Re: Packaging policy for libtool .la files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux