Bug 814477 - Missing libdumb.so symlink
Missing libdumb.so symlink
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dumb (Show other bugs)
16
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-19 19:46 EDT by Fernando
Modified: 2012-04-20 02:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-20 02:33:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fernando 2012-04-19 19:46:57 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
would appear:

  [sauron@mordor]$ /usr/local/bin/sludge-engine 
  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)
	/lib64/ld-linux-x86-64.so.2 (0x0000003d37000000)
	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):

  #ifdef DYNLOAD
    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)
     SONAME=libdumb-0.9.3.so.
     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
     library).


Anyway, something is not working and it would be great if you could fix it.

Thanks :)





How reproducible:
================
N/A
Comment 1 Hans de Goede 2012-04-20 02:33:44 EDT
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.
Comment 2 Fernando 2012-04-20 02:50:05 EDT
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?
Comment 3 Hans de Goede 2012-04-20 02:54:48 EDT
(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?

Yes please!

Note You need to log in before you can comment on or make changes to this bug.