On Apr 20 15:29, Bob Heckel wrote: > On Sat, Apr 20, 2013 at 2:52 PM, Corinna Vinschen wrote: > > This entire ifdef CYGWIN32 block is in another block handling I386. > > It needs to be copied verbatim to the X86_64 block. This header > > file is a big mess! > > I couldn't agree more :) I thought I had it figured out a few > times, adding CYGWIN64 as a new platform, etc. but it has surprised me > more than once.
Just keep the CYGWIN32 define for both platforms. Look out for assumptions that something is 4 bytes where it might be 8 bytes now (long, pointers) and assumptions that CYGWIN32 is equivalent to I386 in CYGWIN32 bracketed code. That should get you a lot further. > It is including a win32 threads file at some point. Yes, but it uses Cygwin-specific code in that file, using pthreads. That should still work, just have an eye on the datatype divergence: While the long/unsigned long datatype is 8 byte in 64 bit Cygwin (LP64(*)), they are 4 byte in native Windows (LLP64). Therefore the Windows datatypes DWORD, LONG, and ULONG are still 4 byte on x86_64. Using pointers to long where a pointer to LONG is expected will result in undefined behaviour. > Thanks for the assistance Corinna. You're welcome. I'm through to a lot of the above in the meantime, so it makes sense to share this experience, I think. Corinna (*) http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
