From:	"Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To:	<djgpp-workers AT delorie DOT com>, "Andris Pavenis" <pavenis AT lanet DOT lv>
Cc:	<lauras AT softhome DOT net>
Subject:	Re: gcc 3.0 released
Date:	Mon, 25 Jun 2001 17:57:54 +0200
Message-ID:	<CAEGKOHJKAAFPKOCLHDIMEMECEAA.tim.van.holder@pandora.be>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To:	<Pine.SUN.3.91.1010625150707.2920D-100000@is>
Importance:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
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

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

I don't agree - linker scripts are only for the linker (ie binutils).  The
djgpp.djl script was different, as it was tied to the DJGPP core (djdev),
the compiler (though the specs file) and binutils (as it needed to evolve
along with the builtin script).  Once that homegrown script is dropped,
binutils becomes the sole owner of linker scripts.
Even if a new compiler needs updated linker scripts, that support must be
added to binutils, and it is the updated binutils that will bring the new
scripts with it.  So linker scripts are only related to the compiler the
same way any of the binutils are.
For example, if gcc 3.1 for whatever reason needs linker script capabilities
only provided by binutils 2.15, then our gcc 3.1 package, just like any
other,
would require binutils 2.15.

- Raw text -