* [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
@ 2008-11-09 16:04 Peter Alfredsen
2008-11-09 16:10 ` Fabian Groffen
0 siblings, 1 reply; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-09 16:04 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-09 16:04 [gentoo-dev] Please review: function epunt_la_files for eutils.eclass Peter Alfredsen
@ 2008-11-09 16:10 ` Fabian Groffen
2008-11-09 16:34 ` Peter Alfredsen
0 siblings, 1 reply; 32+ messages in thread
From: Fabian Groffen @ 2008-11-09 16:10 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-09 16:10 ` Fabian Groffen
@ 2008-11-09 16:34 ` Peter Alfredsen
2008-11-09 16:48 ` Fabian Groffen
` (2 more replies)
0 siblings, 3 replies; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-09 16:34 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-09 16:34 ` Peter Alfredsen
@ 2008-11-09 16:48 ` Fabian Groffen
2008-11-09 17:46 ` Peter Alfredsen
2008-11-12 13:41 ` Mart Raudsepp
2008-11-12 15:52 ` [gentoo-dev] " Donnie Berkholz
2 siblings, 1 reply; 32+ messages in thread
From: Fabian Groffen @ 2008-11-09 16:48 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-09 16:48 ` Fabian Groffen
@ 2008-11-09 17:46 ` Peter Alfredsen
2008-11-09 17:53 ` Fabian Groffen
0 siblings, 1 reply; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-09 17:46 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-09 17:46 ` Peter Alfredsen
@ 2008-11-09 17:53 ` Fabian Groffen
0 siblings, 0 replies; 32+ messages in thread
From: Fabian Groffen @ 2008-11-09 17:53 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-09 16:34 ` Peter Alfredsen
2008-11-09 16:48 ` Fabian Groffen
@ 2008-11-12 13:41 ` Mart Raudsepp
2008-11-12 14:40 ` Peter Alfredsen
2008-11-12 15:52 ` [gentoo-dev] " Donnie Berkholz
2 siblings, 1 reply; 32+ messages in thread
From: Mart Raudsepp @ 2008-11-12 13:41 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 13:41 ` Mart Raudsepp
@ 2008-11-12 14:40 ` Peter Alfredsen
2008-11-12 16:14 ` Rémi Cardona
2008-11-12 16:53 ` Mart Raudsepp
0 siblings, 2 replies; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-12 14:40 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-09 16:34 ` Peter Alfredsen
2008-11-09 16:48 ` Fabian Groffen
2008-11-12 13:41 ` Mart Raudsepp
@ 2008-11-12 15:52 ` Donnie Berkholz
2008-11-12 16:24 ` Peter Alfredsen
2 siblings, 1 reply; 32+ messages in thread
From: Donnie Berkholz @ 2008-11-12 15:52 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 14:40 ` Peter Alfredsen
@ 2008-11-12 16:14 ` Rémi Cardona
2008-11-12 17:16 ` Peter Alfredsen
2008-11-12 16:53 ` Mart Raudsepp
1 sibling, 1 reply; 32+ messages in thread
From: Rémi Cardona @ 2008-11-12 16:14 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 15:52 ` [gentoo-dev] " Donnie Berkholz
@ 2008-11-12 16:24 ` Peter Alfredsen
2008-11-13 6:23 ` Donnie Berkholz
0 siblings, 1 reply; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-12 16:24 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 14:40 ` Peter Alfredsen
2008-11-12 16:14 ` Rémi Cardona
@ 2008-11-12 16:53 ` Mart Raudsepp
2008-11-12 17:31 ` Peter Alfredsen
1 sibling, 1 reply; 32+ messages in thread
From: Mart Raudsepp @ 2008-11-12 16:53 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 16:14 ` Rémi Cardona
@ 2008-11-12 17:16 ` Peter Alfredsen
2008-11-13 6:21 ` Donnie Berkholz
` (2 more replies)
0 siblings, 3 replies; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-12 17:16 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 16:53 ` Mart Raudsepp
@ 2008-11-12 17:31 ` Peter Alfredsen
2008-11-13 18:49 ` [gentoo-dev] " Ryan Hill
2008-11-14 4:14 ` Ryan Hill
0 siblings, 2 replies; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-12 17:31 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 17:16 ` Peter Alfredsen
@ 2008-11-13 6:21 ` Donnie Berkholz
2008-11-14 10:35 ` Gilles Dartiguelongue
2008-11-14 14:25 ` Alexis Ballier
2 siblings, 0 replies; 32+ messages in thread
From: Donnie Berkholz @ 2008-11-13 6:21 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 16:24 ` Peter Alfredsen
@ 2008-11-13 6:23 ` Donnie Berkholz
0 siblings, 0 replies; 32+ messages in thread
From: Donnie Berkholz @ 2008-11-13 6:23 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
2008-11-12 17:31 ` Peter Alfredsen
@ 2008-11-13 18:49 ` Ryan Hill
2008-11-14 4:14 ` Ryan Hill
1 sibling, 0 replies; 32+ messages in thread
From: Ryan Hill @ 2008-11-13 18:49 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
2008-11-12 17:31 ` Peter Alfredsen
2008-11-13 18:49 ` [gentoo-dev] " Ryan Hill
@ 2008-11-14 4:14 ` Ryan Hill
2008-11-14 23:05 ` Peter Alfredsen
1 sibling, 1 reply; 32+ messages in thread
From: Ryan Hill @ 2008-11-14 4:14 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 17:16 ` Peter Alfredsen
2008-11-13 6:21 ` Donnie Berkholz
@ 2008-11-14 10:35 ` Gilles Dartiguelongue
2008-11-14 17:28 ` Marius Mauch
2008-11-14 14:25 ` Alexis Ballier
2 siblings, 1 reply; 32+ messages in thread
From: Gilles Dartiguelongue @ 2008-11-14 10:35 UTC (permalink / raw
To: gentoo-dev
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-12 17:16 ` Peter Alfredsen
2008-11-13 6:21 ` Donnie Berkholz
2008-11-14 10:35 ` Gilles Dartiguelongue
@ 2008-11-14 14:25 ` Alexis Ballier
2008-11-14 14:35 ` Rémi Cardona
` (2 more replies)
2 siblings, 3 replies; 32+ messages in thread
From: Alexis Ballier @ 2008-11-14 14:25 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-14 14:25 ` Alexis Ballier
@ 2008-11-14 14:35 ` Rémi Cardona
2008-11-16 8:44 ` Michael Haubenwallner
2008-11-14 22:31 ` Donnie Berkholz
2008-11-14 22:44 ` David Leverton
2 siblings, 1 reply; 32+ messages in thread
From: Rémi Cardona @ 2008-11-14 14:35 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-14 10:35 ` Gilles Dartiguelongue
@ 2008-11-14 17:28 ` Marius Mauch
0 siblings, 0 replies; 32+ messages in thread
From: Marius Mauch @ 2008-11-14 17:28 UTC (permalink / raw
To: gentoo-dev
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).
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-14 14:25 ` Alexis Ballier
2008-11-14 14:35 ` Rémi Cardona
@ 2008-11-14 22:31 ` Donnie Berkholz
2008-11-14 22:33 ` Ciaran McCreesh
2008-11-14 22:44 ` David Leverton
2 siblings, 1 reply; 32+ messages in thread
From: Donnie Berkholz @ 2008-11-14 22:31 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-14 22:31 ` Donnie Berkholz
@ 2008-11-14 22:33 ` Ciaran McCreesh
0 siblings, 0 replies; 32+ messages in thread
From: Ciaran McCreesh @ 2008-11-14 22:33 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-14 14:25 ` Alexis Ballier
2008-11-14 14:35 ` Rémi Cardona
2008-11-14 22:31 ` Donnie Berkholz
@ 2008-11-14 22:44 ` David Leverton
2 siblings, 0 replies; 32+ messages in thread
From: David Leverton @ 2008-11-14 22:44 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
2008-11-14 4:14 ` Ryan Hill
@ 2008-11-14 23:05 ` Peter Alfredsen
2008-11-14 23:25 ` Ciaran McCreesh
` (2 more replies)
0 siblings, 3 replies; 32+ messages in thread
From: Peter Alfredsen @ 2008-11-14 23:05 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
2008-11-14 23:05 ` Peter Alfredsen
@ 2008-11-14 23:25 ` Ciaran McCreesh
2008-11-15 0:26 ` Mart Raudsepp
2008-11-17 19:19 ` [gentoo-dev] " Steve Long
2 siblings, 0 replies; 32+ messages in thread
From: Ciaran McCreesh @ 2008-11-14 23:25 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
2008-11-14 23:05 ` Peter Alfredsen
2008-11-14 23:25 ` Ciaran McCreesh
@ 2008-11-15 0:26 ` Mart Raudsepp
2008-11-15 6:44 ` Duncan
2008-11-17 19:19 ` [gentoo-dev] " Steve Long
2 siblings, 1 reply; 32+ messages in thread
From: Mart Raudsepp @ 2008-11-15 0:26 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
2008-11-15 0:26 ` Mart Raudsepp
@ 2008-11-15 6:44 ` Duncan
0 siblings, 0 replies; 32+ messages in thread
From: Duncan @ 2008-11-15 6:44 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-14 14:35 ` Rémi Cardona
@ 2008-11-16 8:44 ` Michael Haubenwallner
2008-11-16 22:21 ` Rémi Cardona
0 siblings, 1 reply; 32+ messages in thread
From: Michael Haubenwallner @ 2008-11-16 8:44 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
2008-11-16 8:44 ` Michael Haubenwallner
@ 2008-11-16 22:21 ` Rémi Cardona
0 siblings, 0 replies; 32+ messages in thread
From: Rémi Cardona @ 2008-11-16 22:21 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [gentoo-dev] Re: Re: Please review: function epunt_la_files for eutils.eclass
2008-11-14 23:05 ` Peter Alfredsen
2008-11-14 23:25 ` Ciaran McCreesh
2008-11-15 0:26 ` Mart Raudsepp
@ 2008-11-17 19:19 ` Steve Long
2 siblings, 0 replies; 32+ messages in thread
From: Steve Long @ 2008-11-17 19:19 UTC (permalink / raw
To: gentoo-dev
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.)
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2008-11-17 19:23 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-09 16:04 [gentoo-dev] Please review: function epunt_la_files for eutils.eclass Peter Alfredsen
2008-11-09 16:10 ` Fabian Groffen
2008-11-09 16:34 ` Peter Alfredsen
2008-11-09 16:48 ` Fabian Groffen
2008-11-09 17:46 ` Peter Alfredsen
2008-11-09 17:53 ` Fabian Groffen
2008-11-12 13:41 ` Mart Raudsepp
2008-11-12 14:40 ` Peter Alfredsen
2008-11-12 16:14 ` Rémi Cardona
2008-11-12 17:16 ` Peter Alfredsen
2008-11-13 6:21 ` Donnie Berkholz
2008-11-14 10:35 ` Gilles Dartiguelongue
2008-11-14 17:28 ` Marius Mauch
2008-11-14 14:25 ` Alexis Ballier
2008-11-14 14:35 ` Rémi Cardona
2008-11-16 8:44 ` Michael Haubenwallner
2008-11-16 22:21 ` Rémi Cardona
2008-11-14 22:31 ` Donnie Berkholz
2008-11-14 22:33 ` Ciaran McCreesh
2008-11-14 22:44 ` David Leverton
2008-11-12 16:53 ` Mart Raudsepp
2008-11-12 17:31 ` Peter Alfredsen
2008-11-13 18:49 ` [gentoo-dev] " Ryan Hill
2008-11-14 4:14 ` Ryan Hill
2008-11-14 23:05 ` Peter Alfredsen
2008-11-14 23:25 ` Ciaran McCreesh
2008-11-15 0:26 ` Mart Raudsepp
2008-11-15 6:44 ` Duncan
2008-11-17 19:19 ` [gentoo-dev] " Steve Long
2008-11-12 15:52 ` [gentoo-dev] " Donnie Berkholz
2008-11-12 16:24 ` Peter Alfredsen
2008-11-13 6:23 ` Donnie Berkholz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox