The long-time followers of my blog will almost surely know of my fight against the pollution from libtool archive (.la) files in Gentoo packages. I already said that they are often useless, or even dangerous when dealing with cross-compilation, and that they create problems that can be solved only with --as-needed (over-linking).
But in particular, I’ve started making the tinderbox warn me when libtool archive files are found in three particular sub-trees where they are absolutely not useful: Python modules, Ruby extensions and PAM plugins. Neither of these use libtool for loading the extensions (for quite obvious reasons), so the .la file is not going to be used for loading; you also shouldn’t link against dynamically-loaded modules (and libtool warns you about that if you try to do it), so the .la file is not used for build-time linking. It’s simply unused.
But it goes even worse than that: the warning has also made me notice that quite a few packages not only install the libtool archive, but build and install a static archive as well! This is not only an extra file installed (and in the search path of those implementations) but also force libtool to build all the source code twice: with and without Position-Independent Code (the static archives are usually non-PIC but shared objects are PIC).
In the bugs I reported for this kind of problems I also linked my own documentation on building plugins with libtool, so maybe the Gentoo developers reaching the bugs would be able to fix both up- and down-stream the issue of double build of both PIC and non-PIC objects. Not that I count on it but it might be possible.
That reminds me that I have just been dealing with a strange issue related to .la files.I’ve been trying to doemerge-i586-mingw32 fontconfigbut it always failed.Lets ignore the fact that fontconfig in its idiocy tries to use the target CFLAGS to compile the programs for the host and get to the libtool stuff.It fails because it tries to install the fontconfig.dll.a file, which does not exist because it disabled generation of dlls.The reason it did disable that is that it could not find a freetype.dll.a.Now the next question is of course why is that missing even though freetype was emerged correctly?The answer is that for it as well libtool disabled generating of dynamic libs (and here without even generating a easily visible warning).And now on to the real cause: a _missing_ .la file!Well, at least I fixed it by adding a libz.la file, because (understandably) libtool can’t figure out that to link libz.a dynamically it has to use libzdll.a and zlib1.dll (who made up that stupid naming scheme??)
Oh and I forgot, of course zlib1.dll ends up in /usr/i586-mingw32/usr/lib whereas all other dlls are in /usr/i586-mingw32/usr/binI am still considering what annoys me more: that getting a MinGW build environment up is such a pain with Gentoo or that it is a far worse pain to get it up natively on Windows or anything else for that matter.Now I just wished I could manage to compile libX11 and libGL for MinGW, but I fear that is a complete utopia…
Hi Diego, you noted that “promiscuous” .la files can create problems that can be solved only with –as-needed (over-linking).Probably i’m incurred on that problem… specifically one of my system has an insane dependency on directfb libraries and seems that even after a lafixer, rebuilding my packages (obviously not related to directfb) doesn’t rid the dependency.I read your documentation on gentoo (http://www.gentoo.org/proj/… and i’d like to know if in your opinion “–as-needed” it’s now more safe for a wide system-use.tnx in advance
Fabio, right now there are about 100 packages that fail with @–as-needed@, but just a bunch of those are very common ones. You can find the list at “the tracker”:http://bugs.gentoo.org/alia… so you can see if your system has any of those installed.Sincerely, I think it’s safe enough, nowadays.
tnx for the quick reply!
Fedora has had a policy to remove all .la files for a while now, and it seems to work out OK. In addition, Fedora is now switching to @–no-as-needed@ as default linker option in rawhide (Fedora’s development version).Maybe it would make sense for Gentoo to do the same?
Argh, of course I made a typo. I wanted to say that Fedora is switching to @–no-add-needed@, but they are still on @–no-as-needed@ as always. (add-needed should be renamed, too easy to confuse.)
Actually, @–no-add-needed@ *has* been renamed already for the next binutils release.And of the two, @–as-needed@ is actually the safest; @–no-add-needed@ has a few more issues; on the other hand, they are most likely doing that since the Google-contributed @gold@ linker has that behaviour by default. We’ve briefly discussed supporting that in Gentoo, and even make it the default as well, but for now it would add extra burden for no visible gain.