Date: Wed, 4 Aug 1999 13:02:54 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Changes in Binutils 2.9.1
In-Reply-To: <Pine.LNX.3.93.990804092021.10456B-100000@acp3bf>
Message-ID: <Pine.SUN.3.91.990804125932.19511A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


On Wed, 4 Aug 1999, Hans-Bernhard Broeker wrote:

> 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.

How about `od', is it a standard utility on Unix?  If it is, perhaps 
relying on it would be a better idea after all.

> 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?

I would like to avoid too many interdependencies between different 
packages.  In particular, if at all possible, Binutils should be
independent of what is or isn't in djcrx.