Red Hat Bugzilla – Bug 814477
Missing libdumb.so symlink
Last modified: 2012-04-20 02:54:48 EDT
Description of problem:
I found that, when trying to execute the sludge-engine binary (which is
not yet available as a Fedora package, but anyway), the following error
Error loading libdumb.so: libdumb.so: cannot open shared object file: No such file or directory
The thing is "libdumb.so" didn't seem to be a shared library dependency:
[sauron@mordor]$ ldd /usr/local/bin/sludge-engine
linux-vdso.so.1 => (0x00007fffbd8a8000)
libSDL-1.2.so.0 => /usr/lib64/libSDL-1.2.so.0 (0x0000003d42800000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d37800000)
libalure.so.1 => /usr/lib64/libalure.so.1 (0x0000003fa9400000)
libopenal.so.1 => /usr/lib64/libopenal.so.1 (0x0000003fa9000000)
libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x0000003d4a800000)
libogg.so.0 => /usr/lib64/libogg.so.0 (0x0000003d49c00000)
libvpx.so.1 => /usr/lib64/libvpx.so.1 (0x00007f0ee2486000)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003686600000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000003f96a00000)
libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x0000003f9f200000)
libGLee.so.5 => /usr/lib64/libGLee.so.5 (0x00007f0ee21cc000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003f98e00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003d38400000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003f95a00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d37400000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003d37c00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003d38000000)
libz.so.1 => /lib64/libz.so.1 (0x0000003d38800000)
libnvidia-tls.so.295.33 => /usr/lib64/nvidia/tls/libnvidia-tls.so.295.33 (0x0000003f9ee00000)
libnvidia-glcore.so.295.33 => /usr/lib64/nvidia/libnvidia-glcore.so.295.33 (0x0000003f9f600000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003f95e00000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003f96200000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003d3b800000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003d3bc00000)
At the end, I found that "libalure.so" was trying to dynamically load
"libdumb.so" when it is instantiated by the loader (that's why it doesn't
show up as a dependency in "ldd").
This is the source code from "codec_dumb.cpp" (from the "alure" repository):
static void Init()
#define DUMB_LIB "libdumb.so"
dumb_handle = OpenLib(DUMB_LIB);
HOWEVER, "libdumb.so" does not exist in Fedora. The file that gets
installed with "yum install dumb" is "/usr/lib64/libdumb-0.9.3.so",
AND NO EXTRA SYMBOLIC LINK is created:
[sauron@mordor]$ ls -l /usr/lib64/libdumb*
-rwxr-xr-x. 1 root root 214736 Jul 13 2011 /usr/lib64/libdumb-0.9.3.so
This is _all_ fixed by manually creating a soft link, like this:
[sauron@mordor]$ ln -s /usr/lib64/libdumb.so /usr/lib64/libdumb-0.9.3.so
I have zero knowdledge regarding how you usually deal with these
situations in Fedora (or any other distro):
1) Should the "dumb" package maintainer include the extra symlink when
its package is installed?
2) Should the maintainer of the "alure" package patch the source code
to refer to the proper file ("libdumb-0.9.3.so")
3) Is "ldconfig" the one not working? Shouldn't it automatically create
the required symlinks?
Maybe the problem is that "libdumb-0.9.3.so" should be called
"libdumb.so.0.9.3", and "readelf -d" should report
SONAME=libdumb.so.0 instead of (as it does now)
I took as an example "libcanberra.so.0.2.5", which reports a soname
of SONAME=libcanberra.so.0, which I guess then "ldd" uses to create
two symbolic links: "libcanberra.so.0" and "libcanberra.so" (which,
I guess, always points to the latest available version of the
Anyway, something is not working and it would be great if you could fix it.
The libdumb.so symlink is part of the dumb-devel package. The error looks like like sludge is dl-opening the file itself, rather then directly linking to it. And doing so in a buggy way, apps should always use the full soname when dl-opening not the symlink, as the symlink will point to the latest version which may not be ABI compatible with the version they expect.
Anyways installing dumb-devel should fix this for you.
That's right, sorry. I don't know how I missed the "dumb-devel" package (I should have checked if any package provided "libdumb.so" with "yum provides", but somehow I missed that).
On the other hand, it is not "sludge" (which is not a Fedora package) the one dl-opening "libdumb.so", but "alure" (which _is_ a Fedora package). Should this be reported as a bug?
(In reply to comment #2)
> On the other hand, it is not "sludge" (which is not a Fedora package) the one
> dl-opening "libdumb.so", but "alure" (which _is_ a Fedora package). Should this
> be reported as a bug?