GNOME Bugzilla – Bug 464567
Bad -L usage
Last modified: 2009-04-30 09:53:50 UTC
Similar to Bug #464517, there are local -L being passed after global ones, so installed libraries can interfere. There's a general solution for this one, which is to pass explicit paths to the libraries instead of passing -l and relying on the -L ordering. And it's even easier than that...by using libtool convenience libs instead of .a libs, you get automatic dependency tracking when you link.
Looks like there might be a bit of hackery in getting C++ convenience libs linked correctly, but anyway at least you can use parallel constructs for _DEPENDENCIES and _LDADD (I see there are some places where .a are linked but are not listed as dependencies, which can be a problem for parallel-build systems).
Created attachment 93258 [details] [review] Direct paths instead of -l and local -L
Your point is good. Though I think, we should target the problem at a larger level. In my opinion we should just start using libtool to create the libraries, libtool produces nice linker scripts (the .la files) for the created libraries, so we don't have to worry about anything. Regarding the parallel build issue: that's a completely different thing. Please read this: http://miller.emu.id.au/pmiller/books/rmch/ I only build new projects in a non-recursive way since I read that document.
Created attachment 93332 [details] [review] libtoolize the whole project Alright, bullet is bitten, passepartout is switched to libtool (patch against SVN trunk). More flag simplification will be coming tonite/tomorrow...
Created attachment 93462 [details] [review] fully libtoolize With few exceptions (documented internally) all libs link to the other libs that supply symbols that they use, rather than linking each as a stand-alone with undefined symbols and then relying on the binary to link against them all. I had to do some shuffling of the build order so that libs build before things try to link against them and to avoid some circular build-order messes (maybe there's a way to force this with _LIBADD paths instead of relying on SUBDIRS ordering)? I also removed -I for src/ because it is included automatically by automake (it's the dir containing the autoconf .h file).
(In reply to comment #5) > I also removed -I for src/ because it is included automatically by > automake (it's the dir containing the autoconf .h file). In the situation "builddir != srcdir", you'll run into issues. We need $(top_srcdir)/src in the include path, automake will add $(top_builddir)/src for defines.h. So we have to stick with both. I'll split the patch into several parts and commit them today.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. I decided to split up the patch (and do some things differently), but in the end, everything should be fine now.