Funny how sometimes different people try to fix the same issues at the same time.
First, I’d like to provide a little insight into Libtool and Dolt because a few people have been talking about it for a week or so, but not that many people know what libtool really does, yet everybody agrees on hating it. 
Libtool started as a brilliant idea to have one script that could be used to compile C files and link the resulting object files into whatever we want : executables, static libraries or dynamic libraries. That’s what /usr/bin/libtool does. It’s a cross platform LIBrary TOOL, all in a 218KB shell script. All that code knows about all the C compilers out there, all the linkers and all the subtleties in the command line arguments each and every one supports.
The problem with libtool is that it’s a 218KB shell script. Everytime you build something with an Autotooled project that uses libtool (so basically, all projects that build libraries), for every C file in that project, libtool gets called.
For C++ files, it’s not that big a deal since g++ is quite slow. But for plain C, it’s a whole other issue, as running libtool can sometimes be slower than the actual compiling of the C code it’s used for.
That’s where Dolt kicks in. Basically, Dolt is set up during ./configure and will create a small shell script that takes the same arguments that libtool does. But instead of being 218KB, it’s only going to be a few dozens of lines because ./configure did all the hard work of knowing which compiler and linker are going to be used. Dolt is basically a caching system for libtool. And that’s good.
Now, libtool 2.2 is supposed to be much faster than 1.5.26, and that’s a good thing too because Dolt doesn’t speed up all the operations. Dolt only kicks in for the compiling, not the linking. So all in all, Dolt + libtool-2.2 should be a very good thing for Gentoo users. Let’s hope both gain wide acceptance by upstream projects.
Let’s move on to .la files. Those are text files that everybody has on their systems. Just take a look in /usr/lib, there’s one for almost every .so file. Those are again something libtool creates for the following reasons :
- .la files contain information about both dynamic (.so) and static (.a) libs. .a files unlike ELF .so files do not contain dependencies, so .la files contains those deps. So this is an interesting feature, but mostly aimed for those who need static binaries.
- Dynamic libraries have different naming conventions on different operating systems. .la files make it somewhat easier to be cross-platform.
In theory, .la files are a very good thing… In practice, they hurt us more than they do help solve problems.
- When building applications with dynamic libraries, .la files contain redundant information and therefor are quite useless.
- When using
--as-needed in your LDFLAGS, .la files won’t benefit from the work done by the linker to prune unneeded libraries because .la files are generated by libtool and not the linker. Diego said he would try to write a script that could clean up .la files, but it’s still not a good long-term solution.
- File system pollution… I have 1096 .la files on a “standard” Gentoo systems with Gnome and a few other apps. ‘Nuf said.
“Well, why don’t you remove them? Can’t libtool work correctly without .la files?”
The simple answer is Yes, libtool can work without .la files, but there are exceptions. Basically those include any app that use libtool’s dlopen wrapper library. libltdl expects .la files to work properly, so that’s a PITA. Apps in that category include PulseAudio, Dia (although I’ve fixed it in upstream, awaiting for a new release), … and KDE.
Yep, KDE 3 really sucks on that very point because if you remove KDE’s .la files, it will just not work anymore. I truly hope KDE 4 doesn’t have that flaw (could anyone let me know?).
I have a plan for the Gnome Herd, which I will probably explain when I have some time to work on it 
Hopefully, it should make everyone happy.
Update: I’ve been reminded (and how could I ever forget!) that KDE 4 uses CMake, so it’s thankfully immune to that problem.
