Tue Apr 17 23:17:00 GMT 2007
Larry Hall (Cygwin <reply-to-list-only-lh <at> cygwin.com> writes:
> Here's a naive thought. See if it makes any sense. We have lots of
> complicated logic to try to transparently handle ".exe" extensions.
> We have ".exe" extensions because Windows 9x/Me requires it to execute
> binaries. For the upcoming Cygwin 1.7 release (date TBD), we're dropping
> support for Windows 9x/Me. Does it follow that complex ".exe" logic
> could be dropped from 1.7 as a result?
Interesting thought. But it is more than just cygwin 1.7.0 that would have to
be changed; we would also need a new release of gcc that no longer added an
automatic .exe to files as they are compiled. And there might be some severe
repurcussions in automake/autoconf where they currently are coded to handle
$(EXEEXT) all over the place, if they do it based on hostname rather than on
what the default gcc output is. I would have to remove some of the .exe magic
I've added in coreutils (but it would mean I'm closer to an upstream image).
> I realize this would be a hard break with the 1.5 Cygwin series since it
> would force all Cygwin packages to remove the ".exe" extensions, thereby
> excluding 9x/Me users from these package updates - assuming they would
> otherwise be compatible - even though the Cygwin package would not be. But
> there has to be something worse about it than just this. I'm mean, this
> has to be a real stupid idea...
I think it has merit. But there are some caveats. It will BREAK libtool,
which currently RELIES on having ./foo and ./foo.exe in the same directory,
where ./foo.exe is a binary that satisfies the make dependency for foo$(EXEEXT)
and invokes ./foo, and where ./foo is a script that invokes the
real ./.libs/foo.exe with the correct environment variables set. And you are
correct that if we made the no-.exe extension for cygwin-created executables
mandatory, that every packager with binaries would have to update their package
to the new 1.7.0 scheme.
On the other hand, this would be a good idea to prune away any unmaintained
packages. And if we go this way, we could introduce any other binary
incompatible change that makes cygwin1.dll more efficient but requires the
recompile (such as the change from 1.3.x to 1.5.0 to introduce 64-bit file
I don't know how likely it is to happen though; I'll let cgf and Corinna
comment on that.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin