help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Foreign distro Unity desktop broken after guix update


From: Fredrik Salomonsson
Subject: Re: Foreign distro Unity desktop broken after guix update
Date: Mon, 27 Dec 2021 19:37:07 +0000

Hi,

Thorsten Wilms <t_w_@freenet.de> writes:
> Unity desktop stopped working after the first ’guix pull && guix
> package -u’ in maybe 2 weeks. There has been no update on the Ubuntu
> side between the last succesfull run and now, as far as I can tell.
> Unity desktop causes a few redraws, then exits back to the session
> greeter (lightdm).
>
> Now I would have assumed that there is no interaction between Unity and
> guix, since the former is entirely on the dpkg side. But via journalctl,
> I found a whole lot of:
> ```
> Dec 27 15:44:51 charly compiz[2198]: ERROR 2021-12-27 15:44:51
> nux.gltexture.resource.manager GLTextureResourceManager.cpp:
> 54 Invalid target, impossible to generate a new texture.
> Impossible to generate a pixbuf: Unable to load image-loading
> module:
> /gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so:
> /lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_PRIVATE' not found
> (required by
> /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/librt.so.1)
> ```
>
> It looks like compiz segfaults shortly after a bunch of those, followed
> by unity7.service.
>
> Any ideas why dpkg-compiz tries to use guix-librsvg and what to do
> about it, or what else is going on here?

Could be that LD_LIBRARY_PATH is set and includs path(s) to
libpixbufloader-svg.so in the guix store which is causing the streams to
cross.

Try: 

printenv LD_LIBRARY_PATH

and see what it contains

or: 

env | grep /gnu/store

to see if any environment variable contains path to the store. 

Another reason why the runtime linker would pick up that library would
be if its path is added to the /etc/ld.so.conf configs. But I highly
doubt it's the issue.

If you want to go down the rabbit hole you can use the LD_DEBUG
environment variable to get some debug output. The libs option is
probably the most useful to you as that will print where it's looking
for stuff and why. Use:

env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace <executable>

The LD_DEBUG_OUTPUT is a must as it will print out a ton of text. This
will save the output to /tmp/trace.<pid>.

You can tell it to print out a help text by using:

env LD_DEBUG=help cat

I hope that helps a bit.

-- 
s/Fred[re]+i[ck]+/Fredrik/g



reply via email to

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