[Fedora-packaging] Re: libtool(.la) archive policy proposal

[Toshio Kuratomi]

On Sat, 2006-10-14 at 13:58 +0200, Axel Thimm wrote:
> On Sat, Oct 14, 2006 at 02:45:31PM +0300, Ville Skyttä wrote:
> > On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote:
> > > On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skyttä wrote:
> > >
> > > > ...and in many cases, end up unnecessarily bloating linkage of
> > > > binaries/libs in main packages too, making things like soname changes
> > > > even more painful than they already are...
> > > 
> > > I think the thread made clear that this is not the case.
> > 
> > If it did, I missed it.  Got any pointers to posts that support the
> > above conclusion to share?
> 
> How about this thread? No, honestly check the discussion especially
> Alexandre's posts who goes into the details of both libtool and
> non-libtool library internals.

https://www.redhat.com/archives/fedora-packaging/2006-October/msg00080.html

I think this is the best statement from Alexandre of the facts which he
works out over the course of the message.  I think there are two options
for what to do about it:

A) Get rid of .la's with the possible exception of when static libraries
are kept (maybe this can go along with Ralf's Static Library proposal).
Uses of lt_dlopen("foo.la") are bugs and should be fixed by converting
to lt_dlopenext("foo")

B) Keep all *.la's and create the complete Requires chains specified by
the .la file (could be automated some day.)  And also have Application
packages that use lt_dlopen("foo.la") Require: the chains of library
file *.la's that contain them.  (Which either means application packages
Requiring: *-devel packages or application and main library packages
(libfoo rather than libfoo-devel) holding the *.la's)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20061015/f220910d/attachment.sig>