Date: Mon, 6 Jul 1998 17:02:08 +0200 (MET DST) From: Hans-Bernhard Broeker To: Eli Zaretskii cc: DJ Delorie , djgpp-workers AT delorie DOT com Subject: Re: djgpp alpha 980628 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.