Re: Version 1.8.1 does not compile on Cygwin 1.7.14

[Mark Levedahl <mlevedahl@gmail.com>]

On 01/06/2013 03:51 PM, Torsten Bögershausen wrote:
> Hm, I haven't understood the connection between the dll (cygwin1.dll 
> ?) which is used in runtime, and the header files which are used when 
> compiling. Are they updated at the same time when updating from 1.7.16 
> to 1.7.17 ? Until I updated my cygwin 1.7 (following Marks 
> recommendation) this did the trick for me: +ifeq ($(shell grep mingw 
> /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y) + 
> CYGWIN_V15_WIN32API=YesPlease +endif As an alternative, would this be 
> easier to read?
>> +# Define CYGWIN_V15_WIN32API for Cygwin versions up to 1.7.16
>
>

The cygwin distribution has a very large number of packages, each with 
its own unique version number and update rhythm, just as in any linux 
distro. There is no "cygwin version", just a version for each individual 
package. So, "Cygwin version 1.7.16" is really nonsensical: there is 
only cygwin.dll version 1.7.16.  What folks are noticing is a 
coincidence in the time when the cygwin dll package updated and when the 
old w32api was obsoleted. uname -r reports the cygwin dll version, not 
the version of any other package. Note that the cygwin api is "stable", 
meaning a package compiled against the 1.7.1 dll will still run against 
the current one: updating the cygwin dll does not require other packages 
to update.

The only hard linkage here is that the Cygwin developers are maintaining 
a legacy cygwin version (v1.5.x) as the newer dll series (v.1.7.x) 
dropped support for all Windows versions predating (I think) WinXP. So, 
someone on an old Windows version must use the legacy cygwin version 
which has not been updated since the first v1.7 dll was released, nor 
are there any plans by the developers to ever update the v1.5 packages. 
Cygwin 1.5 lives in a separate distribution repository, with packages 
frozen in time as of the last updates prior to going to v1.7 (packages 
compiled against v1.7 will not run on v.1.5).

So, encountering a v1.5.x dll is a guarantee of using the older w32api 
shared with the mingw project, rather than the current one now 
maintained by the mingw64 project. However, a cygwin with any v1.7.x dll 
could in theory have either w32api installed, or in theory yet another 
newer one we don't know about yet. Unless and until the w32api 
establishes a version number (independent of the Windows API version), 
we have nothing reliable to use.

Therefore, if using the v1.7 series, *update*

Mark