 | Nixpkgs Stdenv | 216 Members |
| 69 Servers |
| Nixpkgs Stdenv | 216 Members |
| 69 Servers |
| Sender | Message | Time |
|---|---|---|
| 1 Oct 2025 | ||
 frontear | I've been trying to compile a C program that uses a few random libs and headers from some packages, which I've correctly declared in Keep in mind this project has no Makefile or CMakeFiles, it's just a bunch of *.h and *.cpp files from an instructor, hence why I need to manually run compilation commands. I'm able to get it to compile by writing the flags myself, but I'm a little confused as to why this isn't working OOTB like the Nixpkgs manual suggests. Is there something I'm missing? | 01:01:28 |
| frontear | * I've been trying to compile a C program that uses a few random libs and headers from some packages, which I've correctly declared in Keep in mind this project has no Makefile or CMakeFiles, it's just a bunch of *.h and *.cpp files from an instructor, hence why I need to manually run compilation commands. I'm able to get it to compile by writing the flags myself, but I'm a little confused as to why this isn't working OOTB like the Nixpkgs manual suggests. Is there something I'm missing? I did check both aforementioned environment variables and they do seem to be populated, so I'm confused. | 01:02:21 |
 rosssmyth | NIX_CFLAGS_COMPILE doesn't do that everything automatically. It's mainly for stdlib stuff. You still need to provide the -I and -L flags for your build inputs, possibly using pkg-config if they supply it. | 03:46:41 |
| frontear | hm I see, I guess what also confused me was seeing that both NIX_CFLAGS_COMPILE and NIX_LDFLAGS were populated with the correct flags to include all the headers and libs respectively, for all of my declared build inputs. That, and the explanation in the Nixpkgs manual suggested that these flags were populated by the stdenv and were used by the CC wrapper and LD wrapper respectively. | 03:58:01 |
| frontear | I’m able to reuse the CFLAGS that are created, I just went ahead and threw pkg-config —libs package1 package2 … and this seems to work | 03:58:47 |
| frontear | Found it: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/default.nix#L37 | 05:29:38 |
| frontear | by default link flags aren’t given to NIX_CFLAGS_COMPILE, which matches what I was seeing | 05:29:55 |
| frontear | now the weird thing is that since the CC wrapper should be using the LD wrapper, I’d have expected NIX_LDFLAGS to be relevant for it | 05:30:24 |
| frontear | back to investigating | 05:30:32 |
| frontear | * | 05:30:53 |
| 2 Oct 2025 | ||
 John Ericson | oh wow, this is being worked on again?! | 04:19:47 |
| John Ericson | excellent news! | 04:19:54 |
 dish [Fox/It/She] | worked on is a strong word, i'm trying to give it some sort of time but i have a million other things I'm also working on at the same time lol | 04:20:27 |
| dish [Fox/It/She] | but yes, trying to make progress on having this work | 04:20:35 |
| 3 Oct 2025 | ||
 Artturin | https://github.com/NixOS/nixpkgs/pull/448196 | 10:38:43 |
| 4 Oct 2025 | ||
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) changed their profile picture. | 08:41:28 | |
 dramforever joined the room. | 11:32:03 | |
| dramforever | We build the bootstrap tools LLVM on aarch64-darwin for aarch64-apple-darwin but the real LLVM for arm64-apple-darwin. This is now a problem because LLVM 21 assumes that it should be arm64 in a test. This is now blocking the current staging-next -> master cycle. | 11:38:51 |
| dramforever | * We build the bootstrap tools LLVM on aarch64-darwin for aarch64-apple-darwin but the real LLVM for arm64-apple-darwin. aarch64 is now a problem because LLVM 21 assumes that it should be arm64 in a test. This is now blocking the current staging-next -> master cycle. | 11:38:59 |
| dramforever | I'm thinking of just changing it to arm64-apple-darwin, which should fix staging-next, but this means it requires special handling next time someone comes around to touching the bootstrap tarball | 11:39:55 |
| dramforever | I don't know if this is a good idea / who to tell about this. Any ideas? Thanks | 11:40:31 |
 Lun | wanted to take a look at your issue but fetching https://ftpmirror.gnu.org/patch/patch-2.5.9.tar.gz is failing, did you have to import any FODs from alternate sources to get that far? | 22:33:05 |
| Lun | something cursed is happening in gen-fib. if you run it redirecting to a file that file just gets /* This file generated by gen-fib.c - DO NOT EDIT. */ and no further lines.probably the musl always-flush.patch you dropped was loadbearing | 23:28:08 |
| Lun | * something cursed is happening in gen-fib. if you run it redirecting to a file that file just gets /* This file generated by gen-fib.c - DO NOT EDIT. */ and no further lines, if you run it without a redirect it works.probably the musl always-flush.patch you dropped was loadbearing | 23:28:27 |
| Lun | * https://ftpmirror.gnu.org/patch/patch-2.5.9.tar.gz is failing, did you have to import any FODs from alternate sources to get that far? | 23:32:15 |
| Lun | yeah if you apply it again minimal-bootstrap.gcc46 builds, tested in https://github.com/NixOS/nixpkgs/commit/ecbb9bad38cf3d293943cb9cebb84dce1fd05698 | 23:39:06 |
| 5 Oct 2025 | ||
| dish [Fox/It/She] | fascinating as to why that's the case | 00:04:14 |
| dish [Fox/It/She] | thanks | 00:04:15 |
| dish [Fox/It/She] | strange, appreciate the help! | 00:04:30 |
| dish [Fox/It/She] | but also it does make sense | 00:05:45 |