Bug 13286

Summary:	kid3 has libraries in wrong place
Product:	Mageia	Reporter:	Nikita Krupenko <krnekit>
Component:	RPM Packages	Assignee:	Damien Lallement <mageia>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	juan.baptiste, stephane.pontier
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	kid3	CVE:
Status comment:

Description Nikita Krupenko 2014-04-29 23:45:42 CEST

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.

David Walser 2014-04-30 19:57:58 CEST

CC: (none) => juan.baptiste
Assignee: bugsquad => mageia

Stéphane Pontier 2014-07-03 13:14:31 CEST

CC: (none) => stephane.pontier

Nikita Krupenko 2014-08-11 20:38:33 CEST

Hardware: i586 => All

Comment 1 Juan Luis Baptiste 2014-08-13 00:26:46 CEST

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.

Comment 2 Nikita Krupenko 2014-08-13 00:38:19 CEST

No. The libraries are in /usr/lib64/kid3 instead of /usr/lib64.

Comment 3 Juan Luis Baptiste 2014-08-13 00:46:00 CEST

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.

Comment 4 Nikita Krupenko 2014-08-13 01:46:42 CEST

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

Comment 5 Juan Luis Baptiste 2014-08-13 05:12:58 CEST

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

Comment 6 Juan Luis Baptiste 2014-08-18 03:24:04 CEST

Pushed a fixed version, please test.

Comment 7 Samuel Verschelde 2015-05-19 20:28:21 CEST

Closing as per comment #6

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED