l...@gnu.org (Ludovic Courtès) writes: > What does this say: > > ldd $(dirname $(readlink -f $(type -P emacs)))/.emacs-25.3-real | grep glibc >
$ ldd $(dirname $(readlink -f $(type -P emacs)))/.emacs-25.3-real | grep glibc libm.so.6 => /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libm.so.6 (0x00007fd969692000) librt.so.1 => /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/librt.so.1 (0x00007fd968869000) libpthread.so.0 => /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0 (0x00007fd966b80000) libc.so.6 => /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6 (0x00007fd96617c000) libdl.so.2 => /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libdl.so.2 (0x00007fd965f78000) libresolv.so.2 => /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libresolv.so.2 (0x00007fd962529000) /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/ld-linux-x86-64.so.2 (0x00007fd96de85000) > Is LD_LIBRARY_PATH or LD_PRELOAD set? > $ echo $LD_LIBRARY_PATH $ echo $LD_PRELOAD /gnu/store/hfz0z0fs14jgl0kzk5hid2msr83lxii1-spectrwm-3.1.0/lib/libswmhack.so.0.0 That's weird, looks like my WM set LD_PRELOAD. I wouldn't have expected that. And sure enough, with LD_PRELOAD unset: $ LD_PRELOAD= emacs -Q --eval "(kill-emacs)" ...(GTK warnings omitted) $ echo $? 0 So why and how does spectrwm set LD_PRELOAD? I can't figure this out. Other than that, I think I know what's going on: my user's compiled emacs uses a newer glibc than the one injected by LD_PRELOAD: $ objdump -p /gnu/store/hfz0z0fs14jgl0kzk5hid2msr83lxii1-spectrwm-3.1.0/lib/libswmhack.so.0.0 ... RUNPATH /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib:... $ objdump -p $(dirname $(readlink -f $(type -P emacs)))/.emacs-25.3-real ... RUNPATH /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib:... And that's because I've guix-pulled and upgraded my user more recently than my system. > Does the beginning of “LD_DEBUG=files emacs” give hints as to why the > second libc gets picked up? > The first paragraph of output looks like this: 19839: 19839: file=/gnu/store/hfz0z0fs14jgl0kzk5hid2msr83lxii1-spectrwm-3.1.0/lib/libswmhack.so.0.0 [0]; needed by /gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash [0] 19839: file=/gnu/store/hfz0z0fs14jgl0kzk5hid2msr83lxii1-spectrwm-3.1.0/lib/libswmhack.so.0.0 [0]; generating link map 19839: dynamic: 0x00007f50b9725dc0 base: 0x00007f50b9524000 size: 0x00000000002020e0 19839: entry: 0x00007f50b9524a90 phdr: 0x00007f50b9524040 phnum: 6 19839: 19839: I think that's just further evidence of the LD_PRELOAD injection.