Mail Archives: djgpp-workers/1997/11/23/20:29:36
On Sun, 23 Nov 1997, DJ Delorie wrote:
> > Given enough interest (i.e.: a good chance that it'll make it into the
> > distributed version), I might re-implement that trick for the current
> > setup. DJ?
>
> As long as everything gets built with the as-yet-uninstalled libc and
> not the previously-installed libc.
(Except for the $(HOSTBIN) ones, that is, right?)
Should be doable, yes. In fact, it could be as simple as redefining the
variables $(LIB), $(BIN) and so on in makefile.inc, and tailor some other
ends.
BTW: there are some more diffs to come, anyway. I'm still collecting, but
for a start:
* libemu.a and emu387.dxe weren't built by 'make'. (fixed)
* bin2h is in the sources, but doesn't seem to be in djdev, why?
(gxx.exe isn't in djdev, either, but I guess that's because it
is to be included in gpp*b.zip, right?)
* A .txh bug noticed in passing: 'remque.txh' has 'putenv' as the
function name in the syntax section (fixed)
* The current lsr dist contains some non-source files, and at least
one temporary file (djasm-n.c, built from djasm.y).
* I tried to use 'gcc -print-libgcc-file-name' to auto-set
'$(MY_LIBGCC_A)' for native builds. But gcc prints something like
'c:/djgpp/lib\libgpp.a' (note the '\'). The backslash in
this string gets eaten up when I write the makefile line like this:
MY_LIBGCC_A = $(shell $(CROSS_GCC) -print-libgcc-file-name)
Any ideas how to get around that?
* Currently, 'libc2.tex' is rebuilt every time 'make' is run. Not a
big issue, but a fixable one.
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -