Date:	Wed, 27 Jun 2001 20:11:14 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	pavenis AT lanet DOT lv
Message-Id:	<2110-Wed27Jun2001201114+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	dj AT delorie DOT com, djgpp-workers AT delorie DOT com
In-reply-to:	<Pine.A41.4.05.10106270853390.48870-100000@ieva06.lanet.lv>
	(message from Andris Pavenis on Wed, 27 Jun 2001 09:27:24 +0300 (WET))
Subject:	Re: gcc 3.0 released
References:	<Pine DOT A41 DOT 4 DOT 05 DOT 10106270853390 DOT 48870-100000 AT ieva06 DOT lanet DOT lv>
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

> Date: Wed, 27 Jun 2001 09:27:24 +0300 (WET)
> From: Andris Pavenis <pavenis AT lanet DOT lv>
> 
> 1) incompatible files with identical names simultanously visible to
>    compiler. Examples: 
>       
> 	specs from djdev201.zip and one from gcc-2.8.1 in 
>       	lib/gcc-lib/djgpp/2.81
> 
> 	djgpp.djl from djdev20[12].zip and one from gcc-2.8.1
> 	(we needed that to get C++ exceptions working)

So you are saying that the different name also required to change
specs to use that new name?  That is, if someone replaces their specs
file, they will lose the linker script as well?

> If I'm wrong then where exactly? 

Having multiple files whose precedence rules are subtle is _the_
problem I'd like to avoid.  It doesn't matter much that the names are
identical or not; what matters is that there are several incompatible
files for the same purpose.

Since the linker script needs to match both the compiler and the
linker (and also the library), we might have a situation in the
future, perhaps near future, that a new Binutils release will need to
modify the linker script, say, to prevent the linker from crashing at
link time, or to prevent programs from crashing at run time.  If we
have more than one linker script lurking on users' platforms, we will
have a much harder time to get the replacement right than today.

Overwriting files when unzipping a package is indeed unfortunate, but
at least we keep one file in one, well-defined place.  Any reasonable
user will DTRT when presented by the unzip utility with the time
stamps of the two files.  As for unreasonable ones... they will wind
up on c.o.m.d. anyway ;-)

By keeping the linker script in one place, we can more easily fix any
situations in the future when one of the three consumers of that file
will require it to be changed.

Once again, the fact that the files' names are identical is not the
problem: the problem is that there are more than one file, and which
one will be used depends on factors that most users don't understand,
and thus will be unable to control without lots of hand-holding.

- Raw text -