From:	"Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To:	<djgpp-workers AT delorie DOT com>
Subject:	Linker scripts (was Re: Where does gcc -o foo make foo.exe)
Date:	Sat, 13 Jan 2001 13:32:43 +0100
Message-ID:	<NEBBIOJNGMKPNOBKHCGHOEILCAAA.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:	<9003-Sat13Jan2001092333+0200-eliz@is.elta.co.il>
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
Importance:	Normal
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id HAA12725
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

> It's true that a stand-alone linker will make a stubified executable,
> but I doubt if users want to bypass the linker script, because many
> other things will break for them (if they want a DJGPP program).
Oh, I don't know. Mark seems to be keeping the built-in script up to
date quite nicely. As long as we have one of our own keeping an eye on
ld's built-in script, I see no reason to have our own.
If you insist on more control, ld could be forced to use scripts from
the filesystem (in $DJDIR/lib/ldscripts, I think) instead of the
built-in ones. This even allows more control, as ld uses several slightly
different scripts (depending on whether it's linking an executable or
a relocateably object or whatever).

While we're on the subject of linker scripts: Mark, could you maybe add
the following lines to binutils' i386go32.sc (either just before or after
the DWARF entries you added). They're taken from i386coff.sc, so I expect
these are valid for us as well; I've been using these for a while without
problems anyway.

  /* STABS */
  .stab  0 ${RELOCATING+(NOLOAD)} : 
  {
    [ .stab ]
  }
  .stabstr  0 ${RELOCATING+(NOLOAD)} :
  {
    [ .stabstr ]
  }

- Raw text -