From: pavenis AT lanet DOT lv
To: "Mark E." <snowball3 AT bigfoot DOT com>, djgpp-workers AT delorie DOT com
Date: Tue, 26 Jun 2001 13:47:24 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: gcc 3.0 released
Message-ID: <3B38926C.15151.16A4D0@localhost>
In-reply-to: <3B373763.10622.36D998@localhost>
References: <Pine DOT A41 DOT 4 DOT 05 DOT 10106251716160 DOT 46808-100000 AT ieva06 DOT lanet DOT lv>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 25 Jun 2001, at 13:06, Mark E. wrote:

> > One more problem is dxegen failure on gcc-3.0 compiled object files due to
> > .comment section (it misinterprets it as unresolved reference).
> 
> A .comment section just contains an id that say in effect, "compiled by gcc 
> 3.0" that takes the place of those 'gcc2_compiled' symbols. gcc 3.0 generates 
> an .ident directive with the id and gas puts the text into the .comment 
> section. For dxes, we can either lump the section in with all others, or 
> discard it since it's only an id string.
> 
> > About Eli's initial question. How possible is some change in
> > binutils that would make linker script from current djdev incompatible
> > with binutils (I think it's unlikely ...) 
> 
> I think so too.
> 
> If gcc 3.0 does require binutils 2.11, then it seems to me it need not use 
> djgpp.djl at all.

Even latest beta update (bnu2112b.zip) doesn't define in internal linker scripts where 
to put .text.* and .data.* (due to options -ffunction-sections and -fdata-sections used 
to build libstdc++-v3). djgpp.djl from current CVS version of DJGPP contains them. So 
djgpp.djl (or functionally identical file with different name) is still needed

One more problem about all recent binutils versions (with gcc-3.0 only):
When external reference from module in object library cannot be resolved the 
procedure name where it happens is not demangled:

./../lib/gcc/liba1.a(gstart.o): In function `Z10InitSVGA16iPKc':
d:/Work/Source/lib/graph/gstart.cc:93: undefined reference to `set_BGI_mode'
d:/Work/Source/lib/graph/gstart.cc:120: undefined reference to `initgraph'
../../lib/gcc/liba1.a(gstart.o): In function `Z10InitSVGA16iPKc':
c:/djgpp/include/libbcc.h:553: undefined reference to `__gr_INIT'

It would be nice to resolve also this for DJGPP release of binutils-2.11.2
(if possible)

Andris