help-guix
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]