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

2008-11-14 Thread Ryan Hill
On Wed, 12 Nov 2008 18:31:47 +0100
Peter Alfredsen [EMAIL PROTECTED] 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


signature.asc
Description: PGP signature


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

2008-11-14 Thread Ryan Hill
On Wed, 12 Nov 2008 18:31:47 +0100
Peter Alfredsen [EMAIL PROTECTED] 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


signature.asc
Description: PGP signature


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

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


signature.asc
Description: This is a digitally signed message part.


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

2008-11-14 Thread Ciaran McCreesh
On Sat, 15 Nov 2008 00:05:52 +0100
Peter Alfredsen [EMAIL PROTECTED] 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


signature.asc
Description: PGP signature


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

2008-11-14 Thread Mart Raudsepp
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: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part


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

2008-11-14 Thread Duncan
Mart Raudsepp [EMAIL PROTECTED] posted [EMAIL PROTECTED],
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