SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
Distribution: PCLinuxOS2023 Fedora38 + 50+ other Linux OS, for test only.
Posts: 17,511
Rep:
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
.
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!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.