Re: perl-5.18.4
On Jan 23 13:00, Reini Urban wrote: On 01/23/2015 06:39 AM, Corinna Vinschen wrote: Are you still with us? Not really, sorry. Just lurking, but not much time to work in cygwin anymore. All my packages are up for grabs. I'm sorry to read that. Andrew, can we get a goldstar for Reini, especially for maintaining perl for so long? clisp was broken upstream with the change to dynamic modules, the rest should be trivial to maintain. I marked your packages as orphaned in the maintainer file, except for perl which I foisted on Achim. Achim, would you also like to take over perl-IO-Tty, perl-libwin32, and perl-Win32-GUI? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAJvf9ewDJ9.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Hi Ken, On Jan 23 08:48, Ken Brown wrote: On 1/14/2015 4:19 PM, Ken Brown wrote: It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. My guess is correct. lisp.exe uses bit 31 (counting from the LSB) as a marker during garbage collection, and this is incompatible with Cygwin's use of high memory for the heap. I think I know how to fix this (by defining LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet. Given that by default *all* addresses used for 64 bit Cygwin processes are beyond the 2GB border, it's kind of tricky to use bit 31 for anything. But even then, the same code would fail on 32 bit Windows as well, if it's running under WOW64 or a 32 bit kernel started with the /3GB flag (or it's successor). In both cases Cygwin would happily use the addresses beyond 0x8000 for the heap. So, from that I conclude that using bit 31 for any dubious reason is inherently broken. I hope that the LINUX_NOEXEC_HEAPCODES stuff works, and if so, it should be used for the 32 bit build as well. I'd like to know Reini's intentions before investing any more time in this. BTW, I am *not* qualified to take over as clisp maintainer. I've never used clisp, and I know nothing about it other than the tiny bit I've learned from debugging the crash I mentioned above. Well, it seems you're now stuck with it. slashdot I, for one, welcome our new clisp overlord! /slashdot *Duck* Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJ780dfNWjr.pgp Description: PGP signature
Re: SSH key for upload access
On Fri, 2015-01-23 at 21:31 +0200, Serge Lamikhov-Center wrote: Name: Serge Lamikhov-Center Package: ELFIO BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by Serge@Panther from OpenSSH B3NzaC1yc2EDAQABAAABAQCzSJICfBlWFshj6QZMfRXgZvitanr6lpub+A42vZ 5CQpY8zNUeGUkwl2WljcT6gY4RkkNqc0Pg8Ajn9BZJbnQdu7m5DtpmV9dDIiWadmNKYyvZ CtWber2gHeBMQNuGs3yZwbezEMYvIJe7P9fW0kPkaUYYjnfntz1L3Cqt+65iE6SzZmw331 lIXBMrgNxeoJWXHhTaEc4G4U7LeylEYpd/JotQ0rwzxL5VXENEDxCFEfN9I/msAfjDNwlY UjJ+EWHiupfBiC6K1pQi1Ukg0ggs8YzTOnB78oesW+tH+pFTKRxWycmVb/TwDOfkMSaZ5c JbX8mA1UyDse231sjlU8kZ END SSH2 PUBLIC KEY Key installed. -- Yaakov
Re: [HEADSUP] Dropping libopenssl098 from distro
I, for one, welcome our new clisp overlord! ALL HAIL THE CLISP OVERLORD
Re: perl-5.18.4
On 01/23/2015 06:39 AM, Corinna Vinschen wrote: On Jan 23 05:50, Reini Urban wrote: 2015-01-19 4:02 GMT-06:00 Corinna Vinschen: On Jan 19 10:36, Marco Atzeri wrote: On 1/19/2015 9:55 AM, Corinna Vinschen wrote: Still, why? Is it real backward incompat, or just due to DLL versioning? Does DLL versioning really make sense here? Usually, if the new DLL is only providing new stuff but not breaking backward compat, we're not bumping the DLL version. Corinna looking at the Changelog, they are breaking API http://perldoc.perl.org/perl5180delta.html#Incompatible-Changes http://perldoc.perl.org/perl5200delta.html#Incompatible-Changes Oh well. Yes. BTW: 5.22 will be about 1.8 times faster on perl-heavy tasks. So you are still here, somehow? You didn't bother to reply for the last three months, so I'm wondering, what are your plans as Cygwin maintainer? You maintain quite a couple of packages, some of them not yet available as 64 bit packages: catdoc clisp ctris fcgi ffcall libsigsegv libtextcat mathomatic parrot perl-io-tty perl-libwin32 perl-win32-gui rakudo scsh tesseract-ocr Are you still with us? Not really, sorry. Just lurking, but not much time to work in cygwin anymore. All my packages are up for grabs. clisp was broken upstream with the change to dynamic modules, the rest should be trivial to maintain. signature.asc Description: OpenPGP digital signature
SSH key for upload access
Name: Serge Lamikhov-Center Package: ELFIO BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by Serge@Panther from OpenSSH B3NzaC1yc2EDAQABAAABAQCzSJICfBlWFshj6QZMfRXgZvitanr6lpub+A42vZ 5CQpY8zNUeGUkwl2WljcT6gY4RkkNqc0Pg8Ajn9BZJbnQdu7m5DtpmV9dDIiWadmNKYyvZ CtWber2gHeBMQNuGs3yZwbezEMYvIJe7P9fW0kPkaUYYjnfntz1L3Cqt+65iE6SzZmw331 lIXBMrgNxeoJWXHhTaEc4G4U7LeylEYpd/JotQ0rwzxL5VXENEDxCFEfN9I/msAfjDNwlY UjJ+EWHiupfBiC6K1pQi1Ukg0ggs8YzTOnB78oesW+tH+pFTKRxWycmVb/TwDOfkMSaZ5c JbX8mA1UyDse231sjlU8kZ END SSH2 PUBLIC KEY
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/23/2015 3:09 PM, Corinna Vinschen wrote: Hi Ken, On Jan 23 08:48, Ken Brown wrote: On 1/14/2015 4:19 PM, Ken Brown wrote: It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. My guess is correct. lisp.exe uses bit 31 (counting from the LSB) as a marker during garbage collection, and this is incompatible with Cygwin's use of high memory for the heap. I think I know how to fix this (by defining LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet. Given that by default *all* addresses used for 64 bit Cygwin processes are beyond the 2GB border, it's kind of tricky to use bit 31 for anything. But even then, the same code would fail on 32 bit Windows as well, if it's running under WOW64 or a 32 bit kernel started with the /3GB flag (or it's successor). In both cases Cygwin would happily use the addresses beyond 0x8000 for the heap. So, from that I conclude that using bit 31 for any dubious reason is inherently broken. I hope that the LINUX_NOEXEC_HEAPCODES stuff works, and if so, it should be used for the 32 bit build as well. Sorry, I should have been more clear. I was only talking about the 32-bit build. I haven't yet seriously tried the 64-bit build. I'd like to know Reini's intentions before investing any more time in this. BTW, I am *not* qualified to take over as clisp maintainer. I've never used clisp, and I know nothing about it other than the tiny bit I've learned from debugging the crash I mentioned above. Well, it seems you're now stuck with it. slashdot I, for one, welcome our new clisp overlord! /slashdot Thanks a lot. I'll see if I can at least get version 3.48 or 3.49 built on both platforms. But in view of what Reini said about it being broken upstream, I don't think I'll try to go further. Ken
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/23/2015 5:57 AM, Dr. Volker Zell wrote: gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn); I think the problem is that Status is used in /usr/include/w32api/rpcdce.h, and this conflicts with #define Status int. I ran into a similar problem when trying to build clisp. Ken
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/14/2015 4:19 PM, Ken Brown wrote: On 1/14/2015 12:46 PM, Achim Gratz wrote: Corinna Vinschen writes: Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. If it's a problem with the Cygwin DLL, it would be nice to get a bug report and, preferredly, an STC, so we have a chance to fix this. AFAIK it's the same problem that produced the same symptoms in sqlite: using a non-Cygwin API. So no, I don't think the Cygwin DLL is to blame. Apart from that, I was only talking about the 32 bitr version anyway. It requires the wrong libopenssl and needs a simple rebuild for now. One of the things holding a port off is libsigsegv, IIRC. This is a bit annoying. Libsigsegv should be optional, not required. I have no idea whether that's possible for clisp. It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. My guess is correct. lisp.exe uses bit 31 (counting from the LSB) as a marker during garbage collection, and this is incompatible with Cygwin's use of high memory for the heap. I think I know how to fix this (by defining LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet. I'd like to know Reini's intentions before investing any more time in this. BTW, I am *not* qualified to take over as clisp maintainer. I've never used clisp, and I know nothing about it other than the tiny bit I've learned from debugging the crash I mentioned above. Ken
Re: perl-5.18.4
2015-01-19 4:02 GMT-06:00 Corinna Vinschen: On Jan 19 10:36, Marco Atzeri wrote: On 1/19/2015 9:55 AM, Corinna Vinschen wrote: On Jan 15 18:51, Achim Gratz wrote: I've finally managed to produce a working Perl including debuginfo via cygport. Thanks! Corinna Vinschen writes: However, why does a bump from 5.x to 5.y require a rebuild of other packages? Is the perl stuff backward incompatible from one minor version to the other?!? Anything linked against the Perl DLL must be rebuilt. Still, why? Is it real backward incompat, or just due to DLL versioning? Does DLL versioning really make sense here? Usually, if the new DLL is only providing new stuff but not breaking backward compat, we're not bumping the DLL version. Corinna looking at the Changelog, they are breaking API http://perldoc.perl.org/perl5180delta.html#Incompatible-Changes http://perldoc.perl.org/perl5200delta.html#Incompatible-Changes Oh well. Yes. BTW: 5.22 will be about 1.8 times faster on perl-heavy tasks.
Re: [HEADSUP] Dropping libopenssl098 from distro
Volker Zell writes: Hi I'm on business, no access to the logs...I will come back to this on friday. Here we are Ciao Volker Vin Shelton writes: Volker - I can build XEmacs on 32-bit Cygwin. What doesn't work for you? gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn); ^ In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:473:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoA(RPC_CSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg); ^ /usr/include/w32api/rpcdce.h:474:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoW(RPC_WSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg); ^ In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:555:59: error: unknown type name 'RPC_MGMT_AUTHORIZATION_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcMgmtSetAuthorizationFn(RPC_MGMT_AUTHORIZATION_FN AuthorizationFn); ^ In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
Re: [HEADSUP] Dropping libopenssl098 from distro
Hi, Volker - Vin wrote: I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Volker wrote: Here we are A few thoughts: 1. You need to use the most recent XEmacs sources from mercurial. 2. You must have an old version of libpng installed, because 21.4.22 won't compile with the newer libpng (some structure members are hidden). 3. You will also need to add: #define stricmp strcasecmp to src/s/cygwin32.h 4. I will review the contents of xemacs-21.4.22-1.src.patch and promote at least your developer info and the above stricmp hack to the mercurial repo. 5. I have promised to release 21.4.23, so I will do that shortly after #4 above. - Vin
Re: perl-5.18.4
On Jan 23 05:50, Reini Urban wrote: 2015-01-19 4:02 GMT-06:00 Corinna Vinschen: On Jan 19 10:36, Marco Atzeri wrote: On 1/19/2015 9:55 AM, Corinna Vinschen wrote: Still, why? Is it real backward incompat, or just due to DLL versioning? Does DLL versioning really make sense here? Usually, if the new DLL is only providing new stuff but not breaking backward compat, we're not bumping the DLL version. Corinna looking at the Changelog, they are breaking API http://perldoc.perl.org/perl5180delta.html#Incompatible-Changes http://perldoc.perl.org/perl5200delta.html#Incompatible-Changes Oh well. Yes. BTW: 5.22 will be about 1.8 times faster on perl-heavy tasks. So you are still here, somehow? You didn't bother to reply for the last three months, so I'm wondering, what are your plans as Cygwin maintainer? You maintain quite a couple of packages, some of them not yet available as 64 bit packages: catdoc clisp ctris fcgi ffcall libsigsegv libtextcat mathomatic parrot perl-io-tty perl-libwin32 perl-win32-gui rakudo scsh tesseract-ocr Are you still with us? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp41h2a9Uts_.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Vin Shelton writes: Hi, Volker - Vin wrote: I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Volker wrote: Here we are A few thoughts: 1. You need to use the most recent XEmacs sources from mercurial. OK 2. You must have an old version of libpng installed, because 21.4.22 won't compile with the newer libpng (some structure members are hidden). I had a patch for this..see the xemacs.cygport file. 3. You will also need to add: #define stricmp strcasecmp to src/s/cygwin32.h In the current source we have ? 4. I will review the contents of xemacs-21.4.22-1.src.patch and promote at least your developer info and the above stricmp hack to the mercurial repo. Ah...ok 5. I have promised to release 21.4.23, so I will do that shortly after #4 above. Cool...thanks. I'll wait for that before going on. - Vin Ciao Volker
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 23 16:43, Dr. Volker Zell wrote: Ken Brown writes: On 1/23/2015 5:57 AM, Dr. Volker Zell wrote: gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn); I think the problem is that Status is used in /usr/include/w32api/rpcdce.h, and this conflicts with #define Status int. I ran into a similar problem when trying to build clisp. Any simple fix/workaround for this ? It's a bug in the header, because it's polluting the namespace with unnecessary usage of Status as parameter names in prototypes. The header should use __status__ or drop them entirely. What you could try is either one of - Change the order of the header files, so that the windows headers are included before the private header defining Status. - Or, prior to including the Windows headers, push the macro and undefine it, after including the windows headers, pop the macro: #pragma push_macro (Status) #undef Status #include windows.h #pragma pop_macro (Status) - Or, you could not include windce.h at all if you don't need any of it: #define __RPCDCE_H__ #include windows.h ... Apart from that, the header should be fixed in Mingw-w64. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3KvBQGHGzV.pgp Description: PGP signature
