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 350637 - GStreamer won't build if libxml2 is not on the same dirs as other dependencies
GStreamer won't build if libxml2 is not on the same dirs as other dependencies
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-08-09 20:03 UTC by Felipe Contreras (banned)
Modified: 2006-10-17 12:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Felipe Contreras (banned) 2006-08-09 20:03:22 UTC
If you try to build GStreamer and your libxml2 is not in /usr/lib, nor in the same directory as other dependencies, like GLib, then the build will fail trying to resolve libxml symbols when on the tool directory.

The problem is the following line in configure.ac:

GST_ALL_LIBS="$GLIB_LIBS $LTLIBINTL \$(GCOV_LIBS)"

It should be:

GST_ALL_LIBS="$GLIB_LIBS $XML_LIBS $LTLIBINTL \$(GCOV_LIBS)"

That should fix the problem.
Comment 1 Tim-Philipp Müller 2006-08-10 10:33:12 UTC
 * Which symbols exactly?
 * When compiling which tool?
 * What's the last gcc line and all the output after that?

Did you see the comment in configure.ac above the GST_ALL_LIBS line?
Comment 2 Felipe Contreras (banned) 2006-08-10 17:13:06 UTC
(In reply to comment #1)
>  * Which symbols exactly?

xmlOutputBufferCreateFile
xmlTextReaderGetAttribute
xmlNewDocNode
xmlReaderForFd
xmlNewDoc
xmlGenericError
xmlNewChild
xmlDocGetRootElement
xmlNodeGetContent
xmlFindCharEncodingHandler
xmlParseMemory
xmlParseFile
xmlTextReaderConstName
xmlTextReaderConstValue
xmlParseCharEncoding
xmlFreeTextReader
xmlTextReaderValue
xmlReaderForMemory
xmlTextReaderNodeType
xmlGenericErrorContext
xmlNewNs
xmlTextReaderRead
xmlIndentTreeOutput
xmlSaveFormatFileTo
xmlSearchNsByHref
xmlFree
xmlTextReaderDepth

>  * When compiling which tool?

First, 'gst-xmllaunch-0.10', then when fixing manually one by one all of the tools fail with the same error.

>  * What's the last gcc line and all the output after that?

/bin/sh ../libtool --tag=CC --mode=link arm-linux-gcc -I$TARGET/include/glib-2.0 -I$TARGET/lib/glib-2.0/include   -g -O2   -o gst-xmllaunch-0.10 ../gst/libgstreamer-0.10.la -pthread -Wl,--export-dynamic -L$TARGET/lib -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -ldl -lglib-2.0     gst_xmllaunch_0.10-gst-launch.o -L$TARGET/lib -lglib-2.0   
arm-linux-gcc -I$TARGET/include/glib-2.0 -I$TARGET/lib/glib-2.0/include -g -O2 -o .libs/gst-xmllaunch-0.10 -pthread -Wl,--export-dynamic gst_xmllaunch_0.10-gst-launch.o  ../gst/.libs/libgstreamer-0.10.so -L$TARGET/lib $TARGET/lib/libgobject-2.0.so $TARGET/lib/libgthread-2.0.so $TARGET/lib/libgmodule-2.0.so -ldl $TARGET/lib/libglib-2.0.so -Wl,--rpath -Wl,$TARGET/opt/gstmmf-felipec/lib -Wl,--rpath -Wl,$TARGET/lib
$ARM_TOOLS/bin/ld: warning: libxml2.so.2, needed by ../gst/.libs/libgstreamer-0.10.so, not found (try using -rpath or -rpath-link)
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlOutputBufferCreateFile'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlTextReaderGetAttribute'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlNewDocNode'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlReaderForFd'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlNewDoc'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlGenericError'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlNewChild'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlDocGetRootElement'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlNodeGetContent'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlFindCharEncodingHandler'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlParseMemory'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlParseFile'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlTextReaderConstName'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlTextReaderConstValue'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlParseCharEncoding'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlFreeTextReader'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlTextReaderValue'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlReaderForMemory'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlTextReaderNodeType'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlGenericErrorContext'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlNewNs'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlTextReaderRead'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlIndentTreeOutput'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlSaveFormatFileTo'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlSearchNsByHref'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlFree'
../gst/.libs/libgstreamer-0.10.so: undefined reference to `xmlTextReaderDepth'
collect2: ld returned 1 exit status
make[2]: *** [gst-xmllaunch-0.10] Error 1
make[2]: Leaving directory `/home/$USER/src/gstreamer-0.10.9/tools'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/$USER/src/gstreamer-0.10.9'
make: *** [all] Error 2 

> Did you see the comment in configure.ac above the GST_ALL_LIBS line?

No, I didn't. Now I have. This is what it says:
 LIBS: XML doesn't need to be added because we don't explicitly use symbols from LibXML except for in the core library

From what I understand it doesn't matter if we use the symbols explicitly or not, you won't be able to link to a library if there are unresolved symbols.

I checked the code and this is what I found:

In the tools directory all of the binaries have the following:
_LDFLAGS = $(GST_OBJ_LIBS)

* Note: maybe _LDADD is more appropriate, according to:
http://www.gnu.org/software/automake/manual/html_node/Linking.html#Linking

GST_OBJ_LIBS doesn't have XML_LIBS or any -L flag that might help to find the 'libxml2.so.2' needed by 'libgstreamer-0.10.so'.

In fact the same happens with the the binaries under 'tests', there is no XML_LIBS and I get exactly the same results.

Now, 'libgstcoreindexers' does have XML_LIBS in it's _LIBADD, but no other library has it, except 'libgstreamer'. Also it might be relevant that 'libgstcoreindexers' has only a static version (I guess that's how you would call a .a that doesn't have a .so). So my best guess is that libtool somehow can find where is 'libxml2.so' from 'libgstreamer-0.10.la' and do all the magic for shared objects.
Comment 3 Tim-Philipp Müller 2006-08-15 14:01:04 UTC
Thomas analysing the problem on IRC:

<thomasvs>	felipec: you know, your link line looks very fishy
<thomasvs>	felipec: it looks like you are not using libtool
<thomasvs>	felipec: the output is showing it's not linking in the proper way
<thomasvs>	felipec: is there stuff you are customizing that you are not telling me ?
<thomasvs>	also, you are not in fact showing me the output of configure like I'm asking
<felipec>	thomasvs: oh, I thought you meant the config.log, let me get that
<felipec>	thomasvs: I have libxml2 in a directory under /opt, PKG_CONFIG_PATH is set accordingly
<thomasvs>	felipec: all of that does not explain why your link lines look like they are not at all using libtool, hence getting the linking wrong
<thomasvs>	felipec: in a normal link line, I expect to see libgstreamer-0.10.la, and -lglib, not libgstreamer-0.10.so and libglib.so
...
<thomasvs>	ok, please show me build output from before what you pasted, so I can actually see make do stuff
<felipec>	thomasvs: there you go: http://pastebin.ca/123893
<thomasvs>	felipec: can I also see the make output for gst/ ? from that output it looks like your libgstreamer-0.10.la file was not generated properly
<felipec>	thomasvs: this is the la file: http://pastebin.ca/123897
<thomasvs>	felipec: what's the content of /data/EVM_filesystems/x0044659/systems/OMAPSW_Linux_8.7/target/opt/gstmmf-2.0/lib/libxml2.la ?
<felipec>	thomasvs: http://pastebin.ca/123902
<thomasvs>	felipec: where is your libxml2.so.2 file on the disk ?
<felipec>	thomasvs: /data/EVM_filesystems/x0044659/systems/OMAPSW_Linux_8.7/target/opt/gstmmf-2.0/lib/libxml2.so.2
<thomasvs>	felipec: so, for some reason, in http://pastebin.ca/123893 -- the transition from line 61 (libtool) to 62 (ld) is going wrong
<thomasvs>	sorry, 60 to 61
<thomasvs>	felipec: it's libtool's job to go through the .la files and make sure it satisfies the deps
<thomasvs>	felipec: none of the tools use xml directly, only libgstreamer does
<thomasvs>	felipec: this dependency is correctly encoded into libgstreamer-0.10.la
<felipec>	thomasvs: in general when I link I always have to add the -L flags or otherwise ld won't find the library, I have never seen libtool do that... but I know next to nothing about libtool
<thomasvs>	felipec: -L only tells about directories, and the directory libxml is in is already on the link line
<felipec>	thomasvs: nope, libxml2 is in $PREFIX/opt/gstmmf-2.0/lib, -L$PREFIX/opt/gstmmf-2.0/lib is not on the link line

If the information in libgstreamer-0.10.la is correct, maybe this is a libtool problem of some sort?


Have you tried using _LIBS instead of _LDFLAGS for the tools in the tools directory? Does that change anything?
Comment 4 Tim-Philipp Müller 2006-08-16 12:12:05 UTC
Felipe, so after your recent comment on IRC

Aug 15 18:05:40 <felipec>  __tim: you know what? I'm totally confused, I managed to change to _LDADD, and it works... but the final binary has libxml2.so as a dependency

things work fine for you if you change the _LDFLAGS stuff in gstreamer/tools/Makefile.am to _LDADD for the tools?

Could you attach the Makefile.am that works for you (or a patch)?
Comment 5 Felipe Contreras (banned) 2006-08-16 21:25:27 UTC
I did another test, I tried to compile from the tarball, even the 'tests' folder didn't compile.

Then I did something else, I tried to run "autogen.sh" with the autotools I have in my FC5 _without_ modifying the Makefile.am on 'tools'. It compiled fine!

So it seems to be a combination of errors here... which versions of the autotools do you use to generate the tarball?
Comment 6 Tim-Philipp Müller 2006-10-12 11:16:22 UTC
(In reply to comment #5)

> Then I did something else, I tried to run "autogen.sh" with the autotools I
> have in my FC5 _without_ modifying the Makefile.am on 'tools'. It compiled
> fine!
> 
> So it seems to be a combination of errors here... which versions of the
> autotools do you use to generate the tarball?

It depends who makes the release and on what system is is made on, so hard to say in general.

If there is a bug in the toolchain somewhere (which is what it sounds like to me), then you should investigate what exactly caused the problem (libtool is always a good candidate) and which version fixes it, so we can then bump the toolchain requirements accordingly.

Without this information, we can't really do much about this I'm afraid.
Comment 7 Tim-Philipp Müller 2006-10-17 12:23:33 UTC
Closing this bug, since there isn't really much we can do about this without more information. Please do re-open this bug if you have new/more information. Thanks!