LTO doesn’t work, and it uses sigtool for signing. sigtool doesn’t set the linker-signed flag, which causes tools like strip to break binaries because their aren’t updated. That flag makes them update automatically.

I see, these don't seem to be dealbreaker to start getting some stuff to cross-compile though. If you intend to have a drop-in replacement, it can be adopted.

For 26.06, I plan to drop it completely from the Darwin bintools. It will just be LLVM bintools.

Does this mean adopting lld as a linker? That would be the best option for cross-compiling as well, but it's unclear to me if there's something that requires ld64 🤔.

LTO doesn’t work, and it uses sigtool for signing. sigtool doesn’t set the linker-signed flag, which causes tools like strip to break binaries because their aren’t updated. That flag makes them update automatically.

I see, these don't seem to be dealbreaker to start getting some stuff to cross-compile though. If you intend to have a drop-in replacement, it can be adopted later on.

For 26.06, I plan to drop it completely from the Darwin bintools. It will just be LLVM bintools.

Does this mean adopting lld as a linker? That would be the best option for cross-compiling as well, but it's unclear to me if there's something that requires ld64 🤔.

There are only three we use from cctools right now:

• ranlib (for CLI compatibility, but LLVM’s seems good enough now);
• install_name_tool (LLVM’s doesn’t support reexports, which are rare but uses by, e.g., libiconv); and
• lipo (LLVM’s doesn’t support static archives, which breaks Meson’s tests).

If you do need to go the cctools-port route

Another problem I have with cctools is that it requires swift-corelibs-libdispatch, which currently fails to build on Linux

setting the platform to non-Darwin

What do you mean by that?

For your situation, LLVM is probably good enough.

Specifically, I need to cross-build mostly LLVM, Python, node, boost and QEMU.

If we could actually get away with using LLD by default

If you do need to go the cctools-port route

Another problem I have with cctools is that it requires swift-corelibs-libdispatch, which currently fails to build on Linux

setting the platform to non-Darwin

What do you mean by that?

For your situation, LLVM is probably good enough.

Specifically, I need to cross-build mostly LLVM, Python, node, boost and QEMU.

If we could actually get away with using LLD by default

I gave it a shot but failed, I'll give it another try.

It compiles, but if you use regular stdenv some symbols are not exported for the reason above.
This works:

(pkgs.callPackage ./pkgs/by-name/li/libtapi/package.nix { stdenv = pkgs.libcxxStdenv; })