| 1 Dec 2025 |
 Randy Eckenrode | Even being able to cross-compile some things will be an improvement. If you do need to go the cctools-port route, I’d suggest setting the platform to non-Darwin and patching it to use rcodesign instead of sigtool. rcodesign can set the linker-signed flag, but its CLI is totally different. | 16:14:07 |
| Randy Eckenrode | And just use LLVM bintools. | 16:14:22 |
| Randy Eckenrode | 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); andlipo (LLVM’s doesn’t support static archives, which breaks Meson’s tests).
| 16:16:37 |
| Randy Eckenrode | For your situation, LLVM is probably good enough. | 16:16:56 |
| Randy Eckenrode | I plan to try to switch those over to LLVM for 26.05. | 16:17:15 |
| Randy Eckenrode | If we could actually get away with using LLD by default, I’d be willing to consider it, but it had problems on x86_64-darwin building the bootstrap. (Admittedly, that was LLD 16, and we’re on 21 now.) | 16:19:26 |
 bake.monorail |
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
| 16:21:22 |
| bake.monorail | *
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.
| 16:22:11 |
| bake.monorail | 
Download asd.png | 16:23:10 |
| bake.monorail | These are the things I'm trying to get to build right now. I still need to figure out the role of libresolv, libsbuf and libutil. Also, apple-sdk. | 16:23:59 |
| Randy Eckenrode | apple-sdk provides the stubs and headers used to build packages for Darwin. Some libraries are built from source. libresolv and libutil are some of them. | 16:26:39 |
| Randy Eckenrode | I thought swift-corelibs-libdispatch got fixed. I’ll be updating it as part of my Swift work, but right now I keep discovering more horrors trying to bootstrap 6.2. | 16:27:35 |
| Randy Eckenrode | What I mean by setting platforms to non-Darwin is setting meta.platforms to Linux. I don’t want there to be confusion about whether cctools-port should be used on Darwin itself. | 16:28:46 |
| Randy Eckenrode | (As-in, a new package separate from cctools.) | 16:30:14 |
| bake.monorail | libtapi was also fun, they hardcode symbol names that assume libc++ in tools/libtapi/libtapi.exports and everything fails silently downstream if you use stdlibc++ :P | 16:31:02 |
| Randy Eckenrode | Good luck with Python. It can’t cross-compile from one Darwin platform to another. I don’t know about from Linux to Darwin. It may only support cross to ELF platforms. | 16:31:32 |
| Randy Eckenrode | Does our libtapi package work? I did try to make sure it compiles on Linux, but I haven’t checked on it in a while. | 16:32:14 |
| bake.monorail | 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; })
| 16:32:59 |
| bake.monorail | I'm thinking at very least to put an assertion on stdenv.isUsingLibcxx or something | 16:33:54 |
