Mail Archives: djgpp/1998/11/09/14:22:37
Eli Zaretskii wrote :
>
> So, if djgpp.djl from GCC *is* the recommended script, let's decide
> whether coff-go32-exe should be the default format, and if not, let's
> change gcc281b.zip on SimTel. If people think coff-go32-exe *should*
> be the default format, I would like to hear why, and discuss possible
> implications and alternatives.
OK, here my opinion: For me the djgpp.djl from gcc281b.zip should
be the default format, since it takes care about possible changes
of gcc (as it was needed for the exception support).
Setting there the 'coff-go32-exe' format as the default output
format for the linker was for me (as I was the first person who
changed this) with the tought, that we can someday remove the
stubify program (and with this the needed hack in the specs
file).
Directly producing the stubified executable has many
improvements:
1) Time: There is no extrac step needed to produce the stubified
exe from the raw coff file.
2) Disk-space: If you produce (like for instance I do) executables
with a size (including the debug information) of some MB and
don't have so much free disk space, you will see this.
3) You can produce on the fly modified stubs for your programs,
by simply pointing an environment variable to a modified stub
(for instance to have a larger default stack). This is not
possible with stubify, only manually stubediting it afterwards.
4) When you call
gcc -o foo foo.o
you will get foo, and not foo _and_ foo.exe which might be confusing
sometimes. If you need the .exe suffix, you should call
gcc -o foo.exe foo.o
OK, these are the improvements as I can see them.
The next to this topic is to discuss, where the possible problems
are when changing the default output format for the linker.
Currently there is only the output format changed and nothing
else, which means, many of the above mentioned improvements are
not used so we should check, where are problems when we have
two files 'foo' and 'foo.exe' where the first is also a stubified
executable. The only program which can't handle this (at least
I haven't heared any other) is ginstall from the GNU fileutils
and so I think, the behaviour of ginstall should be changed.
I really don't understand, why the following command
ginstall foo c:/bin
produces two different files, depending on the format of
foo. If foo is an unstubbed executable it installs it as
c:/bin/foo.exe
but if it is a stubified executable it installs as
c:/bin/foo
In my opinion, ginstall should either install the file in a given
directory ever with the same name as given on the commandline,
or ever (for executables) appending the .exe suffix (if it
doesn't have it already) or, if ginstall will not be changed,
you should know about this behaviour and then you should ever
give the destination filename explicit on the commandline like
ginstall foo c:/bin/foo.exe
> OTOH, if the script in gcc281b.zip is not necessary, I suggest to
The script has not only changed the output format, but also
makes the execption handling work for C++ programs.
Robert
--
******************************************************
* email: Robert Hoehne <robert DOT hoehne AT gmx DOT net> *
* Post: Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW: http://www.tu-chemnitz.de/~sho/rho *
******************************************************
- Raw text -