X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Tue, 3 Aug 1999 15:33:54 +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:	<Pine.SUN.3.91.990803103346.1847C-100000@is>
Message-ID:	<Pine.LNX.3.93.990803151813.9400E-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 Tue, 3 Aug 1999, Eli Zaretskii wrote:

> On Mon, 2 Aug 1999, Hans-Bernhard Broeker wrote:
> > 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?
> 
> This will also work, but adding a header for the sake of a single
> package seems like too much of a hassle.

But OTOH, a directly available 'stub.h' is the only thing that would
work equally easily for both native and cross builds of binutils for
DJGPP. For other solutions, we have to make assumptions about availability
of certain tools (stubify, bin2h, or od and sed/awk/perl).

> > 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.
> 
> This is of course true, but it doesn't solve the problem.  Too many
> people are trying to build Binutils for themselves lately, see
> c.o.m.d., so hand-crafted solutions would not fit the bill.

People building their own binutils, IMHO, is a symptom that a binary
package is needed. Even if it were just for reducing the number of
variants of DJGPP installations being in use, out there, that might be
reason enough to make one. 

> > FSF patches for this part of binutils should
> > probably be submitted by DJ himself, every time a new DJGPP release is
> > made. 
> 
> I was trying to find a way that would automatically use the latest
> stub, so that DJ and others could be spared this burden.

The problem is that there doesn't seem to be any reliable way to find and
use that latest stub, esp. for cross-builds --- native builds could do
with stubify and bin2h.

Anyway, submitting the latest stub to FSF is only to be seen as a fallback
solution, anyway. Of course, the build procedure should be using the stub
of exactly the version of DJGPP it's built for/with, by default. But in
case it isn't found, a warning message could still be issued at
'configure' time, and the included stub be used. 

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

- Raw text -