Mail Archives: djgpp-workers/1998/07/06/11:03:28
On Mon, 6 Jul 1998, Eli Zaretskii wrote:
> It is not nice IMHO to have the library compile with warnings. It
> confuses people. We should either change the code to make it cleaner or
> define special GCC switches, for that directory only, to shut it up.
That would be an option, yes. But it might turn out to be a difficult one
to implement, due to the way the makefiles in the libc sources work.
[...]
> I might miss something, but it seems to me that the only thing you need
> to do is to make libc2.tex depend on all the .../*.txh files. Is that
> such a hard case?
'all the .../*.txh' is the problematic part. The whole makefile.oh
business is just for getting a list of all of these built at compile time,
so you don't have to remember editing a makefile whenever you add another
.txh file.
> > > - The build process expects libgcc.a to be in $(TOP)/../lib. Patch
> > > included to fix this.
> >
> > gcc-2.8.1 induced problem, I suspect.
>
> No, that's because the build process assumes you build the library
> in-place (i.e., from $DJDIR/src), whereas I unpacked the alpha release in
> another directory (I still need my v2.01 installation in working order ;-).
That's what I did, as well. Actually, my last versions of the makefiles
used $(DJDIR)/lib for libgcc, I think. But DJ happened not to like that
part :-(
> > > - ../hostbin/dxegen is built as a cross-executable on DOS (the name of
> > > `ld' is only good for Unix). Patch included.
> >
> > Not sure, but this may be necessary (at least theoretically) to ensure
> > that all the parts that end up in the '../bin' directory after a rebuild
> > use newly compiled files only (including a new stub). Almost-circular
> > dependency issue is lurking around this corner.
>
> I think I failed to explain the problem. When you build on a DOS system,
> the native and ``cross'' versions are actually the same, so it doesn't
> matter, for the most part.
For the most part: no. But we want to be sure that tools like stubify, and
possibly djasm, are built twice, so they use the *new* libc and new stub
in their finally installed versions. As you also need them to build that
new stub and new libc.a in turn, they have to be built twice.
I don't remember the specific problems with dxegen off hand, though. Just
ask yourself: are you 100% certain that the two versions would be binary
identical if you use an existing (unpatched) DJGPP 2.01 setup to compile
DJLSR 2.02 from scratch?
> The special problem with dxegen is that it
> has the pathname of the linker hard-wired into it, and the cross version
> uses /usr/local/bla-bla/yada-yada/ variety, which doesn't work on
> DOS/Windows. That is the only cause I needed to change that. The change
> is simple: use $(XLD) instead of $(CROSS_LD) to define the name of
> the linker during dxegen build. $XLD is set as appropriate on each
> platform.
I may be mistaken, but: this exact change would break the dxegen compiled
for execution on the build-host in a cross-compilation. It needs special
handling to ensure it uses the cross-ld, not the system's native one. This
*is* really tricky to get right (took me about 3 iterations from native
DJGPP to Linux cross-compilation and back to native DJGPP build, e.g.)
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -