Message-ID:	<325DB90E.3B7D@cs.com>
Date:	Thu, 10 Oct 1996 20:03:42 -0700
From:	"John M. Aldrich" <fighteer AT cs DOT com>
Reply-To:	fighteer AT cs DOT com
Organization:	Three pounds of chaos and a pinch of salt
MIME-Version:	1.0
To:	Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
CC:	djgpp-workers AT delorie DOT com
Subject:	Linker script (Was Re: binutils 2.7 questions)
References:	<325E158C DOT 2245 AT blackmagic DOT tait DOT co DOT nz>

Bill Currie wrote:
> 
> Also, (this is for Robert, I think) should ld realy default to producing stubbed exe's?  It's a
> bit of a pain having to either use a .lnk file or -oformat option to get a raw coff file
> (although I can see why it would be that way, stops faq's of "how do I produce a valid exe file
> using ld...").

AFAIK, Robert just writes the IDE.  DJ's the one responsible for the ld
script behavior.  :)

That said, I have asked about this too and it is a problem, albeit a
minor one.  I actually ran into the problem recently when writing the
Makefile for my djverify program.  I wrote a custom stub (and thus had
to rebuild stubify.exe) for djverify, and since I didn't want to
overwrite the standard stubify in the process I just put the code in
with the rest of the djverify files.  But, since the default linker
behavior is to use the stubify in djgpp/bin, I have to explicitly
re-invoke my stubify on the image file after the program is compiled. 
The problem is that when I invoke gcc to produce the image (with -o
djvrfy2) I still get an executable that's stubified with the old stub. 
So my makefile is not only doing the work twice (stubifying with the old
stub and then re-stubifying with the custom one), but if you invoke it
with 'djvrfy2' as the target, it will never actually stubify with the
custom one, leaving you with an invalid 'djvrfy2.exe'.

Admittedly, this is a fairly unique occurrence.  (How many people are
going to write their own custom stubs, after all?)  But it illustrates a
minor pitfall with the default linker script setup.  What is my
recommended solution?  As I recall, the v1.x linker script did _not_
call 'coff2exe', and users had to do it manually.  But the v2 script
calls stubify whether you want it to or not.  I suggest the following
compromise:

1) If the user specifies an '.exe' as the output file, ld should call
stubify and remove the image (current behavior).

2) If the user specifies a non-'.exe' as the output file, ld should
produce the image, but not call stubify.

3) If the user doesn't specify an output file, ld should produce both
a.out and a.exe (current behavior).

Please don't jump all over me on this one - I'm just making a
recommendation that, from personal experience, would work
satisfactorily.  I am certain that the development team must have
discussed this issue when working on v2, but since I wasn't around when
that discussion was taking place I obviously don't know what was said. 
I invite comment both pro and con, but it is, after all, DJ's decision
alone.  :)

Thanks!

John

-- 
---------------------------------------------------------------------
| John M. Aldrich, aka Fighteer I  |        fighteer AT cs DOT com         |
| Plan:  To find ANYONE willing to |   http://www.cs.com/fighteer   |
| play Descent 2 on DWANGO!        | Tagline: <this space for rent> |
---------------------------------------------------------------------

- Raw text -