After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 602075 - wrong path to python library on x86_64 platform
wrong path to python library on x86_64 platform
Status: RESOLVED DUPLICATE of bug 599991
Product: GStreamer
Classification: Platform
Component: gst-python
0.10.17
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-11-16 09:39 UTC by Anatoly Pugachev
Modified: 2010-08-26 12:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Anatoly Pugachev 2009-11-16 09:39:17 UTC
following from
https://bugzilla.redhat.com/show_bug.cgi?id=513703

gstreamer-python-0.10.16 and gstreamer-python-0.10.17 have wrong path compiled into libgstpython.so as "/usr/lib/libpython2.6.so", but that should be "/usr/lib64/libpython2.6.so" .
Comment 1 Anatoly Pugachev 2009-11-16 11:03:37 UTC
looks same as https://bugzilla.gnome.org/show_bug.cgi?id=599991
Comment 2 Edward Hervey 2009-11-16 11:23:44 UTC
I thought the standard behaviour was for $prefix/lib to be a symbolic link to the native architecture library ($prefix/lib32 on 32bit, $prefix/lib64 on 64bit).
Comment 3 Anatoly Pugachev 2009-11-16 12:30:18 UTC
afaik, LSB doesn't specify that /lib should be a link to relevant architecture.

Jumping from http://www.linuxfoundation.org/en/Specifications to

amd64 http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-AMD64/LSB-Core-AMD64/requirements.html

and ia32 http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-IA32/LSB-Core-IA32/requirements.html

shows that 64-bit libraries should be loaded by /lib64/ld-lsb-x86-64.so.3 (a symlink to ld-linux-x86-64.so.2), while ia32 loader is /lib/ld-lsb.so.3

so, it isn't a strict rule that /lib should be a pointer, but rather ia32 loader is located there.

Getting back to our library wrong path, it goes to

$ cd gst-python-0.10.17/
$ grep PY_LIB_LOC ...
plugin/gstpythonplugin.c:        g_module_open (PY_LIB_LOC "/libpython" PYTHON_VERSION "."

PY_LIB_LOC is defined in :

./plugin/Makefile:	-DPY_LIB_LOC="\"$(PYTHON_LIB_LOC)\""		\

and PYTHON_LIB_LOC resides in ./configure

I'm not a big programmer, and it would take a lot more time for me, on writing a patch for autoconf/automake, but as a result it should be more careful about libs location, assuming that libs are not always in /lib. 

Thanks.
Comment 4 Tobias Mueller 2010-06-05 10:17:27 UTC
Reopening as I can't see any open question.
Comment 5 Anatoly Pugachev 2010-08-26 09:14:51 UTC
well, at least RH FC13 have this bug fixed as in gstreamer-python-0.10.16-1.fc12.x86_64 (installed on my fc13) and correct link:

$ ldd /usr/lib64/gstreamer-0.10/libgstpython.so
...
	libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007fe16fb55000)

probably you can close this bug report also. Thanks.
Comment 6 Alessandro Decina 2010-08-26 12:39:25 UTC

*** This bug has been marked as a duplicate of bug 599991 ***