The other day I was trying to compile Amarok with the 32-bit compiler, as the Helix engine fails to build with GCC 4.3, and I dislike fixing stuff blindly. The problem with doing this from a 64-bit multilib setup is libtool.
When you do link with libtool to a given library with -lfoo and that library was built and installed with libtool, it will look up the libfoo.la file, and then use that to replace -lfoo option with the path to the library file. The problem is that libtool does not know about the arch the library was built for, and it uses an absolute path. So in most cases your -lfoo will be replaced, on an amd64 multilib system, with /usr/lib64/libfoo.so. Nothing bad unless you’re building a 32-bit ELF file, which will then fail.
But what are .la files used for, nowadays? This is a good question, and one that I’m sure most users and most developers don’t have a full answer for. And are these actually needed? The following two lines you can find in all .la files would suggest so, but I have a different answer.
# Please DO NOT delete this file!
# It is necessary for linking the library.Code language: PHP (php)Let’s start with saying what libtool is/was designed for. Building shared libraries on Unix wasn’t always possible, older Unixes don’t support them, and almost every Unix version has its own way to handle shared libraries. While on today’s Unixes you mostly can just use the -shared option to gcc, this wasn’t always true, and still there are differences in naming scheme for instance between Linux and *BSD and Apple’s Mac OS X (which, even though people try to deny that, is Unix). libtool abstract all these issues.
Unfortunately, libtool is a hugely complex piece of code, and most people using it have no idea how it is supposed to work. The code also takes care of such old and nowadays mostly unused cases that proably a lot of people even knowing how it works wouldn’t know why it is done that way.
One thing libtool has to workaround is the fact that static libraries are just archives, and contain no metadata with respect to linking other libraries together with them (their dependencies). This is what .la archives are used. Unfortunately libtool can’t understand that if you’re not linking static archives you don’t need to provide the dependencies, at least on ELF-based systems, and that causes one of the problems you can get rid of with --as-needed (overlinking).
But .la files are nowadays mostly used by programs using libltdl for plugins loading (like PulseAudio). This is used again to abstract differences between the dynamic loader of different operating systems, like Unix and Windows for instance. This introduces quite some redundancy on Linux and modern *BSD, but it usually doesn’t create as many problems as .la files for shared libraries.
So do we need the .la files to link to the libraries or not? The answer is “not always”. If the library only installs a shared copy of itself, the .la file is unneeded on modern Linux and *BSD systems, if the library also installs a static copy, it might be needed for static linking to work properly, as the library can have extra dependencies.
In a perfect world, every static library needing dependencies would have its own .pc file for pkg-config, and every package trying to statically link to that library would be using pkg-config --static to get the libraries to link to. Unfortunately we’re not in a perfect world.
It would be nice if somebody had enough time to spend to try removing all the *.la files for shared libraries (not for plugins!) on his system, and see what does fail to link statically. I might consider spending some time on that as it would be a really nice improvement, and a good step forward to have one day proper multilib support, but it will have to wait for now. If any user also consider this a nice thing to do, please let me know, if I do see interest in it I’ll try to get more time on that.