[busybox] some size savings

[Paul Fox]

 > On Wednesday 02 November 2005 14:48, Bernhard Fischer wrote:
 > > Stressing compilers like that did (for me, at least) trigger some more
 > > or less "interresting" compiler deficiencies, AFAIC): Pathscale as well
 > > as gcc gave up on multiple fn() names per unit (illegal code, granted,
 > > still -- unwarned thus uncought), icc -- and the rest of the gang i
 > > tried this approach with -- segfault{ed,s} on certain other corner
 > > cases and the like. Minor noise in compiler-evolution, from my POV,
 > > fwiw. Nothing fancy, just a couple of bugs at our side and a handful
 > > dozend of 'em at "producers" side of affairs..
 > 
 > It's ok for 1.1 to require a new compiler, but we'll need to have it in by 
 > -pre2.

say what?  i guess i've been sleeping.  exactly what's going to break,
using existing 3.3 compilers that work on busybox 1.0?

 > Is this still the libbb.so work we're discussing?  (You're trying to build 
 > libbb.so all in one gulp?)  The relevant question is probably "any idea what 
 > kind of memory footprint it takes to compile this puppy"?  (Keeping in mind 
 > that you can't build gcc 4.0.2 in a measly 128 megs of ram without swap.  256 
 > it builds in, though.  Right now I believe we compile in 32...)
 > 
 > And what kind of space savings are you seeing?

my question too.

paul
=---------------------
 paul fox, pgf at brightstareng.com