GNOME Bugzilla – Bug 350637
GStreamer won't build if libxml2 is not on the same dirs as other dependencies
Last modified: 2006-10-17 12:23:33 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.
* 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?
(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.
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?
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)?
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?
(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.
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!