glxinfo: depends on libdrm.so.1, but nowhere to be found

[Andreas Mohr]

Hi,

yet another Dapper bug report of mine (they're already getting rather very numerous and too trivial for my taste).

On a current Dapper system (dist-upgraded again only minutes ago), glxinfo still says:
# glxinfo
glxinfo: error while loading shared libraries: libdrm.so.1: cannot open shared object file: No such file or directory

libdrm.so.1 cannot be found anywhere, only /usr/lib/libdrm.so.2.0.0 (from libdrm2), and installing libdrm-dev doesn't provide libdrm.so.1 either.

mesa-utils 6.3.2-0ubuntu6
libdrm-dev 2.0-0ubuntu1
libdrm2 2.0-0ubuntu1

Reinstalling mesa-utils (might have been a stale glxinfo binary?) did not help.

NOTE that this is an ex-Knoppix ex-Debian ex-Breezy now-Dapper system, so this might be a Ubuntu packaging weakness that nobody else was able to hit...

Thanks!

Andreas Mohr

[Adam Conrad (adconrad)]

Can I get the output of the following commands:

dpkg -l mesa-utils
ldd /usr/bin/glxinfo | grep drm

For reference, the dapper mesa-utils (6.3.2-0ubuntu6) appears to link to libdrm.so.2 here, and works fine.

[Andreas Mohr (andi)]

First, thanks for your fast reply!

Unbelievable. Absolutely F... Unbelievable.

OK, anyway, let me paste some stuff:

# dpkg -l mesa-utils
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==================-==================-====================================================
ii mesa-utils 6.3.2-0ubuntu6 Miscellaneous Mesa GL utilities
# ldd /usr/bin/glxinfo
        linux-gate.so.1 => (0xffffe000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7f67000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7ef1000)
        libglut.so.3 => /usr/lib/libglut.so.3 (0xb7ebe000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e9c000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d6d000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7c86000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7c79000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c67000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7c62000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c5f000)
        libdrm.so.1 => not found
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7b89000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7b7f000)
        /lib/ld-linux.so.2 (0xb7fe7000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7b7c000)
root@ring:/home/yun# ls -l /usr/bin/glxinfo
-rwxr-xr-x 1 root root 16188 2005-10-11 14:12 /usr/bin/glxinfo
# md5sum /usr/bin/glxinfo
c35f4033450ec4de669c6cb20f3d278b /usr/bin/glxinfo

YES, this is THAT version, YES, I did apt-get install --reinstall it, YES, I did move /usr/bin/glxinfo away and then reinstalled, YES, it's still failing in the very same way.

The only thing that matters now, I think, thus is:

deb http://fr.archive.ubuntu.com/ubuntu/ dapper main restricted universe multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ dapper-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu dapper-security main restricted universe

deb http://wine.sourceforge.net/apt/ binary/

Or maybe I'm @$#%@$#% and awfully totally missing something...

Any ideas left?

Thanks! :)

[Andreas Mohr (andi)]

Doh, sorry, I just pressed Reload and didn't *quite* understand the Chinese message that warned me of a double-submission... Hrmpf, time to *really* start learning Chinese...

[Adam Conrad (adconrad)]

Fast reply notwithstanding, I was also rather tired last night when I replied and didn't take into account that glxinfo isn't actually linked with libdrm at all, but is rather pulling it in as a transitive dependency from libGL.

Can you check:

dpkg -l libgl1-mesa (should be 6.4.1-0ubuntu7 on dapper)
ldd /usr/lib/libGL.so.1 | grep drm
dpkg -S libGL.so.1

Also, which architecture is this running on, and are you using any non-free OpenGL drivers (like nvidia-glx, or xorg-driver-fglrx)?

[Andreas Mohr (andi)]

Darn, I didn't expect (nor know...) such special behaviour as transitive dependencies.
...which makes this the very old and tiresome and way too frequent "user with screwed libGL* on his PC" problem. IOW, I really should have checked this earlier but didn't since I couldn't believe that this would be the case. This is a P3/450 here.

# dpkg -l libgl1-mesa
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==================-==================-====================================================
ii libgl1-mesa 6.4.1-0ubuntu7 A free implementation of the OpenGL API -- GLX runti

# ldd /usr/lib/libGL.so.1 | grep drm
        libdrm.so.1 => not found

# dpkg -S /usr/lib/libGL.so.1
libgl1-mesa: /usr/lib/libGL.so.1

So, to me it seems as if libGL.so.1 had a transitive dependency on libdrm.so.1 again?
I'll do some more verification now that it's much more likely that it's a case of custom-installed libGL*.

Thanks!

[Adam Conrad (adconrad)]

Looks like someone's probably overwritten libGL.so.1, yes (perhaps with a binary driver installer or something).

I've verified (a few times) that the i386 libGL.so.1 that we ship links to libdrm.so.2, so the problem pretty much has to be on your end. :)

Let me know anyway, so I can close this bug.

[Andreas Mohr (andi)]

# strings /usr/lib/libGL.so.1|grep ^lib
libX11.so.6
libXext.so.6
libm.so.6
libpthread.so.0
libXxf86vm.so.1
libdl.so.2
libdrm.so.1
libc.so.6
libGL.so.1

So libdrm.so.1 seems to be a *hard* dependency there.

Hmm, I found it:

# ls -l libGL*
lrwxrwxrwx 1 root root 16 2006-04-02 12:52 libGL.so.1 -> libGL.so.1.2.old
-rw-r--r-- 1 root root 406824 2006-03-23 17:04 libGL.so.1.2
-rw-r--r-- 1 root root 407720 2005-10-24 19:53 libGL.so.1.2.old
lrwxrwxrwx 1 root root 20 2006-03-26 09:19 libGLU.so.1 -> libGLU.so.1.3.060401
-rw-r--r-- 1 root root 479244 2006-03-23 17:04 libGLU.so.1.3.060401

Now the question is: shouldn't libgl1-mesa touch (i.e.: mangle) the symlink on installation, or at least provide a fat warning that the symlink doesn't point to the newly installed version of libGL.so.1?

[Andreas Mohr (andi)]

Not to mention that:

# dpkg -S /usr/lib/libGL.so.1.2
libgl1-mesa: /usr/lib/libGL.so.1.2

# dpkg -S /usr/lib/libGL.so.1
libgl1-mesa: /usr/lib/libGL.so.1

So libgl1-mesa claims ownership of the symlink, yet doesn't fix it or alert if there's a problem on upgrade? Weird...

[Adam Conrad (adconrad)]

Ahh, this is a problem with the person who decided to copy/rename libGL.so.1.2 not having a clue how ldconfig works. Witness:

(base)root@cthulhu:/usr/lib # ls -l libGL.so.1*
lrwxrwxrwx 1 root root 12 2006-03-24 08:12 libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 406824 2006-03-24 03:04 libGL.so.1.2
(base)root@cthulhu:/usr/lib # cp -a libGL.so.1.2 libGL.so.1.2.old
(base)root@cthulhu:/usr/lib # ls -l libGL.so.1*
lrwxrwxrwx 1 root root 12 2006-03-24 08:12 libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 406824 2006-03-24 03:04 libGL.so.1.2
-rw-r--r-- 1 root root 406824 2006-03-24 03:04 libGL.so.1.2.old
(base)root@cthulhu:/usr/lib # ldconfig
(base)root@cthulhu:/usr/lib # ls -l libGL.so.1*
lrwxrwxrwx 1 root root 16 2006-04-02 20:57 libGL.so.1 -> libGL.so.1.2.old
-rw-r--r-- 1 root root 406824 2006-03-24 03:04 libGL.so.1.2
-rw-r--r-- 1 root root 406824 2006-03-24 03:04 libGL.so.1.2.old

Since "libGL.so.1.2.old" is a "newer" version that "libGL.so.1.2" (based on the versioned filename), ldconfig is updating the symlink to point to the wrong library. Libraries should generally never be copied or backed up into /usr/lib for this very reason, but rather moved out of the way to someplace outside the library search path.

[Adam Conrad (adconrad)]

Rejecting the bug, as breaking your own libraries, though creative, is not really a supported action. :)

[Andreas Mohr (andi)]

> Ahh, this is a problem with the person who decided to > copy/rename libGL.so.1.2 not having a clue how ldconfig works.

You mean... me? ;)

OK. So... Mea. Culpa. Absolutely. Fully. Heading over to the hangman site...

I should really have had a bit more experience with ldconfig stuff by now... (10+ years user experience speaking here)

Sorry for having wasted your time!

However... given that it's so easy to shoot yourself into the foot (people do this all the time with libGL*, already many years ago, due to various proprietary drivers and different libGL projects), would it still be worthwhile to add a safety check on package install/upgrade and warn the user if something may be fishy?
(i.e. detect custom-installed GL libraries and do a warning about them or so)

[Adam Conrad (adconrad)]

I don't see much difference between this and misconfiguring/replacing any other binary/library on the system, except perhaps that this one's more frequently messed with. At any rate, I'd rather not set a precedent by starting to warn about breakage in libGL, when I can think of a dozen other binaries I get whacky bug reports about where I'd like to implement similar warnings. :)

I think we'll just leave this resolved as-is.

[Andreas Mohr (andi)]

Oh well, I was desperately trying to get some last bonus mileage out of this otherwise trainwreckishly bug report, but I agree that this problem was just a specific variant of a generally applicable problem.
OTOH one might even want to go as far as remembering these issues as one item on a list of useful system health checks for a generic Ubuntu system troubleshooting module ;)

Thanks a lot for your very nice and fast help!