GNOME Bugzilla – Bug 613394
Gstreamer links tools against its system libs, not srcdir libs
Last modified: 2010-10-12 16:45:14 UTC
When running gstreamer tests from sourcedir while an older version of gstreamer is installed in system, some parts of the sources (mainly tools) seem to be linked against system gstreamer: [snip] make check-TESTS make[3]: Entering directory `/home/plaes/code/gstreamer/tests/check' (gst-plugin-scanner:20518): GStreamer-WARNING **: Failed to load plugin '../../plugins/elements/.libs/libgstcoreelements.so': ../../plugins/elements/.libs/libgstcoreelements.so: undefined symbol: gst_type_find_helper_get_range_ext Running suite(s): GstABI 100%: Checks: 1, Failures: 0, Errors: 0 PASS: gst/gstabi [/snip]
I have heard reports of this, but haven't been able to reproduce this on my system yet (adding dummy functions and calling them from libgstcoreelements, for example). Could you provide more info about your setup? Do you just untar the gstreamer source tarball and configure; make ? What are your libtool/autotools versions?
Here's my simplest approach: gstreamer-0.10.25 is installed system-wide. Either git master or 0.20.28 is under ~/code/gstreamer Configure is run as following: ./configure --prefix=/home/plaes/opt --enable-debug --disable-failing-tests --disable-examples After I run make, and then make check, I get the error ^^ (but only of first time, to see that error I have to make clean again). Versions: sys-devel/automake-1.11.1 sys-devel/autoconf-2.65 sys-devel/libtool-2.2.6b
Created attachment 156821 [details] build log: seems to work for me..
Could you attach the build log for doing a fresh git checkout, and doing $ autogen.sh -- [options] $ make V=1 $make check V=1 Thanks!
Created attachment 156828 [details] autogen.log
Created attachment 156829 [details] build.log
Created attachment 156830 [details] check.log With failures...
Thanks. Could you also do: $ cd tests/check/ $ rm -f test-registry.reg $ GST_DEBUG=*:3,GST_PLUGIN_LOADING:5 make gst/gstabi.check 2>failload.log to get a plugin loading debug log from the failure.
Created attachment 156891 [details] failload.log
How about the output of: cd tests/check; strace -f -eopen make gst/gstabi.check 2>&1 | grep gst > strace-open.log and the file tests/check/gst/gstabi ? (stabbing in the dark here really..)
Created attachment 156921 [details] strace-open.log Apparently libgstbase-0.10.so.0 is looked from wrong directory :S
Oh, and another one: $ readelf -d plugins/elements/.libs/libgstcoreelements.so ?
Created attachment 156922 [details] gst/gstabi
Created attachment 156942 [details] readelf-gstcorelements.log Sorry, overlooked the readelf part yesterday..
Comment on attachment 156921 [details] strace-open.log >... >[pid 26984] open("/home/plaes/code/gstreamer/gst/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) >[pid 26984] open("/home/plaes/code/gstreamer/libs/gst/check/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) >[pid 26984] open("/home/plaes/code/gstreamer/libs/gst/base/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) >... >[pid 26984] open("../../plugins/elements/.libs/libgstcoreelements.so", O_RDONLY) = 4 >[pid 26984] open("/home/plaes/code/gstreamer/gst/.libs/libgstbase-0.10.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) >[pid 26984] open("/usr/lib64/libgstbase-0.10.so.0", O_RDONLY) = 4 >(gst-plugin-scanner:26984): GStreamer-WARNING **: Failed to load plugin '../../plugins/elements/.libs/libgstcoreelements.so': ../../plugins/elements/.libs/libgstcoreelements.so: undefined symbol: gst_type_find_helper_get_range_ext >[pid 26984] open("../../plugins/indexers/.libs/libgstcoreindexers.so", O_RDONLY) = 4 So, when loading the plugin scanner binary, it still happily searches the local library paths provided (as it should, since the libtool wrapper script sets LD_LIBRARY_PATH etc.), but then when it opens the libgstcoreelements.so module, it doesn't look for libgstbase-0.10.so.0 in those paths any more.
Which sounds like some linker voodoo bug :-/
Created attachment 158178 [details] [review] possible fix: build: try harder to link tools and plugin-scanner to the right libraries Does this patch make a difference?
Marking as blocker for now.
(In reply to comment #17) > Created an attachment (id=158178) [details] [review] > possible fix: build: try harder to link tools and plugin-scanner to the right > libraries > > Does this patch make a difference? Nope didn't work :S (gst-plugin-scanner:8784): GStreamer-WARNING **: Failed to load plugin '../../plugins/elements/.libs/libgstcoreelements.so': ../../plugins/elements/.libs/libgstcoreelements.so: undefined symbol: gst_type_find_helper_get_range_ext
Well, no idea what's going on here. Tempted to write it off as a mystery linker/gentoo bug for now. Unmarking as blocker in any case, since there's not much we can do about this, and it generally seems to work for other people.
Given the above, it is not clear to me that there is in fact a bug anywhere in GStreamer, so I'm tempted to close this if you're not going to investigate this any further.
(In reply to comment #21) > Given the above, it is not clear to me that there is in fact a bug anywhere in > GStreamer, so I'm tempted to close this if you're not going to investigate this > any further. Ok, marking as RESOLVED NOTGNOME.
Updates. First of all .... DIE LIBTOOL DIE. Second : the problem it wasn't able to load the plugins/libraries above, is because despite having LD_LIBRARY_PATH properly set for the various tests ... it was using the local plugin scanner (../../libs/gst/helpers/gst-plugin-scanner) for which libtool decided to set the following LD_LIBRARY_PATH: """" # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/home/bilboed/work/devel/gstreamer/gst/.libs:/usr/lib64:$LD_LIBRARY_PATH" """" ... yes, putting the system-wide path before LD_LIBRARY_PATH... therefore preventing the user-set one from being properly used. Last of all ... see my first remark.