From: "Tim Van Holder" To: Subject: Linker scripts (was Re: Where does gcc -o foo make foo.exe) Date: Sat, 13 Jan 2001 13:32:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 8bit 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 Precedence: bulk > 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 ] }