Cygwin 64bits gcc produces erroneous constants with the win32 headers.

Nicolas Noble
Fri Apr 15 20:54:00 GMT 2016

>> Right, but that isn't the same thing. I am well aware of the various
>> issues tied with sizeof(long),
> Sorry, I wasn't aware of this since you wrote something along the lines
> of gcc should make sizeof(long) == 4 which just doesn't make sense in an
> LP64 environment.

I can see how this was confusing, yes. I was trying to make the point that

> One problem is that you're not supposed to use WinSock or the winsock
> headers when compiling Cygwin applications.  Use the Cygwin POSIX headers
> and Cygwin socket functions instead.  If you use WinSock headers and/or
> functions and it breaks, you got to keep the pieces.

Okay. See, that's something I didn't see documented anywhere :-) The
documentation seems to say that it's fair game to use the Win32 API as
long as you're linking the libraries in, and no mention of what is and
isn't acceptable.

Note that I'm not talking about mixing up Cygwin sockets and WinSock
sockets. I'm simply talking about compiling a piece of code that is
100% WinSock aware, and exposes an API that doesn't even mention
sockets. Think, I don't know, libcurl in easy mode for instance. Or
maybe a "publish tweets on twitter" library. It should be acceptable
that said static code be fully independent, and usable with cygwin

Of course, solutions might be to say "sorry, it doesn't actually
compile properly with Cygwin, please only use mingw-w64 to compile it,
then link the resulting static .a file with your project" or "sorry,
using Cygwin, you'll have to use the posix-version of the library,
thus having to lose some amount of performance due to the Cygwin
socket translation layer", but I find neither very appropriate. I'd
rather have the code be compatible with cygwin's compiler and
environment, while retaining the ability to fully use the WinSock API.

> However, Mingw-w64 already contains a lot of changes to accommodate
> the Cygwin LP64 environment, and incidentally there's already a type
> available which does the right thing, so it might be a good idea to
> suggest using that:
> #define FIONBIO _IOW('f',126,__ms_u_long)

So you're saying that the w32api-headers cygwin package actually comes
from mingw-w64 ? I can go and bug them instead then :-)

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list