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

2008-11-16 Thread Michael Haubenwallner

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

Never *unconditionally* switch back from libltdl to dlopenco 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

2008-11-16 Thread Rémi Cardona

Le 16/11/2008 09:44, Michael Haubenwallner a écrit :

Never *unconditionally* switch back from libltdl to dlopenco 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

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

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

-- 
Gilles Dartiguelongue [EMAIL PROTECTED]




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

2008-11-14 Thread Alexis Ballier
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

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

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

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

Cheers

Rémi



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

2008-11-14 Thread Marius Mauch
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

2008-11-14 Thread Donnie Berkholz
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

2008-11-14 Thread Ciaran McCreesh
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

2008-11-12 Thread Mart Raudsepp
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

2008-11-12 Thread Peter Alfredsen
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

2008-11-12 Thread Donnie Berkholz
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

2008-11-12 Thread Rémi Cardona

Le 12/11/2008 15:40, Peter Alfredsen a écrit :

But let me point out that in most leaf-packages, removing la files will
cause no pain, but will ensure that they do not have to be rebuilt if
a .la-listed dependency loses its .la file.


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


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


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


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


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


Cheers :)

Rémi



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

2008-11-12 Thread Mart Raudsepp
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

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

2008-11-12 Thread Peter Alfredsen
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

2008-11-12 Thread Peter Alfredsen
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

2008-11-12 Thread Peter Alfredsen
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

2008-11-12 Thread Donnie Berkholz
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

2008-11-12 Thread Donnie Berkholz
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

2008-11-09 Thread Fabian Groffen
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
 + # If this is a non-ELF system, chances are good that the .la files will 
 be needed.
 + if type -P scanelf  /dev/null

I think this is a not so cool way to check for an ELF system.

 + then
 + debug-print Scanelf found, proceeding...
 + ebegin Removing useless .la files
 + find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec 
 rm -f '{}' '+'
 + eend 0
 + else
 + debug-print scanelf not found, this appears to be a non-ELF 
 system.
 + debug-print non-ELF systems are likely to need .la files.
 + debug-print .la files not removed from ${TARGET}

rationale?


-- 
Fabian Groffen
Gentoo on a different level



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

2008-11-09 Thread Peter Alfredsen
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

2008-11-09 Thread Fabian Groffen
On 09-11-2008 18:34:31 +0200, Peter Alfredsen wrote:
 On Sunday 09 November 2008, Fabian Groffen wrote:
  On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
   + # If this is a non-ELF system, chances are good that the .la
   files will be needed. +   if type -P scanelf  /dev/null
 
  I think this is a not so cool way to check for an ELF system.
 
 Indeed, I think it's a horrid way. Please find a better one.

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

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

   + debug-print scanelf not found, this appears to be a non-ELF
   system. +debug-print non-ELF systems are likely to need 
   .la
   files. + debug-print .la files not removed from ${TARGET}
 
  rationale?
 
 I've been told that .la files are really only needed on non-ELF 
 systems and with plugin systems that use dlopen. I actually have no way 
 of knowing that the .la files are needed on those arches, but I had 
 your archs in mind when doing the patch.

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


-- 
Fabian Groffen
Gentoo on a different level



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

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

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


 --- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.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

2008-11-09 Thread Peter Alfredsen
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.