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 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.