Bug 814477
| Summary: | Missing libdumb.so symlink | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fernando <bocadillodeatun> |
| Component: | dumb | Assignee: | Hans de Goede <hdegoede> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | hdegoede |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-04-20 06:33:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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? Yes please! |
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