| 27 Jun 2025 |
 emily | not quite – there are reasons to forego standard headers and libraries even on a hosted platform | 21:05:39 |
| emily | but the obvious example is that glibc for aarch64-unknown-linux-gnu is of course built without glibc :) | 21:05:50 |
| emily | (but is definitely not building for bare metal) | 21:06:03 |
| emily | pkgs/build-support/bintools-wrapper/ld-wrapper.sh has an example of gnarly non-trivial logic we have in wrappers around the rpath stuff | 21:08:27 |
 Tristan Ross | In reply to @sielicki:matrix.org
with the current stdenv, my main complaint is that it's imprecise with respect to the languages supported. ie: there's no stdenv.cxx/stdenv.fc/stdenv.objcc/stdenv.objcxx/stdenv.nvcc/stdenv.hipcc This is something that's in the pipeline of changes we're working on. Hopefully soon we'll have some movement. | 21:23:25 |
| emily | it… is? :) | 21:27:44 |
| emily | I'm not aware of any current work on that front (for C-family languages I'm not sure it's a good idea to split up, though stdenvNoCC by default would obviously be great but is a hugely breaking change for external users) | 21:28:07 |
| Tristan Ross | In reply to @emilazy:matrix.org
I'm not aware of any current work on that front (for C-family languages I'm not sure it's a good idea to split up, though stdenvNoCC by default would obviously be great but is a hugely breaking change for external users) We've already got split GCC on the way and so far, it's doing good. | 21:35:20 |
