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: Cygwin 64bits gcc produces erroneous constants with the win32 headers.

On Apr 15 12:56, Nicolas Noble wrote:
> On Fri, Apr 15, 2016 at 12:23 PM, Corinna Vinschen
> <> wrote:
> > On Apr 15 12:05, Nicolas Noble wrote:
> >> I originally entered a bug on msys2's bug tracker, but it turns out
> >> they only repackage cygwin packages, and I have verified this is an
> >> issue on cygwin too, so I am now sending that report here.
> >>
> >> Original entry:
> >>
> >>
> >>
> >>
> >>
> >> Basically, the 64 bits "gcc-core" and "w32api-headers" cygwin packages
> >> aren't really compatible with each others.
> >
> > They are not supposed to.  You have to make sure to separate the
> > win32 and Cygwin headers carefully.
> I'm not sure I am getting that reply. The gcc-core package is only a
> compiler, and I am talking about the "gcc" binary contained within.
> The example I am showing is technically using only the w32api-headers,
> trying to use the win32 api as described here:
> >
> >> As far as I understand,
> >> this isn't an issue already documented here:
> >>
> >
> > It's documented in
> 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.

> otherwise it would have taken me a lot
> more time to understand what was going on here. I am talking about the
> fact that the cygwin-provided w32api-headers package doesn't properly
> work with the cygwin-provided 64 bits gcc. Unless I am mistaken
> somewhere, this isn't an issue with the example code. 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.

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature

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