Date:	Mon, 6 Jul 1998 17:48:51 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject:	Re: djgpp alpha 980628
In-Reply-To:	<Pine.LNX.3.93.980706144844.15155F-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.980706173827.28126E-100000@is>
MIME-Version:	1.0

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.

- Raw text -