[SOLVED] Libtool's .la files

[loki] · 10-01-2012, 02:00 PM

I would like to know why Slackware dev team chooses to ship certain packages (GConf for example) without the .la files? Is there a way to circumvent the .la files while building?

I am trying to build a Slackbuild (gnome-python-desktop) that links against GConf, but fails because the file cannot be found:

Code:

grep: /usr/lib64/libgconf-2.la: No such file or directory
/usr/bin/sed: can't read /usr/lib64/libgconf-2.la: No such file or directory
libtool: link: `/usr/lib64/libgconf-2.la' is not a valid libtool archive

ponce · 10-01-2012, 02:21 PM

Maybe the problem is in the slackbuilds you are using: I just tried to build it on slackware64-14.0 (all the dependencies too), using the script that you can find in slackbuilds.org's git repository and all went fine.

[loki] · 10-02-2012, 07:20 AM

It is this slackbuild I am using, and it doesn't work. It requires the .la file from GConf. I want to understand why it is looking for the .la file instead of using pkgconfig. I used to have Gnome Slackbuild installed, which did not remove the .la files from the packages. I removed GSB, but I compiled many packages against it that are still on my system. I may have "corrupted" my system in this way?

knudfl · 10-02-2012, 07:58 AM

This is the libgconf-2.la, version 2.28.1.

Should be easy to edit to your version, if different.
It's just a small text file.
You can also write .la files from scratch easily.
Getting files.la : Debian -dev packages :
http://packages.debian.org/squeeze/libgconf2-dev
.

chrisretusn · 10-02-2012, 01:05 PM

I ran in to a similar problem. The .la files are not included in the Slackware package. They are removed in the build script.

Code:

# Don't ship .la files:
rm -f $PKG/usr/lib${LIBDIRSUFFIX}/*.la

Only Pat or someone from the development team will be able to tell us why.

It an easy fix, simply comment out the line in the build script and recompile. That what I did. Worked for me.

[loki] · 10-02-2012, 04:23 PM

I understand that removing this line works appropriately and may be a solution. But for the sake of it, there must be a reason why Pat & the team shun the .la files. I would like to know why, and what would be the correct, or at least the most elegant, solution.

volkerdi · 10-02-2012, 06:12 PM

Quote:

Originally Posted by [loki]

I understand that removing this line works appropriately and may be a solution. But for the sake of it, there must be a reason why Pat & the team shun the .la files. I would like to know why, and what would be the correct, or at least the most elegant, solution.

Most distributions are removing these now, where possible. It's basically another failed dependency system. In some cases, the .la files can absorb references to specific versions of other libraries, and when those are upgraded it causes breakage until everything else is rebuilt. Basically, the exact opposite of how shared libraries are supposed to work. The .la files have caused problems in Slackware in the past as well. There was one of the X revisions that would have been absolutely impossible to build without first removing all of the .la files because after the first library (libX11) was updated, nothing else would build.

There are a (very) few cases where the .la files are needed, generally in cases where they are used alongside plugins rather than shared libraries. But if a program seems to require .la files in order to compile, the odds are that the program is wrong, not the lack of .la files.

In the case of gnome-python-desktop, I can verify that it builds fine without the GConf .la files on a stock Slackware 14.0 system. What this tells me is that very likely GConf was installed previously from some other source (with the .la files). The reference to GConf's .la files then proceeded to infect the .la files of something else that was compiled and installed on the machine, and when GConf was updated to Slackware 14.0's version (without .la files), it created a broken reference that's now breaking some of the compiles on the machine. You might be able to find where the problem is by grepping the .la files on the machine for libgconf-2.la. If you find some, try moving them somewhere else to see if getting them out of the way fixes the compile. Of course... other .la files may reference the ones that reference libgconf-2.la. Which is the exact mess we're trying to avoid by shipping as few .la files as possible (and hopefully someday none at all).

Here's a link to some articles that might shed a bit more light on the subject:

http://blog.flameeyes.eu/tag/lafiles

chrisretusn · 10-03-2012, 01:12 PM

Thanks for the insight and ray of light toward this subject Pat; and to Loki for not accepting the easy way out.

[loki] · 10-04-2012, 11:23 PM

Indeed, thanks to Pat for the explanation. It was exactly what I was looking for.

For the record, I grep'ed the .la files in the /usr/lib64 repertory, looking for references to libgconf-2.la. I moved the files containing mentions of it to a backup repertory, and gnome-python-desktop compiled!