| 1 Dec 2025 |
 Randy Eckenrode | There used to be wrappers to work around cctools’s limitations, but those were removed. | 16:04:24 |
| Randy Eckenrode | * | 16:04:46 |
| Randy Eckenrode | The issue with LLD is that it doesn’t support some flags required for compatibility with Xcode projects. It also was missing some features, but I haven’t checked on it in a while. | 16:07:34 |
| Randy Eckenrode | In most cases, it should be fine. | 16:07:44 |
 bake.monorail | I see, thanks for the clarifications. I'll try to set up a stdenv using LLD to get to compile hello. I would be very happy not to have to deal with ld64 :P. Also, none of the projects I'm specifically interested in uses Xcode projects, and since the way forward seems to be lld anyway... | 16:10:25 |
| Randy Eckenrode | Also, don’t worry about x86_64-darwin. That platform won’t be available in nixpkgs this time next year. | 16:10:25 |
| 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 |
| bake.monorail | Anyway, I'll try to switch back to master and fight some more to get lld working.
Thanks for the feedback Randy. | 16:36:35 |
| Randy Eckenrode | You’re welcome! | 16:43:55 |
 alexfmpe | am I holding it wrong or x86_64 -> aarch32 works while aarch64->aarch32 doesn't ?
$ uname -mo
Darwin arm64
$ nom-build -A pkgsCross.armv7a-android-prebuilt.hello --argstr system "aarch64-linux"
error: Android NDK doesn't support building on aarch64-unknown-linux-gnu, as far as we know
$ nom-build -A pkgsCross.armv7a-android-prebuilt.hello --argstr system "x86_64-linux"
/nix/store/2nnknh2lbi49n97n8cii6lqgr64bfzjp-hello-armv7a-unknown-linux-androideabi-2.12.2
| 18:24:28 |
| alexfmpe | (using rosetta/linux builder shenanigans) | 18:24:54 |
 K900 | On Darwin? Very possibly | 18:25:20 |
