Message-ID: <329A4400.4E78@pobox.oleane.com> Date: Tue, 26 Nov 1996 02:12:32 +0100 From: Francois Charton Organization: CCMSA MIME-Version: 1.0 To: DJ Delorie CC: djgpp AT delorie DOT com Subject: Re: ld2.4 vs ld2.5.2 References: <199611192319 DOT SAA15056 AT delorie DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DJ Delorie wrote: > > > As regards ways of overriding the problem (without solving the bug), one > > would be to develop a small tool (and maybe to include it in ar or > > ranlib) which converts AOUT files to COFF. > > binutils comes with a utility called "objcopy" that can convert > between a.out and coff. I haven't tried it myself, but does it solve > the povray problem? Yes and no! I tried it tonight : with command line : objcopy -I a.out-i386 -O coff-go32 ... When I apply it to file _pmlite.o (the one which cause problem in povray), and then reinsert the resulting object in the pmode.a library, I can link povray with no error... but when I run the resulting program, it crashes on a SIGSEV, page fault in 000000e8, error=0004, error... I then reextracted _pmlite.o from pmode.a, and tried to relink (this worked originally) but this time I got the same error at runtime... So, it seems that transforming the aout file into coff with objcopy succeeds in eliminating the ld problem, but somehow produces a COFF object which does not work. To check whether this was the fault of ld, of my original aout file, or of objcopy, I reinstalled a working version of povray (using the usual workaround against the ld bug) and tried to rebuild : no problem. Then I took a normal .o file, and used objcopy to convert it to aout format. When I tried to rebuild povray with the modified .o, I got a series of warnings : BFD: could not assert bfd : aoutx.h 2550 (or something like this), and when I ran the executable, it crashed on a SIGILL, invalid opcode... Finally, I tried to reconvert the resulting aout .o back to coff format (still using objcopy). When I tried to build povray again, it stopped in the middle of the link, on an Abort! message. Altogether, this seems to point out some problem with the aout format used in BFD, (called a.out-i386, and used both by ld and objcopy), which seems to either break the linker, or produce crashing programs... Hope this helps understanding the ld problems... I'll try to send a shorter program showing this bug tomorrow. Regards Francois