stage1: cross compile to x86_64 and arm64 macOS from anywhere with LLVM

[kubkon]

With this branch landing (after it's thoroughly cleaned up), we'll be able to cross-compile binaries targeting x86_64 and aarch64 macOS from anywhere. What does it mean exactly, well this:

> uname -a
x86_64 ... Linux ...
> zig build -Dtarget=aarch64-macos-gnu
> file zig-cache/bin/something_cool
something_cool: Mach-O 64-bit arm64 executable...

[kubkon]

Some update on cross-compiling C++ with zig c++. It works fine for x86_64 with this branch. However, for arm64, LLD panicks with the following:

> /opt/llvm/bin/ld64.lld -error-limit 0 -demangle -dynamic -arch arm64 -macosx_version_min 10.13.0 -sdk_version 10.13.0 -pie -o zig-cache/o/04e94c689d42162b5db59ac8e76253ab/a.out zig-cache/o/da0892023306772270bfe0ea3b4ee06d/hello.o /Users/kubkon/.cache/zig/o/ff321c97bab55d143271d8bf4e73cf76/libcompiler_rt.a /Users/kubkon/.cache/zig/o/36f64755d6f854c2a2664bf44ee52a65/libc++abi.a /Users/kubkon/.cache/zig/o/1c9ab3cee90aae422c3bf97a94fe04ab/libc++.a -undefined dynamic_lookup
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/llvm/bin/ld64.lld -error-limit 0 -demangle -dynamic -arch arm64 -macosx_version_min 10.13.0 -sdk_version 10.13.0 -pie -o zig-cache/o/04e94c689d42162b5db59ac8e76253ab/a.out zig-cache/o/da0892023306772270bfe0ea3b4ee06d/hello.o /Users/kubkon/.cache/zig/o/ff321c97bab55d143271d8bf4e73cf76/libcompiler_rt.a /Users/kubkon/.cache/zig/o/36f64755d6f854c2a2664bf44ee52a65/libc++abi.a /Users/kubkon/.cache/zig/o/1c9ab3cee90aae422c3bf97a94fe04ab/libc++.a -undefined dynamic_lookup
0  ld64.lld                 0x0000000104460058 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 52
1  ld64.lld                 0x000000010445f1b0 llvm::sys::RunSignalHandlers() + 128
2  ld64.lld                 0x0000000104460650 SignalHandler(int) + 292
3  libsystem_platform.dylib 0x0000000188f00c44 _sigtramp + 56
4  ld64.lld                 0x00000001046ba560 lld::mach_o::CompactUnwindPass::perform(lld::SimpleFile&) + 2756
5  ld64.lld                 0x00000001044e682c lld::mach_o::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) + 900
6  ld64.lld                 0x000000010437f25c main + 1504
7  libdyld.dylib            0x0000000188ed4f54 start + 4
[1]    42844 segmentation fault  /opt/llvm/bin/ld64.lld -error-limit 0 -demangle -dynamic -arch arm64  10.13.0

@andrewrk, have you perhaps seen something like this before?

[kubkon]

Ugh, when linking against libcxxabi, the output from LLD is garbled even on x86_64. In "binding info" section of dyld info we expect this pointer to be bound at loading time:

But this is what we get instead:

whereas the dyld_stub_binder symbol is tossed deeper into the binding info byte stream for some reason as a local symbol to the executable.

[kubkon]

OK, surprisingly, the output from LLD when linking in archives when cross compiling is pretty messed up. I'll need to noodle on it some more, and see whether there is anything I can do to fix it, or whether it should really be fixed in the LLD itself. In the meantime, my suggestion here is to still go with these changes (after they are refactored ofc!). At the very least, cross compiling Zig and C seems to work fine for the simple cases which already is a major step forward for the macOS platform support in Zig.

[andrewrk]

@andrewrk, have you perhaps seen something like this before?

Yes. We need to get off of lld::mach_o as soon as possible and on to lld::macho, because the former is completely unmaintained and will be deleted in a future LLD release.

The path forward here is to switch to master branch lld::macho and get any bugs that arise filed upstream, and work with LLD devs to get this solved before LLVM cuts the release/12.x branch.

[kubkon]

@andrewrk, have you perhaps seen something like this before?

Yes. We need to get off of lld::mach_o as soon as possible and on to lld::macho, because the former is completely unmaintained and will be deleted in a future LLD release.

The path forward here is to switch to master branch lld::macho and get any bugs that arise filed upstream, and work with LLD devs to get this solved before LLVM cuts the release/12.x branch.

So my plan here is to refactor this PR as promised so that we get some cross-compilation available with the current LLVM backend (i.e., this then excludes zig c++ however should work fine in case of zig or zig cc), and then move on to trying out the new LLVM backend.

[andrewrk]

When building glibc files we should not pass any-macos-any as an include directory

[andrewrk]

Did you mean to return here? I think you meant break :block_name; and to give a block name to the if statement block on the previous line

[kubkon]

Oh crap, yeah, you're absolutely right. Thanks for spotting that one!