[uClibc] Re: crt unacceptable "fix" removal

[Manuel Novoa III]

Peter,

On Fri, Oct 15, 2004 at 10:12:59PM +0200, Peter S. Mazinger wrote:
> On Fri, 15 Oct 2004, Manuel Novoa III wrote:
> > On Fri, Oct 15, 2004 at 09:28:31PM +0200, Peter S. Mazinger wrote:
> > > 
> > > I have thought a lot how I can change the gcc defaults, but it's no way 
> > > out, nostdinc does nothing for linker stage, nostdlib (or nostartfiles) 
> > > has to be used and the rest has to be provided manually. Well, I didn't 
> > > found any other solution to it (someone w/ another idea?)
> > 
> > Which is why I'm saying don't even try.  Even if you get it working
> > now (as you probably did), it just makes for unnecessary maintenance
> > headaches because you're having to duplicate what gcc is (currently)
> > doing.
> > 
> > Once again... the sane thing is to build the utils _after_ you build
> > the targeted toolchain.
> 
> How should I handle than native env? The "toolchain" is already targeted.

What is the problem?  The utilities are just applications that happen
to have their source in the uClibc tree.  Build them as you would build
any other application.  If you want them to use the newly built libs
and crt files, then do an install of the devel environment and build
the utils afterwards.

> I'll try it again.
> If I disable CTOR_DTOR in uClibc what do I really need to build
> libs and executables (dynamic and static) (we assume they do not need 
> [de]constructor support from libc)

The things that would typically need constructor/destructor support in
uClibc are handled specially by __uClibc_main so that initialization
and shutdown of the lib does not rely on CTOR_DTOR.

> libs (shared/archive):
> do I need crtbegin/end.o from gcc and/or crti/n.o from uClibc?

libpthread.so does since it relies on a constructor.  Other shared
libs in uClibc don't.

> executables (dyn/static)
> do I need crt[01].o
> do I need crtbegin/end.o and/or crti/n.o

Look at the gcc specs file.

Manuel