Mail Archives: djgpp-workers/1999/08/04/07:55:42
On Wed, 4 Aug 1999, Eli Zaretskii wrote:
> 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?
Yes. But `od' alone won't help us, here. We'ld also need some
postprocessor for `od' output to translate it into parsable C source code.
`sed' or `awk', or something. In the end, we'd end up re-inventing bin2h
by a somewhat complicated line of shell script.
> > 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
> 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.
Well, if we're planning to use the current version of the stub for
compiling it into binutils, we'll have to take it from somewhere. That
will always introduce some dependency on what is or is not present on the
installer's machine. The stub.h in djcrx is there since at least 2.02
(haven't checked 2.01) so it shouldn't be too much of a burden to keep it
available.
Actually, that 'stub.h' is *used* to construct the cross-'stubify' as the
first step of building a cross-compiler. It'd be quite a pointless
exercise to compile a cross-stubify, run it, and od/sed the output just to
get back the same stub.h file that has been sitting there all the time ...
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -