[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GTK applications crash on start
From: |
Alex ter Weele |
Subject: |
Re: GTK applications crash on start |
Date: |
Sat, 03 Mar 2018 12:32:12 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
address@hidden (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.