Date: Fri, 29 Jun 2001 09:53:11 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Matthew Conte" Message-Id: <1438-Fri29Jun2001095310+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: djgpp-workers AT delorie DOT com In-reply-to: <008301c10050$1a8e4680$e33e1d18@nycap.rr.com> (matt@conte.com) Subject: Re: gcc 3.0 released References: <008301c10050$1a8e4680$e33e1d18 AT nycap DOT rr DOT com> 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 > From: "Matthew Conte" > Date: Fri, 29 Jun 2001 00:00:56 -0400 > > > > maybe i'm missing the bus on this one, but shouldn't the linker script > be > > > built-in, anyway? at least it is on the other main GNU toolchain i am > using > > > right now (arm-elf). > > > > It should of course. But DJGPP releases of binutils still didn't have > > needed features. So I suggested a way out as a temporary workaround > > i don't see what the problem is, then... Let me explain the problem. A built-in script is just that: built-in; you cannot easily change it without rebuilding Binutils. So if, for some reason, you need to modify the script (say, a new release of GCC or djdev requires such changes), you need to produce another Binutils distro and tell all users to upgrade. Binutils is a large and complex distribution, so we would like to avoid telling users to install a new one too frequently. In other words, using the built-in script doesn't solve the problem at hand: there's a dependency between djdev, GCC, and Binutils because they all might require changes in the script. Whether the script is in a file or built in is immaterial. Having the script on a file has a small advantage in that it is easier to replace.