[uClibc] Re: crt unacceptable "fix" removal

[Peter S. Mazinger]

On Fri, 15 Oct 2004, Manuel Novoa III wrote:

> Hello Peter,
> 
> On Fri, Oct 15, 2004 at 09:28:31PM +0200, Peter S. Mazinger wrote:
> > On Fri, 15 Oct 2004, Manuel Novoa III wrote:
> > > On Fri, Oct 15, 2004 at 07:50:54PM +0200, Peter S. Mazinger wrote:
> > > > On Fri, 15 Oct 2004, Manuel Novoa III wrote:
> > > > > Now, the utils are built with gcc-final... the uClibc-targeted compiler.
> > > > > So the libraries and crt*.o files used are those previously installed in
> > > > > the staging area, as is the case with every other application buildroot
> > > > > builds for the target.
> > > > 
> > > > Well, you are focused on buildroot, I haven't checked that,
> > > > what I am saying is that it does not work in a native uclibc env, where I 
> > > > would run make utils (w/o any special parameters,flags), so for this case 
> > > > (like already in gentoo and probably uwoody) the problem remains.
> > > 
> > > Fine... there are still problems in the cases you describe.  Actually,
> > > I'm not happy with my changes either.  But that doesn't change the fact
> > > that your patch was too ugly to live, and ripping it out was all I had
> > > time for.
> > 
> > What kind of patch would you accept?
> > 
> > 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.

> 
> > If first the crt0/1 stuff could be cleared, having only 1 version (see 
> > some earlier mail), after that this one would be smaller.
> > 
> > Could you explain me the case if CTOR_DTOR is not set, please?
> 
> Old option to allow building without constructor/destructor support.
> Mostly useful for stripped-down static-only uClibc builds.
> 
> > shared libs:
> > Is the case you described about libpthread_db generic, so that the lib
> > won't need the gcc start/endfiles, and crt[in].o from libc?
> > If yes, it can be built w/
> > -nostartfiles or
> > -nostdlib -lgcc -lc
> > 
> > executable (dynamic and static)
> > does it need crt[01].o (one of them built accordingly)
> > does it need crtbegin*.o/crtend*.o provided by gcc?
> > does it need crt[in].o provided by libc (I have seen archs, where it 
> > provided by gcc)
> 
> I don't understand what you're asking/saying.  But libthread_db is only
> used by gdb and, since it has no constructors/destructors, does not need
> to be linked with crt[in].o.

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)

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

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

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2