X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Mon, 10 May 1999 15:21:46 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: cross c++
In-Reply-To: <Pine.SUN.3.91.990510161122.29744B-100000@is>
Message-ID: <Pine.LNX.3.93.990510151734.26435G-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Mon, 10 May 1999, Eli Zaretskii wrote:

> 
> On Mon, 10 May 1999, Hans-Bernhard Broeker wrote:
> 
> > On platforms where gcc is not the original 'system' C compiler,
> > libgcc1.a has to be compiled with that sytem compiler, otherwise it
> > won't work.
> 
> Then libgcc.a from the DJGPP's gccNNNb.zip, if renamed to libgcc1.a on 
> the host platform, should fit the bill, no? 

Almost. libgcc1.a is only one half of libgcc.a, so it might cause
problems if we supplied a full libgcc.a, pretending it's just the
portion that would be built as libgcc1.a, normally.

It's been a while since I last tried this myself, but Ithink the real
trick was to fix the configuration files in the gcc sources to disable gcc
trying to build libgcc.a at all, but just let it use a supplied libgcc.a
as is. 

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