[gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1.1: Type: text/plain, Size: 170 bytes --]

I attach here a proposed new function for eutils.eclass. Review 
requested. Thanks to zlin and igli for initial review and suggestions 
on #gentoo-dev-help.
-- 
/PA

[-- Attachment #1.2: eutils.eclass.patch --]
[-- Type: text/x-diff, Size: 1398 bytes --]

--- /usr/portage/eclass/eutils.eclass	2008-09-28 07:06:15.000000000 +0200
+++ eutils1.eclass	2008-11-06 22:22:51.000000000 +0100
@@ -1805,5 +1805,37 @@
 		) || die
 	else
 		newbin "${tmpwrapper}" "${wrapper}" || die
 	fi
 }
+
+# @FUNCTION: epunt_la_files
+# @USAGE: [dir to scan]
+# @DESCRIPTION:
+# .la files can cause many unpleasantries when they disappear,
+# forcing rebuilds of seemingly unrelated packages.
+# This function removes the .la files from [dir to scan], "${D}" if not set.
+# A good time to start punting .la files may be when a .so bump happens,
+# so dependent packages do not have to be rebuilt twice.
+#
+# See also:
+# bug 245889
+# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
+
+epunt_la_files() {
+	debug-print-function $FUNCNAME "$@"
+	local TARGET=$1
+	[ -z "${TARGET}" ] && TARGET="${D}"
+
+	# If this is a non-ELF system, chances are good that the .la files will be needed.
+	if type -P scanelf &> /dev/null
+	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}"
+	fi
+}

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Fabian Groffen]

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.

> +	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?


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

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.

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Fabian Groffen]

On 09-11-2008 18:34:31 +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.

% uname -a
Darwin tefnut.cheops.ods.org 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc PowerMac8,2 Darwin
% scanelf --version
pax-utils-0.1.18_pre0004: scanelf.c compiled Oct 19 2008
$Id: scanelf.c,v 1.194 2008/09/29 06:05:55 vapier Exp $
scanelf written for Gentoo by <solar and vapier @ gentoo.org>
% scanmacho --version
pax-utils-0.1.18_pre0004: scanmacho.c compiled Oct 19 2008
$Id: scanmacho.c,v 1.5 2008/10/19 18:11:59 grobian Exp $
scanmacho written for Gentoo by <solar, vapier and grobian @ gentoo.org>

You could identify ELF a bit more reliable by running file on e.g.
"${ROOT}/bin/bash", or just by building a list of CHOSTs that you know
are ELF systems.

> > > +		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.

Ok.  What worries me though is that this would result in some systems
having libtool files whereas the majority does not.  E.g. removing them
apparently fixes a problem that then crops up on those systems or
something.  Can't think of any atm.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1.1: Type: text/plain, Size: 1159 bytes --]

On Sunday 09 November 2008, Fabian Groffen wrote:

> You could identify ELF a bit more reliable by running file on e.g.
> "${ROOT}/bin/bash", or just by building a list of CHOSTs that you
> know are ELF systems.

D'oh, should have thought of that. See attached patch.

> > > > +		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.
>
> Ok.  What worries me though is that this would result in some systems
> having libtool files whereas the majority does not.  E.g. removing
> them apparently fixes a problem that then crops up on those systems
> or something.  Can't think of any atm.

I can. If you have .la files, you will need to revdep-rebuild a lot 
more. But c'est la vie.

-- 
/PA

[-- Attachment #1.2: eutils.eclass.patch --]
[-- Type: text/x-diff, Size: 1397 bytes --]

--- /usr/portage/eclass/eutils.eclass	2008-09-28 07:06:15.000000000 +0200
+++ eutils1.eclass	2008-11-09 18:26:44.000000000 +0100
@@ -1805,5 +1805,37 @@
 		) || die
 	else
 		newbin "${tmpwrapper}" "${wrapper}" || die
 	fi
 }
+
+# @FUNCTION: epunt_la_files
+# @USAGE: [dir to scan]
+# @DESCRIPTION:
+# .la files can cause many unpleasantries when they disappear,
+# forcing rebuilds of seemingly unrelated packages.
+# This function removes the .la files from [dir to scan], "${D}" if not set.
+# A good time to start punting .la files may be when a .so bump happens,
+# so dependent packages do not have to be rebuilt twice.
+#
+# See also:
+# bug 245889
+# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
+
+epunt_la_files() {
+	debug-print-function $FUNCNAME "$@"
+	local TARGET=$1
+	[ -z "${TARGET}" ] && TARGET="${D}"
+
+	# If this is a non-ELF system, chances are good that the .la files will be needed.
+	if [[ "$(file ${ROOT}/bin/bash)" =~ " ELF " ]]
+	then
+		debug-print "ELF system found, proceeding..."
+		ebegin "Removing useless .la files"
+		find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+'
+		eend 0
+	else
+		debug-print "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}"
+	fi
+}

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Fabian Groffen]

On 09-11-2008 19:46:12 +0200, Peter Alfredsen wrote:
> > Ok.  What worries me though is that this would result in some systems
> > having libtool files whereas the majority does not.  E.g. removing
> > them apparently fixes a problem that then crops up on those systems
> > or something.  Can't think of any atm.
> 
> I can. If you have .la files, you will need to revdep-rebuild a lot 
> more. But c'est la vie.

I meant I can't think of an issue when there is no .la file.


> --- /usr/portage/eclass/eutils.eclass	2008-09-28 07:06:15.000000000 +0200
> +++ eutils1.eclass	2008-11-09 18:26:44.000000000 +0100
> @@ -1805,5 +1805,37 @@
>  		) || die
>  	else
>  		newbin "${tmpwrapper}" "${wrapper}" || die
>  	fi
>  }
> +
> +# @FUNCTION: epunt_la_files
> +# @USAGE: [dir to scan]
> +# @DESCRIPTION:
> +# .la files can cause many unpleasantries when they disappear,
> +# forcing rebuilds of seemingly unrelated packages.
> +# This function removes the .la files from [dir to scan], "${D}" if not set.
> +# A good time to start punting .la files may be when a .so bump happens,
> +# so dependent packages do not have to be rebuilt twice.
> +#
> +# See also:
> +# bug 245889
> +# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
> +
> +epunt_la_files() {
> +	debug-print-function $FUNCNAME "$@"
> +	local TARGET=$1
> +	[ -z "${TARGET}" ] && TARGET="${D}"
> +
> +	# If this is a non-ELF system, chances are good that the .la files will be needed.
> +	if [[ "$(file ${ROOT}/bin/bash)" =~ " ELF " ]]
> +	then
> +		debug-print "ELF system found, proceeding..."
> +		ebegin "Removing useless .la files"
> +		find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+'
> +		eend 0
> +	else
> +		debug-print "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}"
> +	fi
> +}




-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 4055 bytes --]

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
platforms.

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
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1: Type: text/plain, Size: 4369 bytes --]

On Wednesday 12 November 2008, Mart Raudsepp wrote:

> 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.

It's a utility function. I've done all I can to ensure it'll be used 
wisely. Whether it is used wisely is between you and ( $ROOT or $666 ). 
But let me point out that in most leaf-packages, removing la files will 
cause no pain, but will ensure that they do not have to be rebuilt if 
a .la-listed dependency loses its .la file.

> 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.

Because having la files will automagically provide the equivalent amount 
of pain such as in http://bugs.gentoo.org/245889 .
We talked about this on #gentoo-dev the other day. 200 packages out of 
1000 on my system had to be rebuilt because of this. If libxcb didn't 
use la files, that wouldn't have been necessary for the majority of 
those. If the packages themselves didn't use la files, it wouldn't have 
been necessary either.

fix_libtool_files.sh also doesn't play nice with .la files and will 
leave orphan .la files around.

In other words, it's no a question of IF .la files will break stuff but 
WHEN they will break stuff. And how BIG the breakage will be. We can 
remedy the last part by having leaf packages not install .la files and 
by punting library .la files when a .so bump occurs or (as in the case 
of libxcb) when other .la-related breakage occurs.

(Who doesn't remember "The Day the Build Servers were Silenced..." )
http://bugs.debian.org/354674

> 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 platforms.

As those platforms are still not supported by Gentoo as such, but by the 
Gentoo/Alt project, that is not really a problem we should be worrying 
about. That part of the function is a good-faith effort to not 
unnecessarily break stuff for Gentoo/Alt users, nothing more. If they 
later discover that some of their non-ELF platforms can do without .la 
files, they can just wiggle the code and make it so.

> 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:
[Snip good ideas]

Plz2implent. Kthxbye.

But you've still not given a good reason why this function in itself is 
bad.

> 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.

That would cause breakage. There's a reason why revdep-rebuild rebuilds. 
Libtool will look for those la files and fail the compile.

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Rémi Cardona]

Le 12/11/2008 15:40, Peter Alfredsen a écrit :
> But let me point out that in most leaf-packages, removing la files will
> cause no pain, but will ensure that they do not have to be rebuilt if
> a .la-listed dependency loses its .la file.

Mart, others and myself have already tried removing .la files to "see 
what would break". And it breaks a whole lot more than we anticipated.

Among others, it breaks KDE3 (all of it), pulseaudio, the current 
version of app-office/dia, and many more which I can't remember.

In a perfect world, there would be no need for .la files. But we're far 
from that perfect world. I think it's best we provide a better solution.

Mart had already proposed a "static-lib" USE flag. Donnie just suggested 
on IRC we turn this use flag into a FEATURES flag.

I think those are much better options than just using this function in 
some ebuilds.

Cheers :)

Rémi

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Wednesday 12 November 2008, Rémi Cardona wrote:
> Le 12/11/2008 15:40, Peter Alfredsen a écrit :
> > But let me point out that in most leaf-packages, removing la files
> > will cause no pain, but will ensure that they do not have to be
> > rebuilt if a .la-listed dependency loses its .la file.
>
> Mart, others and myself have already tried removing .la files to "see
> what would break". And it breaks a whole lot more than we
> anticipated.
>
> Among others, it breaks KDE3 (all of it), pulseaudio, the current
> version of app-office/dia, and many more which I can't remember.

That's known. So we just don't remove .la files from those.
(I think pulseaudio is fixed, actually.)

> In a perfect world, there would be no need for .la files. But we're
> far from that perfect world. I think it's best we provide a better
> solution.

The problem is that in the world where we do live, .la files are needed 
some places and a pain in the ass other places, so blanket solutions 
will not work.

> Mart had already proposed a "static-lib" USE flag. Donnie just
> suggested on IRC we turn this use flag into a FEATURES flag.

That's problematic. You can't turn off a FEATURES flag for individual 
packages. See above.

> I think those are much better options than just using this function
> in some ebuilds.

I think it would make sense to have a static-libs USE flag and couple it 
with use of epunt_la_files where it's appropriate. FEATURES flag, no. 
The package maintainer decides which files get installed, noone else. 

With a FEATURES flag, we would break the whole tree and then need to fix 
it up with RESTRICT=no-static-libs for every individual ebuild where it 
fails. Tedious and not really worth our time. By selectively doing 
this, we can do it intelligently and over time, minimizing the 
inconvenience to users.

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

On 18:16 Wed 12 Nov     , Peter Alfredsen wrote:
> On Wednesday 12 November 2008, Rémi Cardona wrote:
> > Mart had already proposed a "static-lib" USE flag. Donnie just
> > suggested on IRC we turn this use flag into a FEATURES flag.
> 
> That's problematic. You can't turn off a FEATURES flag for individual 
> packages. See above.

Except for RESTRICT as you mention below...

> > I think those are much better options than just using this function
> > in some ebuilds.
> 
> I think it would make sense to have a static-libs USE flag and couple it 
> with use of epunt_la_files where it's appropriate. FEATURES flag, no. 
> The package maintainer decides which files get installed, noone else. 

If people want to compile an app statically (e.g. for embedded use, for 
portability to unknown systems, etc), Gentoo should enable them to do 
so. It shouldn't enable them to do so in erratic cases and randomly fail 
in others because the libtool archives are randomly distributed.

> With a FEATURES flag, we would break the whole tree and then need to fix 
> it up with RESTRICT=no-static-libs for every individual ebuild where it 
> fails. Tedious and not really worth our time. By selectively doing 
> this, we can do it intelligently and over time, minimizing the 
> inconvenience to users.

If anything, this suggestion is far more tedious because it requires 
modifications to orders of magnitude more ebuilds if we want to globally 
avoid libtool archives.

Have a FEATURES flag that is not on by default but is enabled by the 
developer profile, and I bet you'd find whatever needs a RESTRICT that 
we don't already know about pretty quick.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Gilles Dartiguelongue]

Le mercredi 12 novembre 2008 à 18:16 +0100, Peter Alfredsen a écrit :
[snip]
> > Mart had already proposed a "static-lib" USE flag. Donnie just
> > suggested on IRC we turn this use flag into a FEATURES flag.
> 
> That's problematic. You can't turn off a FEATURES flag for individual 
> packages. See above.

yes you can, can't find the related doc (it's not in portage man), but
that's what /etc/portage/env/ can do for you.

-- 
Gilles Dartiguelongue <eva@gentoo.org>

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Marius Mauch]

On Fri, 14 Nov 2008 11:35:44 +0100
Gilles Dartiguelongue <eva@gentoo.org> wrote:

> Le mercredi 12 novembre 2008 à 18:16 +0100, Peter Alfredsen a écrit :
> [snip]
> > > Mart had already proposed a "static-lib" USE flag. Donnie just
> > > suggested on IRC we turn this use flag into a FEATURES flag.
> > 
> > That's problematic. You can't turn off a FEATURES flag for
> > individual packages. See above.
> 
> yes you can, can't find the related doc (it's not in portage man), but
> that's what /etc/portage/env/ can do for you.

Only for some FEATURES though (depending on where they are implemented).

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Hi,

> (I think pulseaudio is fixed, actually.)

For what it's worth: removing the .la files from pulseaudio breaks its
module loading on freebsd; and it's an elf system. I don't know what
you mean by fixed and I didn't investigate this but restoring the .la
files in the ebuild allowed me to make it load its plugins. Maybe
that's another issue or maybe there's something we have forgotten about
the .la files; I think pulseaudio uses libltdl and iirc these was a
case where the .la files were needed at runtime.

Imho, the only option for punting .la files are the ones that are
opt-in, opt-out ones should be discarded. Having it as a feature is
opt-out and will break anything that needs it and doesn't have the
restrict yet. On the other hand, maybe this could be some property like
"la_files_can_be_punted" which is, as i understand it, the opt-in
version of restrict.

Moreover .la files are good when you want to link statically to some
library because they carry the needed information; they should be
punted only when said library provides a good alternative (like a .pc
file with correct libs.private field).


Regards,


Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Rémi Cardona]

Alexis Ballier a écrit :
> Hi,
> 
>> (I think pulseaudio is fixed, actually.)
> 
> For what it's worth: removing the .la files from pulseaudio breaks its
> module loading on freebsd; and it's an elf system. I don't know what
> you mean by fixed 

It's not fixed and it can't be. libtool's cross-platform dlopen()
wrapper library (libltdl) needs .la files even on ELF systems.

The only way to fix this is to use dlopen() instead...

Cheers

Rémi

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Michael Haubenwallner]

On Fri, 2008-11-14 at 15:35 +0100, Rémi Cardona wrote:
> Alexis Ballier a écrit :
> > Hi,
> > 
> >> (I think pulseaudio is fixed, actually.)
> > 
> > For what it's worth: removing the .la files from pulseaudio breaks its
> > module loading on freebsd; and it's an elf system. I don't know what
> > you mean by fixed 
> 
> It's not fixed and it can't be. libtool's cross-platform dlopen()
> wrapper library (libltdl) needs .la files even on ELF systems.
> 
> The only way to fix this is to use dlopen() instead...

Never *unconditionally* switch back from libltdl to dlopen&co in source
code, as it is likely to break many non-linux platforms (Darwin, AIX,
HP-UX, ...).

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Rémi Cardona]

Le 16/11/2008 09:44, Michael Haubenwallner a écrit :
> Never *unconditionally* switch back from libltdl to dlopen&co in source
> code, as it is likely to break many non-linux platforms (Darwin, AIX,
> HP-UX, ...).

I perfectly know this. My comment was *exactly* made to point out that 
we cannot fix any of this without fixing libtool itself. There's *no* 
way to workaround the issue.

Cheers

Rémi

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On 15:25 Fri 14 Nov     , Alexis Ballier wrote:
> Moreover .la files are good when you want to link statically to some
> library because they carry the needed information; they should be
> punted only when said library provides a good alternative (like a .pc
> file with correct libs.private field).

Perhaps writing a .la to .pc converter would be a worthwhile endeavor.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Fri, 14 Nov 2008 14:31:56 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 15:25 Fri 14 Nov     , Alexis Ballier wrote:
> > Moreover .la files are good when you want to link statically to some
> > library because they carry the needed information; they should be
> > punted only when said library provides a good alternative (like
> > a .pc file with correct libs.private field).
> 
> Perhaps writing a .la to .pc converter would be a worthwhile endeavor.

One of these things is not like the other.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[David Leverton]

On Friday 14 November 2008 14:25:30 Alexis Ballier wrote:
> Moreover .la files are good when you want to link statically to some
> library because they carry the needed information; they should be
> punted only when said library provides a good alternative (like a .pc
> file with correct libs.private field).

Even if the .pc file exists and is fully correct, removing the .la file still 
breaks any application that links statically and relies on libtool to deal 
with library dependencies, rather than using pkg-config (and there's no 
reason why an application /shouldn't/ do that - after all, it works perfectly 
with the library as upstream released it).  Maybe we think it's worth the 
effort to tweak the application's build system (there probably won't be all 
that many applications that need it, after all), but this /is/ an 
incompatible change to the library, and if we're going to do it, we should at 
least be aware of what we're doing.

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 6134 bytes --]

On K, 2008-11-12 at 15:40 +0100, Peter Alfredsen wrote:
> On Wednesday 12 November 2008, Mart Raudsepp wrote:
> 
> > 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.
> 
> It's a utility function. I've done all I can to ensure it'll be used 
> wisely. Whether it is used wisely is between you and ( $ROOT or $666 ). 
> But let me point out that in most leaf-packages, removing la files will 
> cause no pain, but will ensure that they do not have to be rebuilt if 
> a .la-listed dependency loses its .la file.

Unless a system happens to have USE=static used for a few lower level
indirect dependencies (and those very low level libraries having such an
option is sometimes, albeit rarely, quite cool for embedded use cases).
It just breaks then according to other subthreads, and you have no way
to really check for that in your utility function.

> > 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.
> 
> Because having la files will automagically provide the equivalent amount 
> of pain such as in http://bugs.gentoo.org/245889 .

There is still no solution for things that do not break ABI, but get
rebuilt with different USE flags, for example the USE=esd fiasco where
to get rid of esound you had to remove USE=esd and rebuild many packages
with revdep-rebuild for no reason other than libtool being stupid. This
stupidity should be fixed, not delayed with workarounds to a small
subset of cases.

> We talked about this on #gentoo-dev the other day. 200 packages out of 
> 1000 on my system had to be rebuilt because of this. If libxcb didn't 
> use la files, that wouldn't have been necessary for the majority of 
> those. If the packages themselves didn't use la files, it wouldn't have 
> been necessary either.

Or if libtool would be fixed to not cause that pain in the first place..

> fix_libtool_files.sh also doesn't play nice with .la files and will 
> leave orphan .la files around.

That's something that can be fixed.

> In other words, it's no a question of IF .la files will break stuff but 
> WHEN they will break stuff. And how BIG the breakage will be. We can 
> remedy the last part by having leaf packages not install .la files and 
> by punting library .la files when a .so bump occurs or (as in the case 
> of libxcb) when other .la-related breakage occurs.
> 
> (Who doesn't remember "The Day the Build Servers were Silenced..." )
> http://bugs.debian.org/354674
> 
> > 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 platforms.
> 
> As those platforms are still not supported by Gentoo as such, but by the 
> Gentoo/Alt project, that is not really a problem we should be worrying 
> about.

I do worry about projects that make us better than other distributions,
by being able to do things that are not possible elsewhere.

> That part of the function is a good-faith effort to not 
> unnecessarily break stuff for Gentoo/Alt users, nothing more. If they 
> later discover that some of their non-ELF platforms can do without .la 
> files, they can just wiggle the code and make it so.

> > 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:
> [Snip good ideas]
> 
> Plz2implent. Kthxbye.
> 
> But you've still not given a good reason why this function in itself is 
> bad.

It is the worst solution to a problem out of different possibilities for
a solution - that should be enough. If not, well, I guess I'll have to
suffer with the consequences of weird problems we have not discovered
yet and a suboptimal solution making a proper one not happen anytime
soon.

No, I do not have time to look into implementing something proper in
libtool before a couple of weekends.

> > 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.
> 
> That would cause breakage. There's a reason why revdep-rebuild rebuilds. 
> Libtool will look for those la files and fail the compile.

Fixed and generalized fix_libtool_files.sh or fixed libtool?


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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

On Wednesday 12 November 2008, Mart Raudsepp wrote:
> On K, 2008-11-12 at 15:40 +0100, Peter Alfredsen wrote:

> > It's a utility function. I've done all I can to ensure it'll be
> > used wisely. Whether it is used wisely is between you and ( $ROOT
> > or $666 ). But let me point out that in most leaf-packages,
> > removing la files will cause no pain, but will ensure that they do
> > not have to be rebuilt if a .la-listed dependency loses its .la
> > file.
>
> Unless a system happens to have USE=static used for a few lower level
> indirect dependencies (and those very low level libraries having such
> an option is sometimes, albeit rarely, quite cool for embedded use
> cases). It just breaks then according to other subthreads, and you
> have no way to really check for that in your utility function.

My English fails me here. To me it's not clear which cases of breakage 
we're speaking of here (subthreads in that context?). An example 
perhaps?

> There is still no solution for things that do not break ABI, but get
> rebuilt with different USE flags, for example the USE=esd fiasco
> where to get rid of esound you had to remove USE=esd and rebuild many
> packages with revdep-rebuild for no reason other than libtool being
> stupid. This stupidity should be fixed, not delayed with workarounds
> to a small subset of cases.

I disagree. Just because you can have a feast tomorrow doesn't mean that 
you should abstain from eating today.

> > We talked about this on #gentoo-dev the other day. 200 packages out
> > of 1000 on my system had to be rebuilt because of this. If libxcb
> > didn't use la files, that wouldn't have been necessary for the
> > majority of those. If the packages themselves didn't use la files,
> > it wouldn't have been necessary either.
>
> Or if libtool would be fixed to not cause that pain in the first
> place..

That would indeed be nice. Please convince me that you can implement an 
upstreamable solution within 2 months time and I won't be needing this 
function.

[Snip more pie-in-the-sky]

Show me the code, please.

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Wed, 12 Nov 2008 18:31:47 +0100
Peter Alfredsen <loki_val@gentoo.org> wrote:

> On Wednesday 12 November 2008, Mart Raudsepp wrote:
> > There is still no solution for things that do not break ABI, but get
> > rebuilt with different USE flags, for example the USE=esd fiasco
> > where to get rid of esound you had to remove USE=esd and rebuild
> > many packages with revdep-rebuild for no reason other than libtool
> > being stupid. This stupidity should be fixed, not delayed with
> > workarounds to a small subset of cases.
> 
> I disagree. Just because you can have a feast tomorrow doesn't mean
> that you should abstain from eating today.

Well, you won't make it to the feast if you're stuck at the dam,
plugging all the holes with your fingers.

> > > We talked about this on #gentoo-dev the other day. 200 packages
> > > out of 1000 on my system had to be rebuilt because of this. If
> > > libxcb didn't use la files, that wouldn't have been necessary for
> > > the majority of those. If the packages themselves didn't use la
> > > files, it wouldn't have been necessary either.
> >
> > Or if libtool would be fixed to not cause that pain in the first
> > place..
> 
> That would indeed be nice. Please convince me that you can implement
> an upstreamable solution within 2 months time and I won't be needing
> this function.
> 
> [Snip more pie-in-the-sky]
> 
> Show me the code, please.

If you weren't interested in hearing differing opinions, then why did
you ask in the first place?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On Wed, 12 Nov 2008 18:31:47 +0100
Peter Alfredsen <loki_val@gentoo.org> wrote:

> On Wednesday 12 November 2008, Mart Raudsepp wrote:  
> > There is still no solution for things that do not break ABI, but get
> > rebuilt with different USE flags, for example the USE=esd fiasco
> > where to get rid of esound you had to remove USE=esd and rebuild
> > many packages with revdep-rebuild for no reason other than libtool
> > being stupid. This stupidity should be fixed, not delayed with
> > workarounds to a small subset of cases.  
> 
> I disagree. Just because you can have a feast tomorrow doesn't mean
> that you should abstain from eating today.  

Well, you won't make it to the feast if you're stuck at the dam,
plugging all the holes with your fingers.

> > > We talked about this on #gentoo-dev the other day. 200 packages
> > > out of 1000 on my system had to be rebuilt because of this. If
> > > libxcb didn't use la files, that wouldn't have been necessary for
> > > the majority of those. If the packages themselves didn't use la
> > > files, it wouldn't have been necessary either.  
> >
> > Or if libtool would be fixed to not cause that pain in the first
> > place..  
> 
> That would indeed be nice. Please convince me that you can implement
> an upstreamable solution within 2 months time and I won't be needing
> this function.
> 
> [Snip more pie-in-the-sky]
> 
> Show me the code, please.  

If you weren't interested in hearing differing opinions, then why did
you ask in the first place? :P

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]

On Friday 14 November 2008, Ryan Hill wrote:
> > [Snip more pie-in-the-sky]
> >
> > Show me the code, please.  
>
> If you weren't interested in hearing differing opinions, then why did
> you ask in the first place? :P

I just thought it sounded like a tall order, saying that fixing 
libtool .la files would take some weekends to do, when this problem has 
existed for so long, yet noone has been able to fix it in a way that 
causes less pain than removal of all .la files does. IOW, I will 
believe promises of code when I see it.

I won't be touching libtool. You can break that thing by just looking at 
it the wrong way. It'll eval your buttocks off and expr your behind, 
it's .3 MB of all posix-sh and it will make you regret you ever tried 
to wrap your head around it.

[in re pulseaudio, I believed the news for 0.9.1 
http://www.pulseaudio.org/wiki/OldNews]

[Responding to the rest of the thread]

I've given this some thought and I think I've been convinced that 
dberkholz' position is probably the most tenable. If this is to be 
done, we should do it in a documented "Gentooish" way. The problem with 
going down the FEATURES road are two-fold:
1) What should the behavior of the FEATURES flag be?

I think it should act like an INSTALL_MASK="*.la" and 
EXTRA_ECONF="--disable-static"

There should also be a function, let's call it "exemptthis.la" that 
would exempt a .la file from being punted, so the RESTRICT could be 
made on a per-la file basis.

2) Who implements in portage?

[...I know nothing of portage internals...]

3) Grunt work?

This should be rather easy. Just assign the bugs to me and I shall add 
RESTRICTs as-needed.

But the problem is that we've known about this for aeons and nothing has 
been done about it. Diego tried to do something with popt and another 
package some time ago (bug 218286) but he was mostly shouted down and 
nobody touched it since.

On .so bumps I've silently dropped .la files, which I think is the more 
gradualistic approach and it also has the advantage of causing only 
little or no (extra) breakage, but for the whole tree it could take 
decades, since some libs don't do .so bumps. 

Anyway, we really need to start punting .la files one way or the other. 
For desktop users of our distro, they do a lot more harm than good. For 
embedded, perhaps static linking serves some purpose, but really, if 
you can't afford dynamic linking, what are you going to run on your 
board?

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On Sat, 15 Nov 2008 00:05:52 +0100
Peter Alfredsen <loki_val@gentoo.org> wrote:
> I just thought it sounded like a tall order, saying that fixing 
> libtool .la files would take some weekends to do, when this problem
> has existed for so long, yet noone has been able to fix it in a way
> that causes less pain than removal of all .la files does.

Sometimes, doing nothing is better than doing something.

> Anyway, we really need to start punting .la files one way or the
> other. For desktop users of our distro, they do a lot more harm than
> good. For embedded, perhaps static linking serves some purpose, but
> really, if you can't afford dynamic linking, what are you going to
> run on your board?

No, for desktop users they're occasionally a minor inconvenience,
which is more than offset by the large inconvenience of their removal.

Unfortunately, enough fuss has been made about this that too many
people will look bad if it's decided to do nothing, so things have
reached the "find the least bad something to do" stage...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

On Sat, 2008-11-15 at 00:05 +0100, Peter Alfredsen wrote:
> Anyway, we really need to start punting .la files one way or the other. 
> For desktop users of our distro, they do a lot more harm than good. For 
> embedded, perhaps static linking serves some purpose, but really, if 
> you can't afford dynamic linking, what are you going to run on your 
> board?

Just to quickly explain the purpose of static linking on embedded - it
has nothing to do with avoiding dynamic linking (run-time?) cost, it has
everything to do with size. If you have a library that only one or few
applications use, you can end up with smaller size through static
linking it, rather than using a shared library of it.
This is because during static linking all functions that are not used
can be discarded from the final binary, while with shared libraries all
the code has to remain, because it isn't know what will be using that
shared library, so the toolchain can not safely discard anything, even
if you just have one application using some big library, but only using
a small subset of its functionality.


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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass

[Duncan]

Mart Raudsepp <leio@gentoo.org> posted 1226708812.12338.3.camel@localhost,
excerpted below, on  Sat, 15 Nov 2008 02:26:52 +0200:

> This is because during
> static linking all functions that are not used can be discarded from the
> final binary, while with shared libraries all the code has to remain,
> because it isn't know what will be using that shared library

That was a very useful explanation.  Thanks!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Re: Please review: function epunt_la_files for eutils.eclass

[Steve Long]

Peter Alfredsen wrote:

> I've given this some thought and I think I've been convinced that
> dberkholz' position is probably the most tenable. If this is to be
> done, we should do it in a documented "Gentooish" way. The problem with
> going down the FEATURES road are two-fold:
> 1) What should the behavior of the FEATURES flag be?
> 
> I think it should act like an INSTALL_MASK="*.la" and
> EXTRA_ECONF="--disable-static"
> 
> There should also be a function, let's call it "exemptthis.la" that
> would exempt a .la file from being punted, so the RESTRICT could be
> made on a per-la file basis.
>
If it's a FEATURE defaulting to off, which makes sense from the opt-in
perspective, surely a simple Property would do the job for most cases?
 
> 2) Who implements in portage?
> 
> [...I know nothing of portage internals...]
>
Properties are bedded in, all you need is a bit of BASH, to be run for those
packages you maintain; and to add the functionality you mentioned above,
etc.
 
> 3) Grunt work?
> 
> This should be rather easy. Just assign the bugs to me and I shall add
> RESTRICTs as-needed.
>
Might be wise to prove it on a smaller subset first, for those packages
where you know it's not going to cause an issue, and if it did it wouldn't
cause a machine to be unbootable. (Personally I'd understand a user being
peeved if they couldn't get their desktop up, but it's not that big a deal
provided there's an easy command to run to fix it, and there's notice
given; this is Gentoo, after all.)
 
> Anyway, we really need to start punting .la files one way or the other.
> For desktop users of our distro, they do a lot more harm than good. For
> embedded, perhaps static linking serves some purpose, but really, if
> you can't afford dynamic linking, what are you going to run on your
> board?
> 
Libtool is sweet from a software developer's pov, especially in its heyday.
OFC it might cause distros a bit of aggro, but hey you get to decide what
to patch and how. I'm in favour so long as it is only ever an opt-in, or
not enabled in anything but developer or desktop/Linux profiles (the latter
after at least a year or two of testing and bug resolution.)

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

On 18:34 Sun 09 Nov     , Peter Alfredsen wrote:
> "I've been told" that .la files are really only needed on non-ELF 
> systems and with plugin systems that use dlopen.

And for people who want to build things statically.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Wednesday 12 November 2008, Donnie Berkholz wrote:
> On 18:34 Sun 09 Nov     , Peter Alfredsen wrote:
> > "I've been told" that .la files are really only needed on non-ELF
> > systems and with plugin systems that use dlopen.
>
> And for people who want to build things statically.

That's true, but we generally don't want to do that, so that's fine. If 
needed for a package, we just don't punt la files for it and its 
dependencies. But generally, we should really only be building .so 
files and they just don't need .la files. If someone really wants .la 
files, we could introduce a variable:
IWANTTHECRAPPYLAFILESANDIKNOWWHATIMDOING=yes
to be placed in make.conf.
But the great thing about having a utility function is that you can make 
general exceptions to the rule with tweaks like that.

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

On 17:24 Wed 12 Nov     , Peter Alfredsen wrote:
> On Wednesday 12 November 2008, Donnie Berkholz wrote:
> > And for people who want to build things statically.
> 
> That's true, but we generally don't want to do that, so that's fine. 
> If needed for a package, we just don't punt la files for it and its 
> dependencies. But generally, we should really only be building .so 
> files and they just don't need .la files.

We should enable our users to do things they want to do and not get in 
their way. That's the Gentoo philosophy.

> If someone really wants .la 
> files, we could introduce a variable:
> IWANTTHECRAPPYLAFILESANDIKNOWWHATIMDOING=yes
> to be placed in make.conf.

Where do you even usefully document its existence, if it's a feature of 
some function in some eclass?

> But the great thing about having a utility function is that you can 
> make general exceptions to the rule with tweaks like that.

Yep, just as you can with a number of other possible ways of handling 
this.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]