Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
Le 16/11/2008 09:44, Michael Haubenwallner a écrit : Never *unconditionally* switch back from libltdl to dlopen&co in source code, as it is likely to break many non-linux platforms (Darwin, AIX, HP-UX, ...). I perfectly know this. My comment was *exactly* made to point out that we cannot fix any of this without fixing libtool itself. There's *no* way to workaround the issue. Cheers Rémi
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Fri, 2008-11-14 at 15:35 +0100, Rémi Cardona wrote: > Alexis Ballier a écrit : > > Hi, > > > >> (I think pulseaudio is fixed, actually.) > > > > For what it's worth: removing the .la files from pulseaudio breaks its > > module loading on freebsd; and it's an elf system. I don't know what > > you mean by fixed > > It's not fixed and it can't be. libtool's cross-platform dlopen() > wrapper library (libltdl) needs .la files even on ELF systems. > > The only way to fix this is to use dlopen() instead... Never *unconditionally* switch back from libltdl to dlopen&co in source code, as it is likely to break many non-linux platforms (Darwin, AIX, HP-UX, ...). /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Friday 14 November 2008 14:25:30 Alexis Ballier wrote: > Moreover .la files are good when you want to link statically to some > library because they carry the needed information; they should be > punted only when said library provides a good alternative (like a .pc > file with correct libs.private field). Even if the .pc file exists and is fully correct, removing the .la file still breaks any application that links statically and relies on libtool to deal with library dependencies, rather than using pkg-config (and there's no reason why an application /shouldn't/ do that - after all, it works perfectly with the library as upstream released it). Maybe we think it's worth the effort to tweak the application's build system (there probably won't be all that many applications that need it, after all), but this /is/ an incompatible change to the library, and if we're going to do it, we should at least be aware of what we're doing.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Fri, 14 Nov 2008 14:31:56 -0800 Donnie Berkholz <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 pgpLDuhbD3onh.pgp Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Fri, 14 Nov 2008 11:35:44 +0100 Gilles Dartiguelongue <[EMAIL PROTECTED]> wrote: > Le mercredi 12 novembre 2008 à 18:16 +0100, Peter Alfredsen a écrit : > [snip] > > > Mart had already proposed a "static-lib" USE flag. Donnie just > > > suggested on IRC we turn this use flag into a FEATURES flag. > > > > That's problematic. You can't turn off a FEATURES flag for > > individual packages. See above. > > yes you can, can't find the related doc (it's not in portage man), but > that's what /etc/portage/env/ can do for you. Only for some FEATURES though (depending on where they are implemented).
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
Alexis Ballier a écrit : > Hi, > >> (I think pulseaudio is fixed, actually.) > > For what it's worth: removing the .la files from pulseaudio breaks its > module loading on freebsd; and it's an elf system. I don't know what > you mean by fixed It's not fixed and it can't be. libtool's cross-platform dlopen() wrapper library (libltdl) needs .la files even on ELF systems. The only way to fix this is to use dlopen() instead... Cheers Rémi
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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. signature.asc Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 <[EMAIL PROTECTED]>
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 pgpIGjVU6BRSq.pgp Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 pgpIrqxq6kY8r.pgp Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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,
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
Le 12/11/2008 15:40, Peter Alfredsen a écrit : But let me point out that in most leaf-packages, removing la files will cause no pain, but will ensure that they do not have to be rebuilt if a .la-listed dependency loses its .la file. Mart, others and myself have already tried removing .la files to "see what would break". And it breaks a whole lot more than we anticipated. Among others, it breaks KDE3 (all of it), pulseaudio, the current version of app-office/dia, and many more which I can't remember. In a perfect world, there would be no need for .la files. But we're far from that perfect world. I think it's best we provide a better solution. Mart had already proposed a "static-lib" USE flag. Donnie just suggested on IRC we turn this use flag into a FEATURES flag. I think those are much better options than just using this function in some ebuilds. Cheers :) Rémi
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 pgpfp83faEzXI.pgp Description: PGP signature
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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.0 +0200
> +++ eutils1.eclass2008-11-09 18:26:44.0 +0100
> @@ -1805,5 +1805,37 @@
> ) || die
> else
> newbin "${tmpwrapper}" "${wrapper}" || die
> fi
> }
> +
> +# @FUNCTION: epunt_la_files
> +# @USAGE: [dir to scan]
> +# @DESCRIPTION:
> +# .la files can cause many unpleasantries when they disappear,
> +# forcing rebuilds of seemingly unrelated packages.
> +# This function removes the .la files from [dir to scan], "${D}" if not set.
> +# A good time to start punting .la files may be when a .so bump happens,
> +# so dependent packages do not have to be rebuilt twice.
> +#
> +# See also:
> +# bug 245889
> +#
> http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
> +
> +epunt_la_files() {
> + debug-print-function $FUNCNAME "$@"
> + local TARGET=$1
> + [ -z "${TARGET}" ] && TARGET="${D}"
> +
> + # If this is a non-ELF system, chances are good that the .la files will
> be needed.
> + if [[ "$(file ${ROOT}/bin/bash)" =~ " ELF " ]]
> + then
> + debug-print "ELF system found, proceeding..."
> + ebegin "Removing useless .la files"
> + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec
> rm -f '{}' '+'
> + eend 0
> + else
> + debug-print "This appears to be a non-ELF system."
> + debug-print "non-ELF systems are likely to need .la files."
> + debug-print ".la files not removed from ${TARGET}"
> + fi
> +}
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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
--- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
+++ eutils1.eclass 2008-11-09 18:26:44.0 +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
+}
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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
% 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
You could identify ELF a bit more reliable by running file on e.g.
"${ROOT}/bin/bash", or just by building a list of CHOSTs that you know
are ELF systems.
> > > + debug-print "scanelf not found, this appears to be a non-ELF
> > > system." +debug-print "non-ELF systems are likely to need
> > > .la
> > > files." + debug-print ".la files not removed from ${TARGET}"
> >
> > rationale?
>
> "I've been told" that .la files are really only needed on non-ELF
> systems and with plugin systems that use dlopen. I actually have no way
> of knowing that the .la files are needed on those arches, but I had
> your archs in mind when doing the patch.
Ok. What worries me though is that this would result in some systems
having libtool files whereas the majority does not. E.g. removing them
apparently fixes a problem that then crops up on those systems or
something. Can't think of any atm.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
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
