LD_LIBRARY_PATH is set within VSCode integrated terminal

[janvogt]

I am using nix-ld to run vscode-server on a nixos machine. Which works quite well, thanks!

I realized that within VSCode's integrated terminal LD_LIBRARY_PATH is set. This wasn't an issue, since NIX_LD was set to the system's LD anyways so most binaries continued to work.

However, it all broke down when using an old nixpkgs pin within a direnv environment. All binaries fail to launch with errors like:

/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libc.so.6: version `GLIBC_2.34' not found (required by /nix/store/sqhyhvf3qpnnj6xnb55kv46ckfjx2na8-gcc-11.3.0-lib/lib/libstdc++.so.6)

Unsetting LD_LIBRARY_PATH within the terminal fixes the error.

I asume that somehow vscode-server stores the LD_LIBRARY_PATH variable and sets it on all child shells. I have yet to find a non-hacky way to get rid of the behaviour. Is there a way from nix-ld's side, to prevebt LD_LIBRARY_PATH to be propagated to vscode-servers child processes?

[janvogt]

Some more research revealed that the shell is launched by node-pty shipped with vscode-server and requiring nix-ld to run. I assume, when the the actual shell (in my case fish) is launched by an execve syscall, that the environment just persists.

The workaround I am using for now is to set -e LD_LIBRARY_PATH in fish's init script.

[leonhma]

I just came across this problem too (/nix/store/9v5d40...c5dksd-glibc-2.37-45/lib/libc.so.6: version 'GLIBC_2.38' not found (required by /run/current-system/sw/share/nix-ld/lib/libacl.so.1)). In my case this means that the (already patchelf'd) rust installation from devenv also tries to load libraries from nix-ld, leading to this version-chaos. This seems to be exactly the problem mentioned at the bottom of this repo's README. Since vscode-server is an unpatched binary and uses the nix-ld-provided linker at /lib64/ld-linux-x86-64.so.2, LD_LIBRARY_PATH is set and this seems to propagate to all subprocesses. In my case, unpinning nixpkgs helped (this means removing the nixpkgs input from the devenv flake.nix alltogether, leading to the system one being used).

Of course this is really only a workaround. The README mentions changing the entry point in memory to fix this. How would this work (@Mic92) ?

[Mic92]

nix-ld-rs should fix this limitation

[janvogt]

https://github.com/nix-community/nix-ld-rs indeed says:

NIX_LD_LIBRARY_PATH doesn't affect child processes (on x86_64-linux and aarch64-linux) For example, shell environments spawned by the binary VSCode Server no longer get polluted

This sounds very promising. Thanks for letting us know!

[lilyball]

I just switched to nix-ld-rs and I'm still seeing LD_LIBRARY_PATH set to /run/current-system/sw/share/nix-ld/lib. This directly contradicts the "Current behavior" section of that project's README. I am very confused.

[lilyball]

I take it back. Today it's working correctly. I had tried completely shutting down VSCode and starting it back up yesterday and it was still working, but maybe it kept a server process around for a while, because today my environment looks fine.