Mail Archives: djgpp-workers/1996/10/11/20:31:59
Robert Hoehne wrote:
>
> 1) The deafult target of ld is overwritten by the 'djgpp.djl' file. That
> means, if you call ld through gcc, the output format is 'coff-go32',
> the raw coff format.
I assume this is the name of the new linker script file. :)
> 2) The stubify.exe prepends to a coff image a hardcoded stub. That
> means, the environment variable $(STUB), which was mentioned by DJ,
> is used only by the binutils (including ld), when writing the
> 'coff-go32-exe' format. Here comes my suggestion to DJ, to change
> the stubify in that way, also to use that variable for determining
> the stub.
The problem here is that you'd have to completely rewrite stubify to use
a user-defined stub. As it stands, the way the stub is hardcoded into
stubify makes it very difficult to change. Besides, what exactly are
the advantages of using a different stub program anyway? There should
be no need for it unless you are writing a specialized program like
djverify, and for that it's easier to rebuild stubify anyway.
> 3) There is also an other misunderstanding. If you call gcc with
> gcc -o foo foo.c
> there is produced both, the coff image 'foo' and the exe 'foo.exe'
> in the same way like in V 2.00. Remember, that the deafult target
> of ld is used only, if not overwritten on command line or in the
> linker script (which is in DJGPP the case)
So what's your concern? This is exactly the point I was trying to make
- if you use 'foo' instead of 'foo.exe' as your target, neither gcc NOR
ld should produce 'foo.exe' by default.
> 4) Until stubify is not changed to use the optional external stub, you
> can use the following to build an exe file with your stub:
> - create the stub (name it mystub or something else)
> - set the environment variable STUB to point to this file
> - link your program with gcc and outputfile without the exe suffix
> - now use objcopy to create the exe (objcopy knows about the
> STUB variable)
> objcopy --output-target=coff-go32-exe foo foo.exe
Is this a workable solution? I thought that stubify existed for a
reason - if it is this easy to set up your own custom stub I don't see
why we bother with a specialized program. There must be some sort of
drawback here. Besides, why would we need all sorts of customized stub
programs? On Unix systems you don't need a stub at all, and there is
only one DOS.
> > 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).
> >
> What you are missing? The only thing, which you want to change, is
> in point 2) by not creating the exe file (in addition to the coff
> image).
That IS my point. I think the default behavior for 2 should be changed,
as it is counter-intuitive. If the user wants foo.exe, he/she should
have to say so explicitly.
I think you missed the entire point of my post - I wasn't saying that I
want to start appending all sorts of different custom stubs to my
programs, I was saying that I should be able to compile and _only_
generate an image file. The djverify example is just that, an example.
--
John M. Aldrich <fighteer AT cs DOT com>
* Anything that happens, happens.
* Anything that, in happening, causes something else to happen,
causes something else to happen.
* Anything that, in happening, causes itself to happen again, happens
again.
* It doesn't necessarily do it in chronological order, though.
--- Douglas Adams
- Raw text -