Date: Mon, 6 Jul 1998 17:48:51 +0300 (IDT) From: Eli Zaretskii To: Hans-Bernhard Broeker 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, Hans-Bernhard Broeker wrote: > On Sun, 5 Jul 1998, Eli Zaretskii wrote: > > > - regcomp.c, regerror.c, engine.c regexec.c trigger numerous warnings. > > That's always been the case. The regexp functions are simply not of the > same coding quality as the rest of DJ's libc (they come from outside, > IIRC), and I suspect trying to change them might easily break them. > They're just too complicated. 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. > > - mkdoc.exe always remakes libc2.tex, and info: always remakes > > libc.info. Can't they have real dependencies, so they won't > > regenerate files which already exist? > > I once had a patched makefile set (for alpha 9710* or so) that did this. > But it was quite a hassle (you have to duplicate the whole mechanism that > does this for the .[cS] sources, like the makefile.oh and so on, to do > it). 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? > > - 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 ;-). > > - ../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. 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.