Message-ID: <36474D55.F1AF4C29@gmx.net>
Date: Mon, 09 Nov 1998 19:15:17 -0100
From: Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Organization: none provided
X-Mailer: Mozilla 4.07 [de] (Win95; I)
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp AT delorie DOT com
Subject: Re: DJGPP 2.02 Beta 981027
References: <Pine DOT SUN DOT 3 DOT 91 DOT 981109101749 DOT 18112E-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

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        *
******************************************************