You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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

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.

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?

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.

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:

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!