Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E33D272.8DFDB201@phekda.freeserve.co.uk>
Date:	Sun, 26 Jan 2003 12:20:02 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: v2.03 crt0 + v2.04 libc compatibility
References:	<10301251938 DOT AA26309 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Charles Sandmann wrote:
[snip]
> V2.03 stub and V2.04 libc are not compatible because of the
> symbols I moved.  V2.03's stub does not contain djgpp_ds_alias or
> crt0_startup_flags - so it either can't find them or tries to
> pull them from the v2.03 libc, which then causes other conflicts.
> 
> If we want, this is fixable by putting these symbols in their own
> modules in the v2.04 libc.  I had moved them to crt0 since it
> required them and managed them.
> 
> But I do think it's weird that we would be getting the two mixed up
> during linking - probably better that the error happens so we know
> something bad has happened ...

It shouldn't be unexpected. The Cygnus test suite Makefile in CVS points gcc
at the include files and libraries in the DJGPP tree, but it does not override
where crt0 is obtained from. Hence it is using mismatched libc and crt0 when
linking.

The patch I submitted forces gcc to use libgcc from the gcc install and crt0
from the DJGPP tree.

I suspect that there may be some other places in the DJGPP tree where the
makefiles are broken and don't override where gcc should get crt0 from. So
this breakage is useful, in a way. ;)

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -