www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/12/04/09:27:33

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Tue, 4 Dec 2001 15:26:30 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: djgpp-workers AT delorie DOT com
cc: eliz AT is DOT elta DOT co DOT il
Subject: Re: Distribution issues (was: Re: Building a profiled version of
libc)
In-Reply-To: <10112032126.AA14791@clio.rice.edu>
Message-ID: <Pine.LNX.4.10.10112041524230.8994-100000@acp3bf>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 3 Dec 2001, Charles Sandmann wrote:

> > And the problem is that specs is in the GCC distribution, while
> > libc_p.a, if we decide to distribute one, will be in djdev.
> > 
> > What I was saying was that these two changes must be in sync,
> > otherwise users will have broken installations.  At the very least,
> > we must release djdev with libc_p.a first, and modify specs some time
> > after that.
> 
> When we refresh 2.03, should we put a stub libc_p.a in there?  

No. More precisely, a stub is needed only if all of the following
were true:

* we agree that we should have libc_p.a in DJGPP soon
* therefore, we release a GCC build with a modified specs file that
   calls upon libc_p.a to be there
* we fail to build a real libc_p.a for a DJDEV released *before* that
   GCC one.

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019