Date:	Mon, 24 Nov 1997 13:17:41 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To:	Nate Eldredge <eldredge AT ap DOT net>
cc:	djgpp-workers AT delorie DOT com, dj AT delorie DOT com
Subject:	Re: Problems with GCC building process
In-Reply-To:	<199711240228.SAA02776@adit.ap.net>
Message-ID:	<Pine.LNX.3.93.971124123521.13298B-100000@acp3bf>
MIME-Version:	1.0

On Sun, 23 Nov 1997, Nate Eldredge wrote:

> While rebuilding GCC the other day, I found some problems with the building
> process.

[conflict between DJ's 'echo.exe' and the one from GNU shellutils]

Why not put 'echo.exe > s-objlist'? As long as 'echo.exe' is a DJGPP, the
system() implementation of redirection should be able to handle that,
right? 

Anyway, that name conflict ought to be solved for real. IMHO, we simply
should not have two programs in the distribution zips with the same name.
For DJ's 'merge' and 'split', this was already addressed (they got a 'dj'
name prefix), so I'd say DJ's 'echo.exe' should also be renamed to
'djecho.exe', vor V2.02, and the gcc makefiles changed accordingly.

Comments, DJ?

[...]
> 2. `libgcc.a' is built via a batch file. It's slightly confusing, but as
> near as I can figure out, the `mklibgcc' program copies the libgcc stubs (of
> the #define/#include nature), with some exceptions, into a temp directory,
[..]
> I don't understand at all why the batch file method is used. I would think
> there would be an easier way to do it. For instance, since `mklibgcc' knows
> all the CFLAGS, etc, why can't it do the compiling itself? (`system')

I'd suggest rewriting 'mklibgcc' to write out a sub-makefile, that will
then be used by the toplevel-make via '$(MAKE) -f libgcc.mak'.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -