[uClibc] Re: crt unacceptable "fix" removal

[Manuel Novoa III]

Peter,

On Fri, Oct 15, 2004 at 04:46:22PM +0200, Peter S. Mazinger wrote:
> On Fri, 15 Oct 2004, Peter S. Mazinger wrote:
> > Maybe the fix is unacceptable, but do first the test below and see 
> > yourself what happens.

Your fix was unacceptable because you were adding a ton of stuff to the
build system that was either 1) unnecessary or 2) there only to emulate
how the uClibc-targeted gcc would link things.  As I commented in the
cvs commit, it is saner to build the tools with the correct toolchain.

> > In a native uclibc environment add some dummy note to crt0.S and comment
> > stripping after creating the crt1.o file, copy this file to TOPDIR/lib and 
> > rebuild your target utilities running make in utils
> > Look for the dummy entry in your ldconfig/ldd binaries.
> > 
> > I haven't done such a test, but I am pretty sure, that the crt files used 
> > to build the target utils in a native env. running make will use those 
> > installed on the system and not those from TOPDIR/lib.
> 
> The same probably applies to crt[in].o too.
> gcc -v would show the used files too.

Previously, the utils were built using gcc-initial...  the bootstrapping
compiler.  And yes, things were broken.  But since this wasn't affecting
me (I've had no reason to use the utils), fixing this took a back seat to
a number of other tasks.

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.

> Note: You missed to add back SHARED_START/END_FILES to libpthread_db

No, I didn't "miss" libpthread_db.  That library has no constuctors
or destructors, and hence doesn't need to be linked with crt[in].o.

Manuel