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 613394 - Gstreamer links tools against its system libs, not srcdir libs
Gstreamer links tools against its system libs, not srcdir libs
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal critical
: git master
Assigned To: Tim-Philipp Müller
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-03-20 10:44 UTC by Priit Laes (IRC: plaes)
Modified: 2010-10-12 16:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build log: seems to work for me.. (28.97 KB, text/plain)
2010-03-23 00:08 UTC, Tim-Philipp Müller
  Details
autogen.log (18.13 KB, text/plain)
2010-03-23 04:52 UTC, Priit Laes (IRC: plaes)
  Details
build.log (383.63 KB, text/plain)
2010-03-23 04:53 UTC, Priit Laes (IRC: plaes)
  Details
check.log (189.88 KB, text/plain)
2010-03-23 04:53 UTC, Priit Laes (IRC: plaes)
  Details
failload.log (18.15 KB, text/plain)
2010-03-23 17:24 UTC, Priit Laes (IRC: plaes)
  Details
strace-open.log (24.86 KB, text/plain)
2010-03-23 20:25 UTC, Priit Laes (IRC: plaes)
  Details
gst/gstabi (4.29 KB, text/plain)
2010-03-23 20:31 UTC, Priit Laes (IRC: plaes)
  Details
readelf-gstcorelements.log (2.40 KB, text/plain)
2010-03-24 05:23 UTC, Priit Laes (IRC: plaes)
  Details
possible fix: build: try harder to link tools and plugin-scanner to the right libraries (2.64 KB, patch)
2010-04-08 08:19 UTC, Tim-Philipp Müller
committed Details | Review

Description Priit Laes (IRC: plaes) 2010-03-20 10:44:09 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]
Comment 1 Tim-Philipp Müller 2010-03-22 11:43:59 UTC
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?
Comment 2 Priit Laes (IRC: plaes) 2010-03-22 13:43:16 UTC
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
Comment 3 Tim-Philipp Müller 2010-03-23 00:08:58 UTC
Created attachment 156821 [details]
build log: seems to work for me..
Comment 4 Tim-Philipp Müller 2010-03-23 00:17:35 UTC
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!
Comment 5 Priit Laes (IRC: plaes) 2010-03-23 04:52:11 UTC
Created attachment 156828 [details]
autogen.log
Comment 6 Priit Laes (IRC: plaes) 2010-03-23 04:53:04 UTC
Created attachment 156829 [details]
build.log
Comment 7 Priit Laes (IRC: plaes) 2010-03-23 04:53:58 UTC
Created attachment 156830 [details]
check.log

With failures...
Comment 8 Tim-Philipp Müller 2010-03-23 08:53:25 UTC
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.
Comment 9 Priit Laes (IRC: plaes) 2010-03-23 17:24:39 UTC
Created attachment 156891 [details]
failload.log
Comment 10 Tim-Philipp Müller 2010-03-23 19:36:12 UTC
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..)
Comment 11 Priit Laes (IRC: plaes) 2010-03-23 20:25:59 UTC
Created attachment 156921 [details]
strace-open.log

Apparently libgstbase-0.10.so.0 is looked from wrong directory :S
Comment 12 Tim-Philipp Müller 2010-03-23 20:30:52 UTC
Oh, and another one:

 $ readelf -d plugins/elements/.libs/libgstcoreelements.so

?
Comment 13 Priit Laes (IRC: plaes) 2010-03-23 20:31:10 UTC
Created attachment 156922 [details]
gst/gstabi
Comment 14 Priit Laes (IRC: plaes) 2010-03-24 05:23:38 UTC
Created attachment 156942 [details]
readelf-gstcorelements.log

Sorry, overlooked the readelf part yesterday..
Comment 15 Tim-Philipp Müller 2010-03-25 11:55:31 UTC
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.
Comment 16 Jan Schmidt 2010-03-25 11:58:43 UTC
Which sounds like some linker voodoo bug :-/
Comment 17 Tim-Philipp Müller 2010-04-08 08:19:00 UTC
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?
Comment 18 Tim-Philipp Müller 2010-04-08 08:22:41 UTC
Marking as blocker for now.
Comment 19 Priit Laes (IRC: plaes) 2010-04-09 05:41:42 UTC
(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
Comment 20 Tim-Philipp Müller 2010-04-12 22:31:03 UTC
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.
Comment 21 Tim-Philipp Müller 2010-05-05 16:57:27 UTC
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.
Comment 22 Priit Laes (IRC: plaes) 2010-05-06 05:59:57 UTC
(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.
Comment 23 Edward Hervey 2010-10-12 16:45:14 UTC
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.