Re: Version 1.8.1 does not compile on Cygwin 1.7.14

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Jan 6, 2013, 21:34 UTC
Message-ID: <50E9EDE8.6090200@gmail.com>
In-Reply-To: <50E9E3C5.4070104@web.de>

On 01/06/2013 03:51 PM, Torsten Bögershausen wrote:

Show 11 quoted lines

> 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