Re: crt0 formalization

[jschopp <jschopp at austin dot ibm dot com>]

> I would like to stress that newlib 1.15.0 is coming due.  

First I'd heard of that.  Any idea when 1.15 is planned on being put out?  I'd like to 
resync IBMs next cell developer SDK to be based on newlib 1.15 instead of 1.14.

I'd also like to have one of the solutions to fix atexit() pulling in malloc merged for 
1.15, assuming I didn't just miss something getting merged for it.  I can write a new 
patch if you give me some direction how you'd prefer it done.  This seems to be a good 
method: http://sourceware.org/ml/newlib/2006/msg00181.html

I'd also like to take another run at getting the cell stdio offloading RFC mergeable for 
1.15, hopefully the whole thing but at least the functions that don't take a FILE* 
argument.  This set of patches is being used by end users, because without it something 
like printf() will take ~200K of the 256K total memory, leaving very little for anything else.

> If the patch 
> is accepted as-is, there is nothing to prevent the crti/n files from 
> being added to gcc later (and later removed from libgloss).  If someone 
> from the spu group wants to stand up and agree to make a gcc patch, I'll 
> be happy to take the files out of the patch now and check the remainder in.

Not that this is a democracy, because it isn't.  But I think all the spu people are in 
favor of merging the patch here as is.  Kazunori-san had some questions but seems to have 
had them answered.  I haven't heard any objections from Andrew.  Ben sent the patch out in 
the first place, and I liked them so much I forwarded them on.  Sa, the original author is 
obviously in favor.  I talked privately to Ulrich Weigand who works on spu gcc as well and 
he thought it was a logical split.

Ultimately this is the group that will be maintaining the cell spu gcc & newlib.

> If this is attempting to evolve into a policy regarding what gcc must 
> provide on their side of the fence, then I believe that it should 
> probably move to the gcc list.

That sounds like a good place for it.