On Apr 15 22:41, Corinna Vinschen wrote: > On Apr 15 12:56, Nicolas Noble wrote: > > This is an issue > > when trying to compile a 64 bits binary that uses the win32 api, > > nothing more. > > 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.
Btw., the preceeding paragraph is even more true after fixing Mingw-w64's
winsock headers because in this case values like FIONREAD, FIOASYNC,
etc (*) will *collide* when using WinSock and Cygwin headers due to their
different values.
So, again, to be very clear: Never mix Cygwin's POSIX socket functions
and Cygwin's POSIX socket headers with Winsock headers and functions.
In theory only Cygwin should be a consumer of the Winsock headers and
functions in a Cygwin environment.
> The problem with the WInSock definition of FIONBIO (and probably others)
> is a bug in the w32api-headers and thus might be most effectifely
> handled upstream in the Mingw-w64 community.
>
> You're basically right about the redefinition of FIONBIO, but u_long is
> the type used by Microsoft and thus the Mingw-w64 project would probably
> like to keep it that way for compatibility with their upstream :)
>
> OTOH, u_long in an LP64 environment *must* have the same size as long,
> thus 8 bytes.
>
> 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)
Corinna
(*) FIONBIO is an exception beacuse its value in the Cygwin headers
is hardcoded to 0x8004667e for historical reasons.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
