X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Mon, 2 Aug 1999 18:57:53 +0200 (MET DST)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Changes in Binutils 2.9.1
In-Reply-To:	<199908021431.KAA01036@envy.delorie.com>
Message-ID:	<Pine.LNX.3.93.990802185053.8447K-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 2 Aug 1999, DJ Delorie wrote:

> > Does anybody see any problems with this?  How about cross-building:
> > can we rely on `stubify' and `od' to be available then?

> It would be best if it was autoconf detected.  If od and stubify were
> available, it should enable extra makefile steps to regenerate the
> stub pattern.

Or, for similar purposes, why not install the 'stub.h' generated as part
of the DJLSR build process, into $(DJDIR)/include/sys/go32stub.h or
similar? Once that's done (and DJGPP 2.03 or later released), binutils
could be changed to always for "sys/go32stub.h", and use the copy coming
with the binutils source only if none was found. The latter should only
happen if someone's building with an older djcrx*.zip.

For the short term, it might be seen as part of the duty of whoever makes
binutils binary distribution packages for DJGPP to ensure that the latest
stub.h is included, and used. FSF patches for this part of binutils should
probably be submitted by DJ himself, every time a new DJGPP release is
made. 

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -