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.
Thanks for that. libtool gave me the biggest headache when I experimented with methods to ease cross-compiling and I wasn’t entirely sure what the point of it was. I think I tried modifying the search path but with little success. Some kind of ROOT option would be nice. Getting rid of it altogether would be nicer. 😀
On the topic of libtool, have you seen dolt : http://www.ohloh.net/projec… ?
Jonathan, I didn’t, but it looks interesting, I’ll give it a try as soon as I can.
Yeah those .la files annoys me sometimes. On my server I added .la files to INSTALL_MASK… and well… it’s working fine.It would be great to be able to disable libtool and use only pkg-config. I would help, if a project is started to do this!
I did the same as tuXXX. Packages that broke are imagemagick (plugins), neon, and all of kde.Would be a fun little script to write that would convert all .la files to .pc.
I would very much like to start removing .la files whenever possible. If stuff breaks on ~arch, we can fix it, after all.I’ve added a new revision to sys-libs/pam dropping all .la files, and I’ll probably proceed this way for most of packages I maintain directly and indirectly if their .la file is not needed (as in, can’t be linked statically, or has no static dep).Once that’s done I’ll move to fix the packages that don’t use pkg-config entirely.
Is libtool the root cause of the gcc/revdep-rebuild infamous bug?(gentoo bug #125728)
Yes that’s exactly what is causing that.
Thank you so much. I have been pondering this for some time now. =)
Luckily most of my stuff is .la free. Now if I could find a way to disable .la creation from my autotooled projects I’d be quite happy
Sounds like a good step to remove cruft. I’ll give it a shot and kill my .la-files to see what’s broken.A question is what a good migration path would be. Having a FEATURES=”nolafiles” option and put RESTRICT=”nolafiles” into ebuilds that definitely need to install .la-files?Then brave users can enable that feature and do QA.
it’s an interesting starting point to remove useless staff; i agree with Hanno to have a FEATURES=”nolafiles” for ~arch profiles and do deeper QA tests.
media-sound/pulseaudio-0.9.10-r1 (X alsa asyncns avahi caps dbus glib hal jack libsamplerate lirc tcpd) is broken due to media-libs/libogg-1.1.3-r1 which now removes .la files.
It’s not broken. Just run revdep-rebuild, as you should do anytime something in /usr/lib goes missing!
Thanks, Diego. I agree with every wordyou wrote.
Will this be another mission with a tracker over at bugs.g.o or should this be a mission to go upstream with?
I’ve added ogg mad and popt to /etc/warning for update[1] users.We also need the lib filenames for libmpcdec and pulseaudio, would you know what they are? I’m not sure if the versioning I’ve got there is right, I haven’t run into this on my laptop. Desktop is going back to Gentoo today (don’t ask;) so I’m not going to run into this issue at all; would you mind reviewing the warning file and seeing whether it meets your users’ needs?http://dev.gentooexperiment…These are fairly simple, only needing revdep on the specific library.[1] http://forums.gentoo.org/vi…
Hi,I hate libtool.The stupid program is thinking that some .la file exists at a specific location, but I removed it, and now I can’t compile it. Now I reinstalled the old app, and if the .la is there, libtool works again.I HATE THIS.How can I tell libtool to shut up? Or even better, IS IT POSSIBLE TO GET RID OF LIBTOOL COMPLETELY?This is such a horrid piece of software, it is a shame that linux distributions still use it.Please tell me anyone how to get rid of this steaming pile of crap that is called libtool!
Hi, happy news, it’s now 2012, 4 years later, and it’s pretty much a perfect world on Arch Linux, with regards to .la files. Yay, the world actually moves forward!