Date:	Mon, 25 Jun 2001 15:12:51 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Andris Pavenis <pavenis AT lanet DOT lv>
cc:	lauras AT softhome DOT net, djgpp-workers AT delorie DOT com
Subject:	Re: gcc 3.0 released
In-Reply-To:	<Pine.A41.4.05.10106251414220.31944-100000@ieva06.lanet.lv>
Message-ID:	<Pine.SUN.3.91.1010625150707.2920D-100000@is>
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, 25 Jun 2001, Andris Pavenis wrote:

> > > I suggested to temporary change name of linker script and supply the new
> > > one with GCC-3.0. So I make sure the incompatible one from djdev203.zip
> > > will never be used with these binaries of GCC-3.0. As result there is no
> > > need to update djdev203.zip now and there will be no danger of unpacking
> > > archives in wrong order.
> > 
> > What happens if one of the next Binutils releases needs to change the 
> > script?
> 
> When it could happen? I think that not earlier than to next major
> release of binutils but more probably even later.

That could be tomorrow, if Mark finds some grave reason to do so.

> The best would be to get rid of linker script in djdev20X.zip with time
> and to have it in binutils only (in libs/ldscripts).

We've been through that in the past: the problem with the linker script 
is that, unlike specs, it is releated to both the compiler and to 
Binutils.  So putting it in either of these two packages has downsides 
when the other package needs a change in the script, for some reason.

Of course, leaving the script in djdev doesn't solve this problem, but at 
least it doesn't change the packaging everybody is used to.  I think such 
changes are only justified when they solve problems in some fundamental 
ways, because packaging changes have their own downsides (people leave 
old files lurking around and waiting to bite them).

- Raw text -