| 23 Jul 2025 |
|  Charlotte 🦝 (it/its) changed their profile picture. | 10:13:58 |
|  implr set a profile picture. | 10:58:11 |
| implr changed their profile picture. | 11:21:56 |
| 24 Jul 2025 |
|  blocklisted joined the room. | 10:07:02 |
| 25 Jul 2025 |
|  @yuyanugrazi-9001:matrix.org joined the room. | 05:02:03 |
| @yuyanugrazi-9001:matrix.org removed their display name yuyanugrazi-9001. | 05:10:21 |
| @yuyanugrazi-9001:matrix.org left the room. | 05:10:33 |
| 26 Jul 2025 |
 p14 | I'm interested in trying to do a cross compile from a standard aarch64-unknown-linux-gnu nixpkgs, to an aarch64-unknown-linux-gnu nixpkgs with gcc.arch set to something non-standard. If I do this, I bump headlong into https://github.com/NixOS/nixpkgs/issues/265121
Lots of things 'work' but some fundamental dependencies in nixpkgs have this problem with buildPackages.stdenv.cc -- the toolchains seem somewhat screwed up, the wrapper ends up creating compilers called aarch64-unknown-linux-gnu-aarch64-unknown-linux-gnu-cc or similar, because stdenv.buildPlatform != stdenv.hostPlatform even though the target triples are the same.
It seems tricky: how can nixpkgs distinguish the build and host toolchains in the PATH when they have the same triple?
For my purposes I actually wouldn't care if we happened to use the 'host' toolchain for build (because I'm trying to use more recently available architectural features which are available on my build machines). But at the moment it is just broken.
My intent is to use a 'cross' build setup so that I don't have to build the whole world with my arch settings, but just the things required for runtime.
Anyone got experience or thoughts on this? John Ericson
| 11:42:04 |
 Alyssa Ross | IIRC it's not so much that Nixpkgs doesn't distinguish but that GNU doesn't | 12:17:34 |
| Alyssa Ross | Autoconf assumes that cross compiling is when the triples don't match | 12:17:56 |
| p14 | Is this insurmountable? Does it mean the only solution is to do a non-cross build-the-world-from-scratch? | 12:32:36 |
 K900 | Just overlay individual packages? | 12:33:16 |
| K900 | Also, have you benchmarked this, like, at all? | 12:33:24 |
| p14 | It's not about benchmarking for me. It's about architectural features. | 12:33:37 |
| K900 | Because it's extremely unlikely you'll get significantly better performance from doing that | 12:33:40 |
| p14 | And it's not about individual packages | 12:33:41 |
| K900 | What "architectural features"? | 12:33:51 |
| p14 | We're talking about things like hardening features for example. pac-ret being one example. | 12:33:58 |
| p14 | So I was hoping to do a cross build where out pops a hardened glibc when I request... firefox. As a contrived example. | 12:34:31 |
| p14 | What is frustrating is that it seems very close to working, but for the depsBuildBuidl = [ buildPackages.stdenv.cc ] situation. Lots of things do build as expected. | 12:35:25 |
| Alyssa Ross | You could hack it to be a different triple | 12:35:50 |
| p14 | I was wondering about this. | 12:35:58 |
| Alyssa Ross | aarch64-pc-linux-gnu or aarch64-redhat-linux-gnu would probably work :P | 12:36:14 |
| p14 | I have to go AFK but will be on my phone and a bit slower to respond. Back to keyboard typing in a few hours. | 12:36:21 |
| p14 | Nice idea, I'll definitely give that a look. | 12:36:41 |
| p14 | Hopefully I can put whatever I want in the vendor position. | 12:36:53 |
| Alyssa Ross | ... what if we make that useless vendor portion a hash of the platform? :P | 12:37:04 |
| p14 | Ah, so it pops out for free? Neato... | 12:37:29 |
| K900 | I'm going to guess like 1% direct breakage, but it's in some ancient autotools thing that everything depends on | 12:37:50 |
 dramforever | distros already ship toolchains with different vendor, right? | 12:42:05 |
