www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/06/29/06:07:16

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Fri, 29 Jun 2001 11:13:01 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: djgpp-workers AT delorie DOT com
Subject: Re: gcc 3.0 released
In-Reply-To: <008301c10050$1a8e4680$e33e1d18@nycap.rr.com>
Message-ID: <Pine.LNX.4.10.10106291057080.20259-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 Fri, 29 Jun 2001, Matthew Conte wrote:

> i don't see what the problem is, then...  using a built-in version of the
> linker script avoids having to deal with $(DJGPP)/lib/djgpp.djl altogether,
> thus avoiding mutually exclusive binary packages from overwriting each
> other's version of the file.  

Not really. Not unless we give up the currently rather loose coupling of
GCC, DJGPP and binutils releases among each other. E.g., the next GCC
might break something, fixable only by changing those builtin linker
scripts.  So we'ld have to release fresh binutils for no other reason than
a change in GCC, unless we can have GCC overrule those linker scripts, at
least temporarily. And that's what having them as externally visible files
does for us.

At the heart of this, I see two conceptual differences between DJGPP
and, say, your average Linux installation that are causing this:

1) Unlike Linux distributions, DJGPP isn't really centrally managed ---
   releases of individual packages happen independantly, even among
   libc, gcc and binutils. And we try to have as many combinations of
   package releases working as remotely possible. 

2) The ratio of wizards per newbie is lower for DJGPP than for other
   platforms, partly because the platform we're working for (DOS)
   is growing more and more obscure.  We have to deal with users who
   never before grasped the concept of a README, let alone that of a
   command-line oriented toolchain in general.  So we have to be as
   foolproof as remotely possible, but the platform lacks some 
   important tools for making that a reality.

The whole problem this discussion is about if only we could rely on either
of the above to be changed.  If we could rely that users read READMEs, the
problem would be nonexistant. It would also disappear if we switched back
to the old days of packaging libc, gcc and binutils as one (huuuge) binary
package. Or if we switch from plain .zip to an opaque package format
requiring an installer application to unpack, which would check package
dependencies.

-- 
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