Nix Cross Compiling - Public Room Timeline

	Nix Cross Compiling	559 Members
		122 Servers

Load older messages

Sender	Message	Time
30 Nov 2025
Randy Eckenrode	I’d suggest any such work start from there. We don’t use cctools-port.	22:16:16
Randy Eckenrode	Somewhat longer term, I want to rewrite at least some parts of ld64 in Swift. It does a lot of pointer fiddling and other unsafe stuff. There was a ton of UB fixed a release or two ago.	22:17:10
Randy Eckenrode	I wanted to work on making it build on Linux at some point even without that, but there are other priorities like Swift.	22:19:52
Randy Eckenrode	When I resync with upstream, I’ll incorporate any patches people have submitted to nixpkgs to fix the build.	22:20:06
bake.monorail	I just managed to get `ld64` from `cctools-port` to build. What's wrong with that?	22:23:03
bake.monorail	`libtapi` doesn't look like great code either, but I'd avoid frontloading rewriting code in order to be able to cross-compile for macOS.	22:26:56
1 Dec 2025
	matthewcroughan changed their profile picture.	14:57:37
Randy Eckenrode	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. It also historically lagged behind Apple’s releases, but I think they got better about that.	15:56:23
Randy Eckenrode	Darwin used to use cctools-port, but it moved away from it due to the LTO and update issue. The code-signing problem was discovered later.	15:57:18
Randy Eckenrode	Darwin also mostly doesn’t use cctools anymore. For 26.06, I plan to drop it completely from the Darwin bintools. It will just be LLVM bintools.	15:58:10
Randy Eckenrode	https://github.com/reckenrode/ld64 is the fork of ld64 that nixpkgs uses. https://github.com/reckenrode/ld64/tree/ld64-954.16-nixpkgs is the source of the patches.	15:58:56
Randy Eckenrode	Note that libtapi is still packaged even though ld64 vendors a reduced version.	16:00:13
Randy Eckenrode	My recommendation though would be to use LLVM’s bintools and LLD.	16:00:33
bake.monorail	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` 🤔.	16:01:16
bake.monorail	* 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` 🤔.	16:02:29
Randy Eckenrode	Anything that uses `strip` or `install_name_tool` will break the signature.	16:03:36
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); and `lipo` (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

Show newer messages

Back to Room ListRoom Version: 6