"nix develop" environment incomplete?

Help
1

Hey, another new user/dev question— I have a package which is failing to build and I’m struggling to recreate the failure using the nix develop environment as I expected to be able to do. I end up with errors like this:

make[2]: *** [CMakeFiles/cpr_slam_utils.dir/build.make:108: CMakeFiles/cpr_slam_utils.dir/src/incremental_trigger.cpp.o] Error 1
In file included from /nix/store/h3f8rn6wwanph9m3rc1gl0lldbr57w3l-gcc-10.3.0/include/c++/10.3.0/cstdio:42,
                 from /nix/store/h3f8rn6wwanph9m3rc1gl0lldbr57w3l-gcc-10.3.0/include/c++/10.3.0/ext/string_conversions.h:43,
                 from /nix/store/h3f8rn6wwanph9m3rc1gl0lldbr57w3l-gcc-10.3.0/include/c++/10.3.0/bits/basic_string.h:6545,
                 from /nix/store/h3f8rn6wwanph9m3rc1gl0lldbr57w3l-gcc-10.3.0/include/c++/10.3.0/string:55,
                 from /nix/store/rgf3j13hnkl6lj5nvq3vnm5xfmbm82xl-cpr_slam_msgs/include/cpr_slam_msgs/Graph.h:9,
                 from /home/administrator/slam_utils_ws/src/cpr_slam_utils/include/cpr_slam_utils/graph.h:15,
                 from /home/administrator/slam_utils_ws/src/cpr_slam_utils/src/graph.cpp:12:
/usr/include/stdio.h:781:10: fatal error: bits/sys_errlist.h: No such file or directory
  781 | #include <bits/sys_errlist.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

From what I can tell here, it’s using the correct GCC from Nix and some of the correct compiler-supplied headers, but it’s leaking in /usr/include/stdio.h from my outer system (Ubuntu). My impression was that taking care of this kind of thing was part of gcc-wrapper— is there something additional that I need to do here?

If it’s relevant, I do have two different glib versions in my PATH in this environment— I have bin and dev from glib-2.68.2, and bin from glibc-2.32-46. I’m working to understand that as a separate matter, but I don’t think it’s directly relevant here since doing nix build on this installable fails at a much later point when built in proper isolation. Disregard this, I didn’t see that it’s glib vs glibc!

2

you could probably do something like:

  shellHook = ''
    NIX_CFLAGS_COMPILE = [ "-I${glibc.dev}/include" ];
  '';

Assuming that gcc prioritizes cli args, the gcc-wrapper should make this available to gcc.

3

Thanks for the suggestion, but I don’t think this is quite it, since the NIX_CFLAGS_COMPILE in my nix develop environment already contains the glibc include path— the issue is that Nix’s GCC is pulling headers from /usr/include, and I don’t know how to stop it doing that.

I proved this to myself by temporarily moving them away from there so that GCC wouldn’t see them (sudo mv /usr/{include,include-x}). Once this was done, it worked as expected! So I’d like to understand what is missing to make gcc ignore the system paths without having to cloak them. (Obviously it works in nix build because that takes place in a purified user namespace environment where nothing from the host is accessible anyway)

4

the FHS paths are likely hardcoded into gcc. Which is why you can still build projects that import from libc without specifying where to find libc.

5

From Directory Options (Using the GNU Compiler Collection (GCC)), it looks like the options for this are -nostdinc and -nostdinc++. I am surprised these wouldn’t be defaulted to on in the wrapped GCC, but I can look into patching them into my projects so that I can build easily outside of isolation.

6

nix builds woouldn’t have access to /usr, so I don’t think it was ever a concern. But maybe we should make the nixified toolchains less likely to interact with a host system “by default”.

7

Oh yeah, for sure. I think it’s just that given the way nix develop is pitched in the documentation as being a representative environment useful for interactively stepping through a failing build etc etc, it would be ideal if it did whatever it could to not touch the surrounding system even when there isn’t the isolation preventing it from doing so.

I know this isn’t really a concern on NixOS where there’s no /usr, but if anything, it’s even more important for users dipping their toes in from other Linuxes to not hit these kinds of surprises when they’re trying to resolve an issue by following the docs. :slight_smile: