Mail Archives: djgpp/1996/11/16/10:17:51
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
- Raw text -