Date:	Wed, 27 Jun 2001 09:27:24 +0300 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	dj AT delorie DOT com, djgpp-workers AT delorie DOT com
Subject:	Re: gcc 3.0 released
In-Reply-To:	<9003-Tue26Jun2001174339+0300-eliz@is.elta.co.il>
Message-ID:	<Pine.A41.4.05.10106270853390.48870-100000@ieva06.lanet.lv>
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 Tue, 26 Jun 2001, Eli Zaretskii wrote:

> > Date: Mon, 25 Jun 2001 15:55:30 -0400
> > From: DJ Delorie <dj AT delorie DOT com>
> > 
> > Ok, I guess I get to step in and decide then.  Here's the question:
> > 
> > I have a set of zips configured with a custom djl file with a unique
> > name.  If I put those on Simtel, will the average user have problems?
> 
> Sorry, I'm confused: what does ``custom djl file'' mean?  Are you
> talking about the solution suggested by Andris, that is, to put a
> linker script under lib/gcc-lib/, or something else?  If the latter,
> where will that file live, and what will be its name?
> 
> In general, I'd like to avoid to have two or more linker script in
> different places.  We've had this with specs before, and I'm still
> healing the wounds ;-)
> 

So I thought slightly more about that and it seems to be required to
explain background of my choose in more details. I have not forgotten
problems we met with earlier ports of GCC (egcs-1.1.X and especially 
gcc-2.8.1) and tried not to repeat earlier mistakes.

I think there are some things we should avoid when possible:

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)

	include files generated by fixinc when building gcc and
	ones from djdev20X.zip (in this case perhaps best would
	be to fix original ones) 
       
2) installing package requires predefined order of unzipping
   archives and package does not work when installed in wrong
   order. We would have that if I put djgpp.djl in directory 
   lib (gcc30b.zip)

3) requesting to check timestamps of required packages additionally
   to version number.

4) requesting user to remove, rename or edit files from other installed
   packages (this doesn't include removal of stale files from old
   packages)


Any of these things can cause problems for ordinary users when
installation instructions is not carefully followed (there always
will be users who will be not carefull and will not read 
instructions even when running into trouble)

Now about "wounds" Eli mentioned. There were mostly due to 1) and 4)
at the time of releasing gcc-2.8.1. I would like to avoid similar
problems now so I tried to avoid all bad things I mentioned above
as far as I could.

Choosing different name of linker script for this release avoids 1)
and possibly 2) we would have if I should name it as djgpp.djl.
There is no need to rerelease djdev203.zip with updated djgpp.djl
so we avoid 3). There is also no need to delete lib/djgpp.djl
that comes from djdev203.zip as it's not used due to different name
(so we avoid 4)

Any of things I would like to avoid now would require to write 
additional detailed installation instructions which will rather likely
forgotten to read and as result I think we should get new wounds.
I tried to avoid that. 

If I'm wrong then where exactly? 

Andris

- Raw text -