On P, 2008-11-09 at 18:34 +0200, Peter Alfredsen wrote:
> On Sunday 09 November 2008, Fabian Groffen wrote:
> > On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> > > + # If this is a non-ELF system, chances are good that the .la
> > > files will be needed. +   if type -P scanelf &> /dev/null
> >
> > I think this is a not so cool way to check for an ELF system.
> Indeed, I think it's a horrid way. Please find a better one.
> > > + then
> > > +         debug-print "Scanelf found, proceeding..."
> > > +         ebegin "Removing useless .la files"
> > > +         find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec
> > > rm -f '{}' '+' +          eend 0
> > > + else
> > > +         debug-print "scanelf not found, this appears to be a non-ELF
> > > system." +                debug-print "non-ELF systems are likely to need 
> > > .la
> > > files." +         debug-print ".la files not removed from ${TARGET}"
> >
> > rationale?
> "I've been told" that .la files are really only needed on non-ELF 
> systems and with plugin systems that use dlopen. I actually have no way 
> of knowing that the .la files are needed on those arches, but I had 
> your archs in mind when doing the patch.

I heavily object to having any such function introduced or used or
equivalent .la removals conducted without a good rationale and
explanation of why this is the approach taken. I see no such explanation
anywhere, you are just blatantly removing .la files that the package
itself installs, with no good way to ensure they aren't actually needed
by libltdl and breaking revdep-rebuild heavily when used unwisely.

If such a function is introduced, I'm quite sure it will get used by
some maintainers in revbumps or version bumps, when the library soname
has not changed at all compared to the previous version. What that means
is that the user will get absolutely all packages suggested to
revdep-rebuild that directly OR _indirectly_ rdepend on the library in
question. Therefore to have any relatively safe way to add this, you can
only add the call when the library introduced ABI breaks. Some libraries
are backwards compatible forever, in effect you can't ever add
epunt_la_files to those without causing some serious one-time pain for
users. Therefore this is not a proper solution, and I don't see why this
should be used for just a small set of packages that do have an unstable
ABI while not having a solution for all the rest.

Additionally, I am quite unconvinced on the coverage of the removal or
non-removal of the files. Not removing it on all platforms (because you
can't) also doesn't solve the problem for those non-ELF platforms - you
still will get all the pain you are trying to solve here on those

Also, this would be a local Gentoo specific hack to reduce pain on ELF
systems, while I'm sure there are upstream or better solutions available
that have not been explored. Here are two different ideas of mine for
libtool upstream work to perhaps solve this:

* Get libtool to not include indirectly linked libraries as dependencies
in the .la files if it is running on an ELF system (additionally I think
libtool should have a much better idea if a platform is ELF or not)

* Make libtool not install .la files on ELF platform if it doesn't see
libltdl used

These are just two different ideas, that might not work out, but one of
them might (they are mutually exclusive though).
Ideas like these should be investigated and pursued instead of distro
specific hacks, such as epunt_la_files.

I do however think that it would be a good idea to tweak revdep-rebuild
to not take indirect dependencies listed in .la files too seriously, and
mostly just go by DT_NEEDED entries in ELF files on ELF systems instead
of all of the listed ones in .la ones, as even if a solution for
upstream libtool is figured out, we'd still have old installed .la files
around that include indirect libraries.

Mart Raudsepp
Gentoo Developer
Weblog: http://planet.gentoo.org/developers/leio

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to