NixOS newer GLIBC version forced by environment outside nix-shell

Question

My NixOS system is running on the current nixos-23.05 channel. But I'm using vscode from the current nixos-unstable channel in my configuration.nix like this:

{ config, pkgs, ... }:
let
  unstable = import <nixos-unstable> { config = { allowUnfree = true; }; };
in
{
# ...
  users.users.musteresel = {
    isNormalUser = true;
    description = "Daniel Jour";
    packages = with pkgs; [
      # ...
      unstable.vscode.fhs
    ];
  };
# ...
}

glibc version on the nixos-23.05 channel is 2.37, on the unstable channel it is 2.38. vscode is running fine without any issues!

But if I open a terminal from within VS Code, go to some (C++ + cmake + nix shell) project directory of mine and do

nix-shell
cmake -S . -B build-from-vscode
cmake --build build-from-vscode

then I get an executable which somehow depends on GLIBC version 2.38 (through the fmod symbol, as reported by readelf and nm).

If I do the same from a "normal" (outside VS code) terminal:

nix-shell
cmake -S . -B build-outside
cmake --build build-outside

then I get an executable which does not depend on GLIBC 2.38.

Where is this impurity coming from? The versions of CMake, compiler and so on are the same (same nix store paths!) for both nix-shells (of course, since they're using the same shell.nix file and are both using packages from the nixos-23.05 channel).

edit The impurity seems to come from the environment variables NIX_CFLAGS_COMPILE, NIX_CFLAGS_LINK and NIX_LDFLAGS, since they hold values that reference the fhs environment of vscode (with the newer glibc in it):

NIX_CFLAGS_COMPILE=-idirafter /usr/include
NIX_CFLAGS_LINK=-L/usr/lib -L/usr/lib32
NIX_LDFLAGS=-L/usr/lib -L/usr/lib32

Using in my shell.nix:

  shellHook = ''
    unset NIX_LDFLAGS
    unset NIX_CFLAGS_COMPILE
    unset NIX_CFLAGS_LINK
  '';

Solves this issue when running nix-shell from within vscode. But it does not solve the issue when running a build through vscode (with the nix-environment extension).

Answer 1

Where is this impurity coming from?

I know nothing about nix-shell or vscode, but you can tell where the GLIBC_2.38 reference is coming from by tracing which library provides the definition of the fmod symbol, which you can do by linking with -Wl,-y,fmod flag.

Undoubtedly your two builds are using different versions of libm.so.6. The "problem" build is using newer version of libm.so.6 (and probably newer version of math.h as well), one which defines fmod@@GLIBC_2.38.

How the linker decides which symbol version to use is explained here.