This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: .exe magic


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]