| 18 Jan 2026 |
 Randy Eckenrode | Or to answer the question more directly, we’re using our own port. It’s been a low priority making Linux to Darwin cross work. Probably the easiest way now is to use LLVM binutils in cross, force -fuse-ld=lld, and hope for the best. | 19:59:19 |
| Randy Eckenrode | Note that Darwin bintools is almost entirely LLVM tools anyway. The only tools that aren’t are the linker, codesign_allocate, install_name_tool, lipo, and ranlib. Even if I can’t make LLD the default, those will be switched to LLVM or dropped. cctools won’t be in the bootstrap for 26.05 regardless. | 20:01:53 |
| Randy Eckenrode | codesign_allocate is useless on macOS. macOS native tools don’t need to pre-allocate. It’s only needed by sigtool, which can hardcode a reference to it. install_name_tool doesn’t work on binaries with reexports, but those are rare. Ones that need to reexport can use the version from cctools. lipo doesn’t work on archives, which breaks Meson tests. I’m inclined to disable those tests. ranlib isn’t fully compatible with the cctools one (mostly in terms of flags Xcode passes), but enough stuff should work we can use the LLVM in most cases. | 20:03:32 |
| Randy Eckenrode | *
codesign_allocate is useless on macOS. macOS native tools don’t need to pre-allocate. It’s only needed by sigtool, which can hardcode a reference to it.install_name_tool doesn’t work on binaries with reexports, but those are rare. Ones that need to reexport can use the version from cctools.lipo doesn’t work on archives, which breaks Meson tests. I’m inclined to disable those tests.ranlib isn’t fully compatible with the cctools one (mostly in terms of flags Xcode passes), but enough stuff should work we can use the LLVM in most cases.
| 20:04:01 |
| Randy Eckenrode | I opted to do my own ports because at the time cctools-port was behind Apple’s releases. They’ve since caught up (AFAIK by treating the port as a patch set on top of Apple’s releases, which is also what I do), but we’re not switching back (e.g., because of the LTO and code-signing issues). | 20:07:13 |
| 19 Jan 2026 |
 thefloweringash | Maybe slightly off topic, but I happened to see these messages.sigtool was written exclusively for nixpkgs. If it's no longer required I'll gladly archive it. If it's actually still required but causing problems by being unmaintained I can transfer it to a nixpkgs owned github organization. And as always, thank you for hard work in this area | 10:19:04 |
|  Sapphire changed their profile picture. | 20:16:19 |
| 20 Jan 2026 |
| Randy Eckenrode | And thank you for the groundwork you did. | 01:38:48 |
| Randy Eckenrode | sigtool’s main issue is lacking certain features, which won’t be coming. I don’t think we want to maintain our own implementation long term. The way forward is likely a codesign-compatible CLI to rcodesign. | 01:39:53 |
| Randy Eckenrode | It supports the needed features (particularly bundle signing and setting the linker-signed flag), but it has its own CLI. | 01:40:36 |
| Randy Eckenrode | * sigtool’s main issue is lacking certain features. I don’t think we want to maintain our own implementation long term, so we probably don’t want to do that ourselves. The way forward is likely a codesign-compatible CLI to rcodesign. | 01:43:29 |
 emily | FWIW I think Nixpkgs is no longer the world's biggest sigtool consumer at this point 😅 | 01:49:51 |
| Randy Eckenrode | Is Conda using it? | 18:37:11 |
| emily | isn't cctools-port? | 19:40:11 |
| emily | I think that gets a fair bit of use. | 19:40:17 |
| 21 Jan 2026 |
| Randy Eckenrode | Yeah, for code-signing. | 11:34:23 |
| 22 Jan 2026 |
|  crazychaoz joined the room. | 10:43:06 |
| crazychaoz | so i am trying to get a amd64 -> arch64 rust cross build bit-for-bit equal to the emulated version, but (aside from other issues) i cannot get the symbols in the same order
aarch64 native and aarch64 emulated on arm64 already produce the same binary (to be expected tbh)
does anybody here know why or knows a resource (aside from reading rustc source) on ironing out my build ? | 13:08:28 |
 K900 | Honestly I don't think that's a realistic expectation | 13:09:37 |
| K900 | It's very likely your linker and not rustc, if you want to go down that rabbit hole | 13:09:49 |
| K900 | But in general, cross is its own thing and you shouldn't be expecting fully identical behavior | 13:10:17 |
| crazychaoz | ack, but it feels soooo close | 13:14:23 |
 Grimmauld (any/all) | it would be cool, because you could then more easily mix cross and native builds for the same target | 13:14:50 |
| crazychaoz | yeah
and in my case: cross compiling aarch64 is soo much faster than emu or native on a raspi, but only emu or native produce the "expected" result | 13:17:24 |
| crazychaoz | 
Download image.png | 13:20:17 |
| crazychaoz | guess the emu: | 13:20:21 |
|  Moved to: @astro:c3d2.de changed their display name from Astro to Moved to: @astro:c3d2.de. | 21:39:12 |
| 23 Jan 2026 |
|  blitz joined the room. | 14:11:57 |
| blitz | Hey cross-compilation gurus! :) Does anyone have a minute to look at this: https://github.com/NixOS/nixpkgs/issues/482970 | 14:12:35 |
| blitz | I really wonder why building the python bcrypt package fails in this scenario, because it should "just" be the x86 package (which works fine) | 14:13:02 |
