Message-ID: <328DD5B5.38DA@pobox.oleane.com>
Date: Sat, 16 Nov 1996 15:54:45 +0100
From: Francois Charton <deef AT pobox DOT oleane DOT com>
Organization: CCMSA
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: [Fwd: Re: ld2.4 vs ld2.5.2]
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status: 0001
Message-ID: <328DD482 DOT 267C AT pobox DOT oleane DOT com>
Date: Sat, 16 Nov 1996 15:49:38 +0100
From: Francois Charton <deef AT pobox DOT oleane DOT com>
Organization: CCMSA
X-Mailer: Mozilla 2.0 (Win16; I)
MIME-Version: 1.0
To: DJ Delorie <dj AT delorie DOT com>
CC: "djgpp AT delorie DOT com Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Subject: Re: ld2.4 vs ld2.5.2
References: <199611152221 DOT RAA17486 AT delorie DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

DJ Delorie wrote:
> 
> 
> The binutils 2.7 ld is slightly less buggy than the 2.5 and 2.6
> linkers.  It can link the problem file in povray (_pmlite.o), but only
> if you take it out of the library and link it explicitely on the
> command line.

_pmlite.o is a Tasm compiled file, processed by EXMAOUT. From the povray 
3.0 distribution (in the borland specific file pmode.lib) I extracted the 
original .obj : _pmlite.obj, and the processed it with OBJ2COFF, instead 
of EXMAOUT, to get a new _pmlite.o.

Then I replaced the old _pmlite.o by this one inside pmode.a and *it 
worked* without having to extract _pmlite from the library.

This seems to show that (IMHO) the bug is *not* in ld, but in EXMAOUT, 
or, rather, that the COFF format used by EXMAOUT is not 100% compatible 
with DJGPP. (hence the linker error: memory exhausted...).

Eli, could it be put in the FAQ (chapter "converting .OBJ to .O")?

Regards,
Francois