Sam Varshavchik wrote: > 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 #3 is the policy. https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries (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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
