GNOME Bugzilla – Bug 344358
libtool .la files make jhbuild links to system libraries (and fails, sometimes)
Last modified: 2010-10-16 19:39:18 UTC
Please describe the problem: I'm unable to build cairo, and possibly other modules, because libtool is linking to the system versions rather than the ones most recently built by jhbuild. Steps to reproduce: 1. jhbuild build -ca Actual results: When doing this, it eventually fails building cairo with output very similar to the following: libtool --tag=CC --mode=link gcc -O2 -pipe -march=athlon-xp -o svg2png svg2png-svg2png.o -L/mnt/hitachi_shared/gnome/gnome2/lib -lrsvg-2 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lm mkdir .libs gcc -O2 -pipe -march=athlon-xp -o svg2png svg2png-svg2png.o -L/mnt/hitachi_shared/gnome/gnome2/lib /usr/lib/librsvg-2.so /usr/lib/libgnomevfs-2.so -lssl -lcrypto /usr/lib/libhowl.so -lresolv -lrt /usr/lib/libbonobo-2.so /usr/lib/libgconf-2.so /usr/lib/libbonobo-activation.so /usr/lib/libORBitCosNaming-2.so /usr/lib/libORBit-2.so /usr/lib/libpopt.so /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libgsf-1.so -lbz2 /usr/lib/libcroco-0.6.so /usr/lib/libart_lgpl_2.so /usr/lib/libxml2.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libfontconfig.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so /mnt/hitachi_shared/gnome/gnome2/lib/libpangocairo-1.0.so /mnt/hitachi_shared/gnome/gnome2/lib/libpangoft2-1.0.so /mnt/hitachi_shared/gnome/gnome2/lib/libpango-1.0.so /mnt/hitachi_shared/gnome/gnome2/lib/libcairo.so /mnt/hitachi_shared/gnome/gnome2/lib/libXrender.so -lX11 -lpng12 /mnt/hitachi_shared/gnome/gnome2/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libexpat.so /mnt/hitachi_shared/gnome/gnome2/lib/libxml2.so -lz /mnt/hitachi_shared/gnome/gnome2/lib/libgobject-2.0.so /mnt/hitachi_shared/gnome/gnome2/lib/libgmodule-2.0.so -ldl /mnt/hitachi_shared/gnome/gnome2/lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/mnt/hitachi_shared/gnome/gnome2/lib -Wl,--rpath -Wl,/mnt/hitachi_shared/gnome/gnome2/lib As you can see from the output, quite a few things that were built by jhbuild are being linked in /usr/lib rather than /mnt/hitachi_shared/gnome/gnome2 where I keep my jhbuild sandbox. I wonder if it has to do with some of the deps in that list which aren't built yet, or inside of jhbuild. Expected results: A successful build! Does this happen every time? Yes Other information: Using built-in specs. Target: i686-pc-linux-gnu Configured with: /mnt/hitachi_first/portage/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --enable-java-awt=gtk --enable-languages=c,c++,java,objc,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1)
Interesting. I can't reproduce. Try 'jhbuild bootstrap' to ensure you have the latest libtool. Then remove your cairo directory and try building from a fresh checkout.
Same problem here with evolution, epiphany and many other modules. I was about to report this. See: http://mail.gnome.org/archives/gnome-devel-list/2008-January/msg00002.html
Could you describe how does Evolution Makefile produce this command ? It would be really interesting to know how /usr/lib/*.so got there.
I am having the same problem on Gentoo. The way it happens is this: if the module has a conditional dependency on something that would normally be built by jhbuild after the current module, but that dependency is installed with the dev files then configure detects its presence and attempts to use it to link. Now the libtool files for the dependency that is being satisfied by the system will refer to the /usr/lib/*.so files, hence exhibiting the behaviour seen.
I'd also like to note that this in general will be hit by new users of jhbuild as opposed to those that haven't used it before; once you have most of the packages built using jhbuild the issue doesn't show up as much, and gradually gets better each time you run jhbuild (sometimes requiring manual rerunning configure so that it looks in the right locations) as the files get installed. Its just annoying and time consuming to have to keep running through jhbuild. I guess fixing this would require rewriting parts of libtool to modify the way it handles dependencies? I know the common suggested solution is to remove all .la files but this is not an acceptable solution in my case as I run Gentoo which requires the system .la files to build when updating the system.
*** Bug 538794 has been marked as a duplicate of this bug. ***
Wouldn't one way of solving this be to modify the configure scripts of affected modules to check compatibility of the versions of the intersection of libraries that are explicitly linked by the module and those that get pulled in via pkg-config? This would only need to be done for optional dependencies since the jhbuild module dependencies should be sufficient in all other cases.
I got hit by the problem and spent some time looking at it; the problem cames from linking to a system library providing a libtool .la file, that would refer system libraries that would otherwise have been picked from jhbuild prefix. Say there is a module that can link against libnotify, but that library is not part of the jhbuild set. You would have /usr/lib/libnotify.la containing: dependency_libs=' /usr/lib/libgtk-x11-2.0.la ... and those would be used when building in jhbuild. It is enough to remove the offending .la file to avoid this problem. Hopefully distributors will stop distributing .la files.
(In reply to comment #8) > It is enough to remove the offending .la file to avoid this problem. Hopefully > distributors will stop distributing .la files. > This can never happen for distros that compile from source such as Gentoo and thus removing the .la file can't and won't be a permanent solution. The solution has to come as some sort of patch to the configure script (or by disabling the link to the library in question via autogen args but after the first compile then the system is bootstrapped and the problem doesn't show again) since it only occurs when an optional dependency occurs, causing a circular dependency (where one of the links is a weak dependency) if it occurs anywhere else then it is a bug in the jhbuild dependency tree.
Why would it fail on Gentoo? Certainly some .la are necessary (used by KDE for example), but what about libnotify.la? How would Gentoo fail if it was removed? Other distributions are doing fine removing .la files and AFAIK that doesn't prevent sources from being compiled.
Looking into it a bit more it looks like the issue is that .la files are only needed if you're linking static librarys (i.e. .a files) and when linking against .so files they're not needed. IMO libtool should be fixed to not use .la files when it is linking against elf based shared libraries.
Hmmm you don't need .la files at all anywhere. You should be using pkg-config and *.pc files instead. Because with pkg-config you can choose which pkg-config you want to use (system, jhbuild-jail or cross-variant) and none of the configure scripts need changing. Debian Release Goal is to remove all la files and there is good progress on that. pkg-config works for static linking as well. Imho this bug should be "won't-fix", all gnome configuration scripts should use pkg-config. Another possobility is to run jhbuild inside chroot but I don't know whether that would desirable at all though.
I agree with comment 12. Reopen if you disagree.
What about the la files we install ourself ? Those in jhbuild install directory ? And how would the removal of la files prevents linking against a system library in the case outlined at http://gsocblog.jsharpe.net/archives/5 : ie a test in pixman trying to link to gtk which latest version is not yet build by jhbuild. Not against removal of la files . Just that it is not the graal and will not solve all linkage issues (and also that it should not be mandatory). Ie the la files we install ourselves in the jhbuild install directory are no better than the system one when it comes to pointing to the wrong library. For example when a symbol change in gdk and gtk is to be build and use the new symbol the link stage will use the la file from jhbuild install directory which point to the previous installed gdk from our jhbuild which lacks the symbol. So until we stop installing la files ourselves I find it weird to requires distributions to do so .
(In reply to comment #14) > What about the la files we install ourself ? Those in jhbuild install directory > ? And how would the removal of la files prevents linking against a system > library in the case outlined at http://gsocblog.jsharpe.net/archives/5 : ie a > test in pixman trying to link to gtk which latest version is not yet build by > jhbuild. > Let me clarify myself. I'm trying to encorage gnome platform to: 1) replace installation of .la files with installing pc files 2) during configure stage to stop relying on link / libtool tests 3) use pkg-config / PKG_CHECK_* autoconf macros for testing dependency packages instead of libtool. Blunt removal of la files will not prevent against cases outlined on the blog you mention. Blunt addition of pc files will not either. Correct pc.in files need to written and correct pc files should be generated at build time and installed. After that packages that previously depend on .la file (libtool tests) can switch to pkg-config tests for that particular package. And after everyone has switched to pkg-config check the original package can drop shipping la files. > Not against removal of la files . Just that it is not the graal and will not > solve all linkage issues (and also that it should not be mandatory). Ie the la > files we install ourselves in the jhbuild install directory are no better than > the system one when it comes to pointing to the wrong library. You can get it all wrong with pkg-config as well =) except that at least with pkg-config it's much easier to have multiple sys-roots (e.g. cross-compilation or multiple build environments with different complete jhbuilds). Because instead of random libtool order, you point to a correct pkg-config executable + installed .pc file catalog and use that. This way it should just work (TM) =) DESTDIR= often ends up in the la files which totatally can screw up cross-compilation toolchains =/ because they really do use separate build-dir, source-dir, dist-dir and final install-dir. > For example when a symbol change in gdk and gtk is to be build and use the new > symbol the link stage will use the la file from jhbuild install directory which > point to the previous installed gdk from our jhbuild which lacks the symbol. > Same thing will happen with pkg-config. > So until we stop installing la files ourselves I find it weird to requires > distributions to do so . Distributions can do whatever they want =) and at least debian has a release goal of getting rid of them. The "leaf" libraries within build-dependencies had their .la files already removed and slowly debian is working on stopping to ship all of them.
Prahal, Dmitrijs, this is just a jhbuild bug report, even marked as closed, necesseraly not the best venue to discuss changes to the GNOME platform; I'd suggest you mail desktop-devel-list@ instead. Thanks.
Ok about the discussion . Though about this bug it should be documented somewhere that as right now we do not build cairo/test/svg2png.c the issue is hidden. But as soon as this test will be reenabled, with or without la files it will fail again as cairo build before the deps of this test (gdk, librsvg2 are build after cairo via jhbuild). Nothing to do with la files at all.
Sorry Frederic for keeping this going =) So most of the testsuite can run right after cairo module is build (i.e. post-compile tests), while others have additional dependencies, which makes them post-install tests. The testsuite should be split into two and an additional test module should be added to jhbuild modulesets to run this second part of cairo test-suite later on in the build cycle. How many other modules have similar semi-circular dependencies in the test suites? I have no clue how this will play with the buildbot-on-jhbuild-steroids buildfarm.