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 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/ ]