X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Wed, 4 Aug 1999 09:49:37 +0200 (MET DST)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Changes in Binutils 2.9.1
In-Reply-To:	<Pine.SUN.3.91.990804094218.6630A-100000@is>
Message-ID:	<Pine.LNX.3.93.990804092021.10456B-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 Wed, 4 Aug 1999, Eli Zaretskii wrote:
> On Tue, 3 Aug 1999, Eli Zaretskii wrote:

> > For other solutions, we have to make assumptions about availability
> > of certain tools (stubify, bin2h, or od and sed/awk/perl).
> 
> It turns out we only need stubify and bin2h.  Can you even have a
> cross-build environment without these?  They are part of djdev, so I'd
> expect them to be installed on any system that generates DJGPP
> programs.  Am I missing something?

You're missing the chicken/egg problem, I think.  For a cross-build of
binutils, only djcrx will be used. In particular, there is no bin2h, in a
cross-build, I think. At least not if you follow the cross-compilation
HOWTO. As is, bin2h is only part of djdev, but not of djcrx. Stubify
source is provided with djcrx, and also the necessary stub.h (as
$(CROSS-DJDIR)/src/stub/stub.h) 

So the building procedure for binutils could probably be changed to:

if native build: use existing 'stubify -g' ; 'bin2h' to generate stub.h
else           : use stub.h from the djcrx package. 
If the selected method (of the above two) doesn't work:
   fall back to go32stub.h, as contained in binutils sources

Does this sound manageable?

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

- Raw text -