Date: Mon, 25 Jun 2001 21:46:31 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: pavenis AT lanet DOT lv
Message-Id: <9003-Mon25Jun2001214631+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <Pine.A41.4.05.10106251924240.34030-100000@ieva06.lanet.lv>
	(message from Andris Pavenis on Mon, 25 Jun 2001 19:36:28 +0300 (WET))
Subject: Re: gcc 3.0 released
References:  <Pine DOT A41 DOT 4 DOT 05 DOT 10106251924240 DOT 34030-100000 AT ieva06 DOT lanet DOT lv>
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

> Date: Mon, 25 Jun 2001 19:36:28 +0300 (WET)
> From: Andris Pavenis <pavenis AT lanet DOT lv>
> 
> > > 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.

That doesn't really answer my question.  Is ignoring these section a
clean solution or not?  If you think ignoring these sections is not a
clean solution, what is?

> 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

We are reiterating the same things for the umpteenth time.  I don't
see any point to continue monopolizing everybody's time, especially
since you've already made up your mind and uploaded the distribution
to DJ's machine.

So I guess we'll have to wait-and-see.