Date:	Mon, 25 Jun 2001 19:36:28 +0300 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: gcc 3.0 released
In-Reply-To:	<Pine.SUN.3.91.1010625193140.4936G-100000@is>
Message-ID:	<Pine.A41.4.05.10106251924240.34030-100000@ieva06.lanet.lv>
MIME-Version:	1.0
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

y

On Mon, 25 Jun 2001, Eli Zaretskii wrote:

> 
> On Mon, 25 Jun 2001, Andris Pavenis wrote:
> 
> > One more problem is dxegen failure on gcc-3.0 compiled object files due to
> > .comment section (it misinterprets it as unresolved reference). In last
> > time I patched dxegen.c to workaround this problem (ignore .comment), but
> > I'm almost sure Eli would not like such patch
> 
> I don't know why should I not like it.  What is the cleanest way to solve 
> this?  Can dxegen do anything useful with these sections?  If it cannot, 
> then ignoring them is an okay solution, IMHO.

They simply contain info that object file is generated by GCC-3.0 and
nothing else. For DJGPP it is defined as containing debug info, so it's 
later removed by strip.

There may be also something wrong with reading COFF file in mkdexe.c and
related functions. I don't know.

> 
> > 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 don't know.  The fact is that this happened with GCC; it can happen 
> again with Binutils.  I'd prefer that such problems could be detected 
> during the development of each one of the packages (GCC and Binutils), 
> and avoided by submitting appropriate patches into the mainstream 
> sources.  But given the size and complexity of these packages and the 
> scarcity of resources, I understand how hard it could be to find these 
> problems in time.  So I guess a possibility that such problems are found 
> late is something we will have to live with.
> 

I suggested temporary solution we can change back when the solution will
be available in DJGPP port of binutils. Even fixing linker scripts in
binutils Mark plans to do should not break binaries of gcc-3.0 which could
contain their own linker script for some time. don't see serious problems
here also as it's unlikely gcc-3.0 will be newest version for a long time

Andris

- Raw text -