* [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-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 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 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 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-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-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 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
* 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] 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: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
* [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] 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
* [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
* 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 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 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
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