The asker is building a Brainfuck-to-arm64 compiler on macOS. Their compiler emits a raw binary — pure arm64 machine code with no headers, no load commands, no segments. They've correctly identified that macOS won't execute this directly: the kernel's execve path on Darwin only knows how to launch Mach-O binaries (or scripts via shebangs). They want to wrap that raw blob into a minimal Mach-O executable using ld.

Why it's harder than it looks: ld on macOS doesn't ingest raw binaries. It consumes Mach-O object files (.o) with symbol tables, relocations, and section metadata. There's no equivalent to GNU ld's -b binary --oformat trick that lets you embed an arbitrary blob as a section. Worse, since around Big Sur, every Mach-O executable on arm64 macOS must be code-signed — even an ad-hoc signature (codesign -s -) is required, or the kernel refuses to launch it with a killed: 9. And the modern ld (the "new linker," ld-prime) is stricter than its predecessor about needing a proper entry point symbol and an LC_MAIN load command.

Direction toward a solution:

• Don't fight ld — feed it what it wants. Wrap the raw blob in a tiny assembly stub that .incbin's the binary into a __TEXT,__text section with a _start (or _main) label at offset 0.
• Assemble with as -arch arm64 stub.s -o stub.o, then link with ld -arch arm64 -platform_version macos 11.0 11.0 -e _start -o prog stub.o.
• Code-sign: codesign -s - prog. Without this, SIP/AMFI will kill it.
• Alternatively, skip ld entirely and hand-author a Mach-O header in your compiler. It's ~200 bytes of LC_SEGMENT_64 + LC_MAIN + LC_BUILD_VERSION load commands. otool -l /bin/ls shows the minimum viable shape.

Gotchas:

• The BF program needs a way to exit. Falling off the end of __text on arm64 will fault. The stub or the generated code must end with an svc #0x80 to exit(0) (syscall #1).
• BF I/O needs read/write syscalls — also via svc. The cell tape needs writable memory; consider emitting a __DATA,__bss section for it rather than putting it in __TEXT (which is RX-only).
• arm64e (Apple Silicon with pointer authentication) is not what you want here — stick to plain arm64, since arm64e requires signed pointers in places a hand-rolled binary won't provide.