Mail Archives: cygwin/2007/04/18/11:12:35
Eric Blake wrote:
> 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).
Seems manageable but that's also a naive statement. ;-) I know next to
nothing of the complexities of automake/autoconf.
>> 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.
Forgot about libtool and it's reliance on ./foo and ./foo.exe. :-(
> 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
> offsets).
True, though strictly speaking, this change shouldn't require a recompile of
most packages. A simple renaming should suffice in most cases.
> I don't know how likely it is to happen though; I'll let cgf and Corinna
> comment on that.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
_____________________________________________________________________
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -