| 27 Jun 2025 |
 sielicki | one of the biggest rough spots for me is in trying to setup environments between clang/gcc and libc++ vs libstdc++:
nix-repl> pkgs.stdenv.cc.libcxx # on darwin
«derivation /nix/store/clhcsg5l0lwabkniwqfgfjcfhydp0xxs-libcxx-19.1.7.drv»
nix-repl> pkgs.pkgsLinux.stdenv.cc.libcxx
null
both of these stdenvs are capable of building C++ programs
| 20:25:44 |
 emily | libcxx is the LLVM C++ library | 20:37:24 |
| emily | on Linux we use libstdc++ by default | 20:37:28 |
| emily | well, I guess you know that :) | 20:37:35 |
| emily | but I'm not sure why you're looking at stdenv.cc.libcxx to begin with, what are you trying to accomplish? | 20:37:44 |
| sielicki | I dunno, that's a good question. I guess my main idea here is to avoid cc-wrapper as much as possible, for build systems where it is possible. In the case of autotools, I don't see a way around cc-wrapper. But for meson or cmake, I think passing the unwrapped compiler, alongside a nix-generated toolchain, can help out in some hand-wavey way.
https://github.com/sielicki/nix-cmake/blob/main/pkgs/cmake-toolchain-hook/cmake-toolchain.nix
https://github.com/sielicki/nix-cmake/blob/main/pkgs/cmake-dependency-hook/cmakeBuildHook.cmake
this is very rough but it's a start.
| 20:43:57 |
| emily | we (or at least I) would generally like to move in the direction of fewer wrappers, but it's hard (will require upstream compiler work) | 20:45:12 |
| emily | since exactly what the flags inject depends on what flags are being passed | 20:45:18 |
| emily | I think that is generally hard to express in the toolchain information files build systems support | 20:45:32 |
| sielicki | hmm, I'm not sure I see why -- what's something we can accomplish with cc-wrapper that we can't do otherwise? | 20:47:00 |
| emily | e.g., we look at -nostdlib/-nostdinc when deciding what flags to inject | 20:55:05 |
| emily | which is import for things like getting libc to work without breaking freestanding builds (including libc itself) | 20:55:58 |
| emily | perhaps not a common use-case for CMake, but pretty critical for our compilers to work :) | 20:56:16 |
| emily | there is also stuff about cross-compilation role variable demangling but theoretically a sufficiently clueful build system could handle that sort of thing (otoh CMake is pretty bad at cross in practice) | 20:57:16 |
| sielicki | I'm probably missing context on the specifics, but I'd think those would be different stdenvs (and different triples) -- freestanding corresponding to something like aarch64-none-elf and used to bootstrap something like aarch64-unknown-linux-eabi, right? | 21:04:29 |
| 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 |
| Tristan Ross | I was thinking of having derivations which mirror the toolchain attributes | 21:35:46 |
| Tristan Ross | So cc is your C/C++ compiler while cxxlib would be your C++ std implementation. | 21:36:19 |
| Tristan Ross | Ik it's something I've talked to Jon about | 21:37:22 |
| Tristan Ross | And it's in the stdenv & CC improvements plan | 21:37:39 |
| 28 Jun 2025 |
 Randy Eckenrode | I’ve been wondering if we should generate a sysroot when setting up the stdenv and point the compiler to that. It would simplify the Darwin SDK and let me drop some workarounds in the Swift compiler. | 00:30:39 |
| Randy Eckenrode | I would also like to see the stdenv not assume a C compiler and require it (and autotools/make support) to be added just like for every other language and build system. | 00:33:07 |
| Tristan Ross | Yeah, it'll be great to disconnect stdenv and cc | 00:33:53 |
