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