Any way for LD_LIBRARY_PATH to *not* break nix-env's absolute paths for dynamic libs #327854
Description
Maybe this is naive of me, but I thought there was some way on linux to link a dynamic library with an absolute path which would not be affected by LD_LIBRARY_PATH.
I'm on an ubuntu 14.04 system on a shared account where, for whatever reason, LD_LIBRARY was set to include some extra directories. That causes nix-env to segfault:
$ nix-env -q
Segmentation fault (core dumped)
$ ldd `which nix-env`
linux-vdso.so.1 => (0x00007ffde2da7000)
libnixexpr.so => /nix/store/9n8c3g541qn43yjjs94f1a0m69wp8scg-nix-1.11.2/lib/libnixexpr.so (0x00007f72a54ac000)
libgc.so.1 => /nix/store/f24zx1r39kalz01q9kw7zcg1ngj7w2db-boehm-gc-7.2f/lib/libgc.so.1 (0x00007f72a5243000)
libnixmain.so => /nix/store/9n8c3g541qn43yjjs94f1a0m69wp8scg-nix-1.11.2/lib/libnixmain.so (0x00007f72a5031000)
libnixstore.so => /nix/store/9n8c3g541qn43yjjs94f1a0m69wp8scg-nix-1.11.2/lib/libnixstore.so (0x00007f72a4d6f000)
libnixutil.so => /nix/store/9n8c3g541qn43yjjs94f1a0m69wp8scg-nix-1.11.2/lib/libnixutil.so (0x00007f72a4b3d000)
libnixformat.so => /nix/store/9n8c3g541qn43yjjs94f1a0m69wp8scg-nix-1.11.2/lib/libnixformat.so (0x00007f72a4933000)
libstdc++.so.6 => /nix/store/kxac9yv62zff2pj6k1j4d6hiz8jdi2f3-gcc-5.3.0-lib/lib/libstdc++.so.6 (0x00007f72a45b9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f72a42b3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f72a409c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f72a3cd7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f72a3ad3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f72a38b5000)
/nix/store/phffgv3pwihmpdyk8xsz3wv8ydysch8w-glibc-2.23/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000$f72a573a000)
libsqlite3.so.0 => /nix/store/1w64w28j9vz57g2k5bivh2wpk8q9j6vj-sqlite-3.12.2/lib/libsqlite3.so.0 (0x00007f72a35e0000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f72a33d0000)
libcurl.so.4 => /nix/store/9whcgafma7473b4xpyb88hbhi8w5414z-curl-7.47.1/lib/libcurl.so.4 (0x00007f72a3160000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f72a2f3e000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f72a2b62000)
libnghttp2.so.14 => /nix/store/vv2n25vgck007mjph2ay8g4ab58igzp2-nghttp2-1.9.2-lib/lib/libnghttp2.so.14 (0x00007f72a293$000)
libssh2.so.1 => /nix/store/y8jcz5g52265i18kr63d6lim4k1d7jgn-libssh2-1.7.0/lib/libssh2.so.1 (0x00007f72a2711000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f72a24b2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f72a2299000)
Whereas simply unsetting LD_LIBRARY_PATH makes nix-env run fine:
$ LD_LIBRARY_PATH= nix-env -q
bash-4.3-p42
That's an easy fix, sure. But shouldn't nix-env be robust against LD_LIBRARY_PATH if possible?
Metadata
Metadata
Assignees
Labels
No labels