Is there a set of packaging guidelines for libtool's .la files?
There seems to be some inconsistency here.
1) libieee1284 and libieee1284-devel: .la files are installed by libieee1284-devel rpm
2) arts and arts-devel: .la files are installed by the arts rpm
3) gnutls: the spec file removes and does not install the .la files
From what I can tell, #1 should be the policy. I do not believe that .la
files are needed at runtime. libtool uses them only during the compile and link cycle. Furthermore, I'd question the decision to remove them completely, unless having them actually creates a problem.
I needed to work with a newer version of gnutls. I used the spec file and forced _prefix to /usr/local, to have everything installed there.
What I found that even if I properly build and link against /usr/local, at runtime my rpath is not set correctly, and the binary loads /usr/lib64/libgnutls.so.26, instead of /usr/local/lib64/libgnutls.so.26, even though I linked against it. I had to hack out the spec file and put the .la files into libgnutls-devel, so that at linktime, libtool could sprinkle its pixie dust and put the correct rpath into the resulting ELF object.
Sam Varshavchik wrote:
Is there a set of packaging guidelines for libtool's .la files?
There seems to be some inconsistency here.
- libieee1284 and libieee1284-devel: .la files are installed by
libieee1284-devel rpm
arts and arts-devel: .la files are installed by the arts rpm
gnutls: the spec file removes and does not install the .la files
#3 is the policy. https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Librari... (and no, the policy is not only for static libraries).
The KDE 3 plugin loader fails to work if you don't have a .la file for the plugin (it's fixed in KDE 4), this may be why arts installs the .la files, I'll have to check. But other than that, no, they should not be included.
From what I can tell, #1 should be the policy. I do not believe that .la files are needed at runtime. libtool uses them only during the compile and link cycle. Furthermore, I'd question the decision to remove them completely, unless having them actually creates a problem.
It creates a problem: it forces linking indirect dependencies directly and so you have to BuildRequire a lot more -devel packages than actually needed. The unnecessary linkage also slows application loading down at runtime.
I needed to work with a newer version of gnutls. I used the spec file and forced _prefix to /usr/local, to have everything installed there.
This is not supported. Fedora packages are not expected to be relocatable: https://fedoraproject.org/wiki/Packaging:Guidelines#Relocatable_packages In fact, gnutls clearly isn't, which is why you had to rebuild it in the first place, but even rebuilding with a new prefix doesn't fix all the problems.
What I found that even if I properly build and link against /usr/local, at runtime my rpath is not set correctly, and the binary loads /usr/lib64/libgnutls.so.26, instead of /usr/local/lib64/libgnutls.so.26, even though I linked against it. I had to hack out the spec file and put the .la files into libgnutls-devel, so that at linktime, libtool could sprinkle its pixie dust and put the correct rpath into the resulting ELF object.
RPATHs are frowned upon in Fedora: https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
They're also the wrong solution here, what you really want is to have /usr/local/lib64 listed in your ld.so.conf or ld.so.conf.d. I wonder why that isn't the default.
And FWIW I don't think installing to /usr/local is a good solution to make 2 versions of libs coexist. RPMs should not install to /usr/local (and in fact official Fedora RPMs MUST NOT install to /usr/local).
Kevin Kofler
On Sunday 22 February 2009 18:23:35 Kevin Kofler wrote:
Sam Varshavchik wrote:
Is there a set of packaging guidelines for libtool's .la files?
There seems to be some inconsistency here.
- libieee1284 and libieee1284-devel: .la files are installed by
libieee1284-devel rpm
arts and arts-devel: .la files are installed by the arts rpm
gnutls: the spec file removes and does not install the .la files
#3 is the policy. https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Librar ies (and no, the policy is not only for static libraries).
Are you sure it's not only for static libraries? If I understand you correctly then there should be no .la files at all? I have a lot of them:
# find /usr/lib64/ | grep '.la$' | wc -l 376
On Mon, 23 Feb 2009 10:43:53 +0100, Michal wrote:
On Sunday 22 February 2009 18:23:35 Kevin Kofler wrote:
Sam Varshavchik wrote:
Is there a set of packaging guidelines for libtool's .la files?
There seems to be some inconsistency here.
- libieee1284 and libieee1284-devel: .la files are installed by
libieee1284-devel rpm
arts and arts-devel: .la files are installed by the arts rpm
gnutls: the spec file removes and does not install the .la files
#3 is the policy. https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Librar ies (and no, the policy is not only for static libraries).
Are you sure it's not only for static libraries?
The first chapter refers to libtool archives. Not so obvious, but this is linked from within a MUST item in the ReviewGuidelines.
If I understand you correctly then there should be no .la files at all? I have a lot of them:
# find /usr/lib64/ | grep '.la$' | wc -l 376
413 here.
$ rpm -ql gegl|grep '.la$'|wc -l 117 $ rpm -ql ImageMagick | grep '.la$'|wc -l 102
$ find /usr/lib/python2.5/site-packages|grep '.la$'|wc -l 8
It's an indication that hardly any reviewers/packagers follow the guidelines. There are also Merge Reviews missing.
"MS" == Michael Schwendt mschwendt@gmail.com writes:
MS> $ rpm -ql ImageMagick | grep '.la$'|wc -l MS> 102
MS> It's an indication that hardly any reviewers/packagers follow the MS> guidelines.
Very far from fair to mention ImageMagick. The issue was addressed in the ImageMagic merge review, which points back to earlier problems when the .la files were originally removed from the package. The only real sin here is the fact that it's not explicitly documented in the spec file, only mentioned in the changelog entries.
https://bugzilla.redhat.com/show_bug.cgi?id=225897 https://bugzilla.redhat.com/show_bug.cgi?id=185237
"The package breaks without the .la files" is a reasonable exemption to the guidelines. It's pretty easy to see what's going on if you actually look at the merge review instead of simply accusing accusing people of blindly ignoring the guidelines.
- J<
Jason L Tibbitts III wrote:
"MS" == Michael Schwendt mschwendt@gmail.com writes:
MS> $ rpm -ql ImageMagick | grep '.la$'|wc -l MS> 102
MS> It's an indication that hardly any reviewers/packagers follow the MS> guidelines.
Very far from fair to mention ImageMagick. The issue was addressed in the ImageMagic merge review, which points back to earlier problems when the .la files were originally removed from the package. The only real sin here is the fact that it's not explicitly documented in the spec file, only mentioned in the changelog entries.
https://bugzilla.redhat.com/show_bug.cgi?id=225897 https://bugzilla.redhat.com/show_bug.cgi?id=185237
"The package breaks without the .la files" is a reasonable exemption to the guidelines. It's pretty easy to see what's going on if you actually look at the merge review instead of simply accusing accusing people of blindly ignoring the guidelines.
Attaching a patch that allows convert, at least, to work without *.la files installed to show how much coding work is involved in fixing these.
This still leaves several questions, though:
* Is it the packagers job to fix things like this? It's certainly a Fedora-specific packaging policy to remove *.la files, so this is not something that we can force on upstream.
* Is this something we should carry local patches to fix if upstream won't accept our changes?
Note: This patch fixes convert for our purposes but it's not ready to be sent upstream yet. Upstream will want *.la files to work on platforms that are more limited than we are and can't support loading directly from the *.so file. Also, there's a couple uses of lt_dlopen() that might better be reqorked to lt_dlopenext() if upstream is amenable.
-Toshio
On Mon, 23 Feb 2009 10:52:11 -0800, Toshio wrote:
- Is it the packagers job to fix things like this? It's certainly a
Fedora-specific packaging policy to remove *.la files, so this is not something that we can force on upstream.
Libtool archives in private plugin/modules directories are harmless as they are located outside build-time linker's search path. Such directories must never be added to the search path via -L.
When these files are built, you just need to make sure that no inter-library dependencies on external .la files are inserted, which may break later when those files are removed.
On Mon, 2009-02-23 at 10:52 -0800, Toshio Kuratomi wrote:
This still leaves several questions, though:
- Is it the packagers job to fix things like this? It's certainly a
Fedora-specific packaging policy to remove *.la files, so this is not something that we can force on upstream.
Yes, definitely. A packager _needs_ to be capable of at least this much, if he/she is going to capably maintain the package.
If not, he/she should find a comaintainer who will help.
- Is this something we should carry local patches to fix if upstream
won't accept our changes?
That'll vary from case to case, but probably; yes.
On Mon, 23 Feb 2009 10:43:34 -0600, Jason wrote:
MS> $ rpm -ql ImageMagick | grep '.la$'|wc -l MS> 102
MS> It's an indication that hardly any reviewers/packagers follow the MS> guidelines.
Very far from fair to mention ImageMagick.
Sorry, I had searched rpm --changelog for just "libtool". Searching for ".la" would have caught it. For a moment I wanted to point also at imlib2, but in its changelog I saw that it was me who added back the libtool archives some years ago.
Michal Hlavinka wrote:
Are you sure it's not only for static libraries?
Yes, I am: | Libtool archives, foo.la files, should not be included. Packages using | libtool will install these by default even if you configure | with --disable-static, so they may need to be removed before packaging.
--disable-static means the package is built only shared, but the guidelines talk about removing .la files even there. In fact the whole point is that on GNU/Linux, .la files are only ever needed for static linking (and even there not always).
If I understand you correctly then there should be no .la files at all?
Ideally yes, but there's this exception: | Due to bugs in older versions of libtool or bugs in programs that use it, | there are times when it is not always possible to remove *.la files | without modifying the program. In most cases it is fairly easy to work | with upstream to fix these issues. e.g. KDE 3 plugins (not libraries) need .la files (this is fixed in KDE 4, which got rid of libtool and libltdl entirely).
Kevin Kofler