kid3 has libraies installed into /usr/lib/kid3 instead of just kid3. This results in a following error: kid3: error while loading shared libraries: libkid3-gui.so.3.0.2: cannot open shared object file: No such file or directory If I set LD_LIBRARY_PATH, it starts successfully.
CC: (none) => juan.baptisteAssignee: bugsquad => mageia
CC: (none) => stephane.pontier
Hardware: i586 => All
Libraries are fine, they are where they should be: /usr/lib for x86 and /usr/lib64 for x86_64 systems. The problem is that the kid3 binary can't find its own libs.
No. The libraries are in /usr/lib64/kid3 instead of /usr/lib64.
Many other programs put their libs in a subdir under /usr/lib{64} like kid3 is doing, just take a look at those dirs, so I don't think that it's really the problem.
If libraries not in lib, dynamic linker cannot find them without some tricks (setting LD_LIBRARY_PATH, using RPATH etc). Also, in OpenSUSE, plugins placed into kid3 folder and libraries into lib: http://pkgs.org/opensuse-13.1/packman/libkid3_3-3.1-1.32.x86_64.rpm.html
The problem is because kid3 sets the path to the private lib in the binary with RPATH, but it seems that RPATH is disbled in mga, that's why it can't find it. I opened a bug upstream for this: https://sourceforge.net/p/kid3/bugs/91/ So there are three options to fix this: 1. Reenable rpath on the spec file: no go because if was disabled it was for a reason. 2. Set a custom launch script that sets LD_LIBRARY_PATH pointing to the correct dir and then launches the program. 3. Move the lib outside the kid3 directory. So I'm going with option 3 which seems to be the cleanest of all.
Status: NEW => ASSIGNED
Pushed a fixed version, please test.
Closing as per comment #6
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED