Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/18/2012 16:08, Corinna Vinschen wrote: On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Awesome, and now to wait for the avalanche of complaints :) signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 18 17:21, JonY wrote: On 10/18/2012 16:08, Corinna Vinschen wrote: On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Awesome, and now to wait for the avalanche of complaints :) You should probably break the news to the announce list gently. :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
gold stars Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Thu, Oct 18, 2012 at 12:32:00PM +0200, Corinna Vinschen wrote: On Oct 18 17:21, JonY wrote: On 10/18/2012 16:08, Corinna Vinschen wrote: On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Awesome, and now to wait for the avalanche of complaints :) You should probably break the news to the announce list gently. :) But, in the meantime, could we get some gold stars for this? This is a significant achievement. cgf
Re: gold stars Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 18 11:19, Christopher Faylor wrote: On Thu, Oct 18, 2012 at 12:32:00PM +0200, Corinna Vinschen wrote: On Oct 18 17:21, JonY wrote: On 10/18/2012 16:08, Corinna Vinschen wrote: On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Awesome, and now to wait for the avalanche of complaints :) You should probably break the news to the announce list gently. :) But, in the meantime, could we get some gold stars for this? This is a significant achievement. Jon already got a gold star for taking over w32api. But this is *still* a significant achievement, so we probably should take another one out of the vault for Jon. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gold stars Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/19/2012 00:00, Corinna Vinschen wrote: On Oct 18 11:19, Christopher Faylor wrote: On Thu, Oct 18, 2012 at 12:32:00PM +0200, Corinna Vinschen wrote: On Oct 18 17:21, JonY wrote: On 10/18/2012 16:08, Corinna Vinschen wrote: On Oct 17 23:09, Yaakov (Cygwin/X) wrote: On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Thanks, guys! Awesome, and now to wait for the avalanche of complaints :) You should probably break the news to the announce list gently. :) But, in the meantime, could we get some gold stars for this? This is a significant achievement. Jon already got a gold star for taking over w32api. But this is *still* a significant achievement, so we probably should take another one out of the vault for Jon. Thanks guys. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 17 06:43, JonY wrote: On 10/17/2012 06:19, JonY wrote: On 10/16/2012 23:32, Corinna Vinschen wrote: Are you waiting for more feedback or shall we upload? Are you mentally and ethically prepared to take the loads of complaints on the Cygwin ML? It's good to go if the Cygwin maintainers are OK with split out packages and a meta package. As for complaints, well, we'll see how it goes. I mean to say I'll try my best, within mortal limits :) Fear, mortal! Now is the time for retali... Uh, sorry, I got carried away. For serious stuff, see my reply to Yaakov's mail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 16 20:02, Yaakov (Cygwin/X) wrote: On Sat, 2012-10-13 at 13:36 +0800, JonY wrote: I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 I think the sdesc: is confusing. How about: sdesc: Windows API headers http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 sdesc: Windows API import libraries But wouldn't w32api-headers be a better name? You have a point there, Yaakov. In fact, you already set a precedent with your mingw packages, Jon. We have mingw64-headers and mingw64-runtime packages. I'm not *that* sure about the runtime name, but a consistent naming sounds like a good idea. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/17/2012 16:20, Corinna Vinschen wrote: On Oct 16 20:02, Yaakov (Cygwin/X) wrote: On Sat, 2012-10-13 at 13:36 +0800, JonY wrote: I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 I think the sdesc: is confusing. How about: sdesc: Windows API headers http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 sdesc: Windows API import libraries But wouldn't w32api-headers be a better name? You have a point there, Yaakov. In fact, you already set a precedent with your mingw packages, Jon. We have mingw64-headers and mingw64-runtime packages. I'm not *that* sure about the runtime name, but a consistent naming sounds like a good idea. Alright, will rename it. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/17/2012 17:23, JonY wrote: On 10/17/2012 16:20, Corinna Vinschen wrote: In fact, you already set a precedent with your mingw packages, Jon. We have mingw64-headers and mingw64-runtime packages. I'm not *that* sure about the runtime name, but a consistent naming sounds like a good idea. Alright, will rename it. OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Thu, 2012-10-18 at 06:17 +0800, JonY wrote: OK, renamed, I hope I did not mess it up this time. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-headers/w32api-headers-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-runtime/w32api-runtime-3.0b_svn5431-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-100.0-1.tar.bz2 Uploaded. I have also switched the Fedora Cygwin toolchain to the mingw-w64 w32api packages. Yaakov
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/14/2012 02:12, Christopher Faylor wrote: On Sat, Oct 13, 2012 at 12:45:43PM -0400, Christopher Faylor wrote: On Sun, Oct 14, 2012 at 12:28:42AM +0800, JonY wrote: On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? Nope. Only old packages. Should have made that clear. However, if you make the appropriate subdirectories in cygwin's release ^ first area it will then work. Ping. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 16 18:05, JonY wrote: On 10/14/2012 02:12, Christopher Faylor wrote: On Sat, Oct 13, 2012 at 12:45:43PM -0400, Christopher Faylor wrote: On Sun, Oct 14, 2012 at 12:28:42AM +0800, JonY wrote: On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? Nope. Only old packages. Should have made that clear. However, if you make the appropriate subdirectories in cygwin's release ^ first area it will then work. Ping. Are you waiting for more feedback or shall we upload? Are you mentally and ethically prepared to take the loads of complaints on the Cygwin ML? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/16/2012 23:32, Corinna Vinschen wrote: On Oct 16 18:05, JonY wrote: On 10/14/2012 02:12, Christopher Faylor wrote: On Sat, Oct 13, 2012 at 12:45:43PM -0400, Christopher Faylor wrote: On Sun, Oct 14, 2012 at 12:28:42AM +0800, JonY wrote: On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? Nope. Only old packages. Should have made that clear. However, if you make the appropriate subdirectories in cygwin's release ^ first area it will then work. Ping. Are you waiting for more feedback or shall we upload? Are you mentally and ethically prepared to take the loads of complaints on the Cygwin ML? It's good to go if the Cygwin maintainers are OK with split out packages and a meta package. As for complaints, well, we'll see how it goes. signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/17/2012 06:19, JonY wrote: On 10/16/2012 23:32, Corinna Vinschen wrote: Are you waiting for more feedback or shall we upload? Are you mentally and ethically prepared to take the loads of complaints on the Cygwin ML? It's good to go if the Cygwin maintainers are OK with split out packages and a meta package. As for complaints, well, we'll see how it goes. I mean to say I'll try my best, within mortal limits :) signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Sat, 2012-10-13 at 13:36 +0800, JonY wrote: I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 I think the sdesc: is confusing. How about: sdesc: Windows API headers http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 sdesc: Windows API import libraries But wouldn't w32api-headers be a better name? Yaakov
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 13 13:36, JonY wrote: On 10/12/2012 18:57, Yaakov (Cygwin/X) wrote: On Fri, 2012-10-12 at 18:27 +0800, JonY wrote: Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. Not only that, but they are also useless with the cygwin compiler, with is currently 32-bit only. IMO w32api should be built with the native gcc4, and configured --enable-lib32 --disable-lib64 until such time that we have a 64-bit Cygwin. OK, I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? I like the idea. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 It would just be nice if your download paths would reflect the directory layout :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Sat, Oct 13, 2012 at 05:37:01PM +0200, Corinna Vinschen wrote: On Oct 13 13:36, JonY wrote: On 10/12/2012 18:57, Yaakov (Cygwin/X) wrote: On Fri, 2012-10-12 at 18:27 +0800, JonY wrote: Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. Not only that, but they are also useless with the cygwin compiler, with is currently 32-bit only. IMO w32api should be built with the native gcc4, and configured --enable-lib32 --disable-lib64 until such time that we have a 64-bit Cygwin. OK, I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? I like the idea. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 It would just be nice if your download paths would reflect the directory layout :} If you want to use a still-in-testing utility, you could try the get-cygwin-package program in /sourceware/infra/bin/ on sourceware.org. Just cut/paste the whole content of a cygwin-apps email (including From: part) into the program's stdin and it will attempt to figure out where to put stuff automatically. It first downloads to a staging area, which should be obvious from the messages displayed. You then have to move or copy the files to the correct location. Eventually I want to make that happen automatically and offer some options for trimming older files. Currently I use either 'mv' or 'cp --link'/rm to move files, depending on whether the package contains subdirectories. cgf
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Oct 13 11:47, Christopher Faylor wrote: On Sat, Oct 13, 2012 at 05:37:01PM +0200, Corinna Vinschen wrote: On Oct 13 13:36, JonY wrote: On 10/12/2012 18:57, Yaakov (Cygwin/X) wrote: On Fri, 2012-10-12 at 18:27 +0800, JonY wrote: Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. Not only that, but they are also useless with the cygwin compiler, with is currently 32-bit only. IMO w32api should be built with the native gcc4, and configured --enable-lib32 --disable-lib64 until such time that we have a 64-bit Cygwin. OK, I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? I like the idea. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 It would just be nice if your download paths would reflect the directory layout :} If you want to use a still-in-testing utility, you could try the get-cygwin-package program in /sourceware/infra/bin/ on sourceware.org. Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? signature.asc Description: OpenPGP digital signature
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Sun, Oct 14, 2012 at 12:28:42AM +0800, JonY wrote: On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? Nope. Only old packages. Should have made that clear. However, if you make the appropriate subdirectories in cygwin's release area it will then work. cgf
Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On Sat, Oct 13, 2012 at 12:45:43PM -0400, Christopher Faylor wrote: On Sun, Oct 14, 2012 at 12:28:42AM +0800, JonY wrote: On 10/14/2012 00:08, Corinna Vinschen wrote: Sounds really interesting. I just tried it, but it fails to download the w32api-libs and w32api-includes packages: generating package name - package directory mapping... Done couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 couldn't find a package dir for http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 - /sourceware/snapshot-tmp/cygwin/release/w32api/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint - /sourceware/snapshot-tmp/cygwin/release/w32api/setup.hint Corinna It doesn't handle new packages? Nope. Only old packages. Should have made that clear. However, if you make the appropriate subdirectories in cygwin's release ^ first area it will then work.
Re: [ITA] w32api-3.0b_svn5368-1
On 10/12/2012 01:10, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-10 at 23:55 -0500, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-10 at 11:09 +0200, Corinna Vinschen wrote: Other than that, was there any other roadblock on the way to the Mingw64 headers? I think there's still one issue wrt xorg-server; I need to check that again. SVN trunk (r5430) is GTG, but AFAICS at least r5384 should do. Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Fri, 2012-10-12 at 18:27 +0800, JonY wrote: Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. Not only that, but they are also useless with the cygwin compiler, with is currently 32-bit only. IMO w32api should be built with the native gcc4, and configured --enable-lib32 --disable-lib64 until such time that we have a 64-bit Cygwin. Yaakov
[ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]
On 10/12/2012 18:57, Yaakov (Cygwin/X) wrote: On Fri, 2012-10-12 at 18:27 +0800, JonY wrote: Any thoughts on if I should put up multilib w32api? I'm having second thoughts now since I realize you can't simply build them with ootb Cygwin tools. Not only that, but they are also useless with the cygwin compiler, with is currently 32-bit only. IMO w32api should be built with the native gcc4, and configured --enable-lib32 --disable-lib64 until such time that we have a 64-bit Cygwin. OK, I decided do a simpler split out version due to the way the source package is built, with w32api as a meta package. If required I can redo it into a single package. Preference? Comments? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-libs/w32api-libs-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api-includes/w32api-includes-3.0b_svn5431-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/meta/w32api-100.0-1.tar.bz2 signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Oct 10 23:55, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-10 at 11:09 +0200, Corinna Vinschen wrote: On Oct 10 10:24, Corinna Vinschen wrote: On Oct 9 22:48, Yaakov (Cygwin/X) wrote: Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to trigger inaddr.h's include guard? Will do. But that only helps in your case after we updated to the next Cygwin version. I guess you already added such a #define to the bind code? Can you check if my patch to cygwin/in.h works for you? WFM. Thanks for testing. Other than that, was there any other roadblock on the way to the Mingw64 headers? I think there's still one issue wrt xorg-server; I need to check that again. Ok. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On Wed, 2012-10-10 at 23:55 -0500, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-10 at 11:09 +0200, Corinna Vinschen wrote: Other than that, was there any other roadblock on the way to the Mingw64 headers? I think there's still one issue wrt xorg-server; I need to check that again. SVN trunk (r5430) is GTG, but AFAICS at least r5384 should do. Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On Oct 9 22:48, Yaakov (Cygwin/X) wrote: On Tue, 2012-10-09 at 12:06 +0200, Corinna Vinschen wrote: Why does bind include iphlpapi.h at all? As a Cygwin application it's not supposed to use Windows and Cygwin network functions in parallel. Because you asked me to make it so: http://www.cygwin.com/ml/cygwin-apps/2009-01/msg00097.html Oops, *blush*. So I hacked the code to do exactly that: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/bind;a=blob;f=9.7.1-lwconfig-win32.patch;h=d05c009 Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to trigger inaddr.h's include guard? Will do. But that only helps in your case after we updated to the next Cygwin version. I guess you already added such a #define to the bind code? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On Oct 10 10:24, Corinna Vinschen wrote:
On Oct 9 22:48, Yaakov (Cygwin/X) wrote:
On Tue, 2012-10-09 at 12:06 +0200, Corinna Vinschen wrote:
Why does bind include iphlpapi.h at all? As a Cygwin application it's not
supposed to use Windows and Cygwin network functions in parallel.
Because you asked me to make it so:
http://www.cygwin.com/ml/cygwin-apps/2009-01/msg00097.html
Oops, *blush*.
So I hacked the code to do exactly that:
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/bind;a=blob;f=9.7.1-lwconfig-win32.patch;h=d05c009
Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to
trigger inaddr.h's include guard?
Will do. But that only helps in your case after we updated to the next
Cygwin version. I guess you already added such a #define to the bind
code?
Can you check if my patch to cygwin/in.h works for you?
Index: include/cygwin/in.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/in.h,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- include/cygwin/in.h 6 Jul 2012 13:52:18 - 1.18
+++ include/cygwin/in.h 10 Oct 2012 08:36:33 - 1.19
@@ -112,11 +112,15 @@ enum
IPPORT_USERRESERVED = 5000
};
+/* Avoid collision with Mingw64 headers. */
+#ifndef s_addr
/* Internet address. */
struct in_addr
{
in_addr_t s_addr;
};
+#define s_addr s_addr
+#endif
/* Request struct for IPv4 multicast socket ops */
Other than that, was there any other roadblock on the way to the Mingw64
headers?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On Wed, 2012-10-10 at 11:09 +0200, Corinna Vinschen wrote: On Oct 10 10:24, Corinna Vinschen wrote: On Oct 9 22:48, Yaakov (Cygwin/X) wrote: Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to trigger inaddr.h's include guard? Will do. But that only helps in your case after we updated to the next Cygwin version. I guess you already added such a #define to the bind code? Can you check if my patch to cygwin/in.h works for you? WFM. Other than that, was there any other roadblock on the way to the Mingw64 headers? I think there's still one issue wrt xorg-server; I need to check that again. Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On Oct 2 16:54, JonY wrote: On 9/24/2012 12:27, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? jturney, did you patch(es) get committed yet? Unfortunately, I did find another regression, this time with bind. The mingw-w64 inaddr.h header conflicts with Cygwin's netinet/in.h: In file included from /usr/include/w32api/ras.h:11:0, from /usr/include/w32api/mprapi.h:10, from /usr/include/w32api/iprtrmib.h:9, from /usr/include/w32api/iphlpapi.h:13, from test.c:4: /usr/include/w32api/inaddr.h:17:16: error: redefinition of ‘struct in_addr’ /usr/include/cygwin/in.h:116:8: note: originally defined here Yaakov Ping, anything new? Why does bind include iphlpapi.h at all? As a Cygwin application it's not supposed to use Windows and Cygwin network functions in parallel. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On 10/9/2012 18:06, Corinna Vinschen wrote: On Oct 2 16:54, JonY wrote: On 9/24/2012 12:27, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? jturney, did you patch(es) get committed yet? Unfortunately, I did find another regression, this time with bind. The mingw-w64 inaddr.h header conflicts with Cygwin's netinet/in.h: In file included from /usr/include/w32api/ras.h:11:0, from /usr/include/w32api/mprapi.h:10, from /usr/include/w32api/iprtrmib.h:9, from /usr/include/w32api/iphlpapi.h:13, from test.c:4: /usr/include/w32api/inaddr.h:17:16: error: redefinition of ‘struct in_addr’ /usr/include/cygwin/in.h:116:8: note: originally defined here Yaakov Ping, anything new? Why does bind include iphlpapi.h at all? As a Cygwin application it's not supposed to use Windows and Cygwin network functions in parallel. Corinna I gathered from Yaakov that he wanted some fallback to the Windows DNS settings when /etc/resolv.conf isn't found. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Oct 9 19:48, JonY wrote: On 10/9/2012 18:06, Corinna Vinschen wrote: On Oct 2 16:54, JonY wrote: On 9/24/2012 12:27, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? jturney, did you patch(es) get committed yet? Unfortunately, I did find another regression, this time with bind. The mingw-w64 inaddr.h header conflicts with Cygwin's netinet/in.h: In file included from /usr/include/w32api/ras.h:11:0, from /usr/include/w32api/mprapi.h:10, from /usr/include/w32api/iprtrmib.h:9, from /usr/include/w32api/iphlpapi.h:13, from test.c:4: /usr/include/w32api/inaddr.h:17:16: error: redefinition of ‘struct in_addr’ /usr/include/cygwin/in.h:116:8: note: originally defined here Yaakov Ping, anything new? Why does bind include iphlpapi.h at all? As a Cygwin application it's not supposed to use Windows and Cygwin network functions in parallel. Corinna I gathered from Yaakov that he wanted some fallback to the Windows DNS settings when /etc/resolv.conf isn't found. In that case bind should use the Cygwin-provided POSIX resolver functions, IMHO. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On Tue, 2012-10-09 at 12:06 +0200, Corinna Vinschen wrote: Why does bind include iphlpapi.h at all? As a Cygwin application it's not supposed to use Windows and Cygwin network functions in parallel. Because you asked me to make it so: http://www.cygwin.com/ml/cygwin-apps/2009-01/msg00097.html So I hacked the code to do exactly that: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/bind;a=blob;f=9.7.1-lwconfig-win32.patch;h=d05c009 Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to trigger inaddr.h's include guard? Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On 9/24/2012 12:27, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? jturney, did you patch(es) get committed yet? Unfortunately, I did find another regression, this time with bind. The mingw-w64 inaddr.h header conflicts with Cygwin's netinet/in.h: In file included from /usr/include/w32api/ras.h:11:0, from /usr/include/w32api/mprapi.h:10, from /usr/include/w32api/iprtrmib.h:9, from /usr/include/w32api/iphlpapi.h:13, from test.c:4: /usr/include/w32api/inaddr.h:17:16: error: redefinition of ‘struct in_addr’ /usr/include/cygwin/in.h:116:8: note: originally defined here Yaakov Ping, anything new? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? jturney, did you patch(es) get committed yet? Unfortunately, I did find another regression, this time with bind. The mingw-w64 inaddr.h header conflicts with Cygwin's netinet/in.h: In file included from /usr/include/w32api/ras.h:11:0, from /usr/include/w32api/mprapi.h:10, from /usr/include/w32api/iprtrmib.h:9, from /usr/include/w32api/iphlpapi.h:13, from test.c:4: /usr/include/w32api/inaddr.h:17:16: error: redefinition of ‘struct in_addr’ /usr/include/cygwin/in.h:116:8: note: originally defined here Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On 9/4/2012 00:05, Jon TURNEY wrote: On 03/09/2012 16:59, Jon TURNEY wrote: So, how about the attached (minimal) change? (where NOBOOLTYPE is named whatever you think is appropriate) This time with correct patch attached... Done in trunk, used _NOBOOLTYPEDEF. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 9/4/2012 18:21, JonY wrote: On 9/4/2012 00:05, Jon TURNEY wrote: On 03/09/2012 16:59, Jon TURNEY wrote: So, how about the attached (minimal) change? (where NOBOOLTYPE is named whatever you think is appropriate) This time with correct patch attached... Done in trunk, used _NOBOOLTYPEDEF. I just made a last second change to _NO_BOOL_TYPEDEF for readability, sorry if I caused any inconvenience. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 20 20:15, JonY wrote: On 8/14/2012 16:02, Kai Tietz wrote: 2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Btw have you checked size with debugging-information, or without? Regards, Kai New version up. Was the first uploaded? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download None have been uploaded so far. I'm not sure of the current state of the discussion. Are the above w32api headers good to go or is a new version in the loop? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On 9/3/2012 18:34, Corinna Vinschen wrote: New version up. Was the first uploaded? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download None have been uploaded so far. I'm not sure of the current state of the discussion. Are the above w32api headers good to go or is a new version in the loop? Corinna Jon Turney says he's working on a patch for xorg-server to build with mingw-w64. Jon, any comments? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 03/09/2012 12:04, JonY wrote: On 9/3/2012 18:34, Corinna Vinschen wrote: New version up. Was the first uploaded? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download None have been uploaded so far. I'm not sure of the current state of the discussion. Are the above w32api headers good to go or is a new version in the loop? Jon Turney says he's working on a patch for xorg-server to build with mingw-w64. Jon, any comments? Almost right. The problem with BOOL redefinition affects the XWindows.h header in the x11proto package, which is (should be) included by all applications which need access to both the X11 and Win32 APIs, of which the xserver is the primary, but not only example. I really don't want to mess with this as I have no idea why this header differs in this regard from the mingw.org headers, or how it came to be the way it is (the svn history did not enlighten me much) So, how about the attached (minimal) change? (where NOBOOLTYPE is named whatever you think is appropriate) (I also attach a patch which un-knots the definition of a macro BOOL just so we can use it define some types, which seems a strange way to do things to me, but might well be there for a reason I don't know) --- windef.h.bak2012-09-03 16:54:05.15625 +0100 +++ windef.h2012-09-03 16:54:25.34375 +0100 @@ -101,15 +101,14 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +typedef WINBOOL *PBOOL; +typedef WINBOOL *LPBOOL; +#if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) !defined(NOBOOLTYPE) #pragma push_macro(BOOL) #undef BOOL -#if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) !defined(NOBOOLTYPE) typedef int BOOL; -#endif -#define BOOL WINBOOL -typedef BOOL *PBOOL; -typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif #endif /* _DEF_WINBOOL_ */ typedef unsigned char BYTE; --- windef.h.bak2012-09-03 16:54:05.15625 +0100 +++ windef.h2012-09-03 16:54:25.34375 +0100 @@ -101,15 +101,14 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +typedef WINBOOL *PBOOL; +typedef WINBOOL *LPBOOL; +#if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) !defined(NOBOOLTYPE) #pragma push_macro(BOOL) #undef BOOL -#if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) !defined(NOBOOLTYPE) typedef int BOOL; -#endif -#define BOOL WINBOOL -typedef BOOL *PBOOL; -typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif #endif /* _DEF_WINBOOL_ */ typedef unsigned char BYTE;
Re: [ITA] w32api-3.0b_svn5368-1
On 03/09/2012 16:59, Jon TURNEY wrote: So, how about the attached (minimal) change? (where NOBOOLTYPE is named whatever you think is appropriate) This time with correct patch attached... --- windef.h.bak2012-09-03 16:54:05.15625 +0100 +++ windef.h2012-09-03 17:03:49.359375000 +0100 @@ -103,7 +103,7 @@ typedef int WINBOOL; #pragma push_macro(BOOL) #undef BOOL -#if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) !defined(NOBOOLTYPE) +#if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) typedef int BOOL; #endif #define BOOL WINBOOL
Re: [ITA] w32api-3.0b_svn5368-1
On Thu, Aug 30, 2012 at 4:56 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I can roll an xproto update and this will be GTG. No problems with ddraw.h status? There's probably some decruftification which can take place later in the xserver, of stuff which presumably predates the existence of libdxguid.a in mingw.org's w32api Jon's xserver patch takes care of that. The only change needed in w32api is for _PROTECT_BOOL_MACRO in windef.h: http://cygwin.com/ml/cygwin-apps/2012-08/msg00074.html I'd rather not make windef.h any convoluted, and there's probably a more elegant way to solve this problem. Given that we are going to have to change x11proto's Xwindows.h anyhow, it might be possible to do it all there, but I haven't found the way yet... So hold on the patch to mingw-w64?
Re: [ITA] w32api-3.0b_svn5368-1
On Thu, 2012-08-23 at 19:45 +0100, Jon TURNEY wrote: Yaakov, you might like to try the attached patch. With an appropriate change to prevent BOOL redefinition errors, this builds X server for me. WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I can roll an xproto update and this will be GTG. Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 09:02, Kai Tietz wrote: 2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Fair enough. I just highlighted it in case it's unexpected. Btw have you checked size with debugging-information, or without? Without. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On 8/29/2012 14:14, Yaakov (Cygwin/X) wrote: On Thu, 2012-08-23 at 19:45 +0100, Jon TURNEY wrote: Yaakov, you might like to try the attached patch. With an appropriate change to prevent BOOL redefinition errors, this builds X server for me. WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I can roll an xproto update and this will be GTG. No problems with ddraw.h status? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Thu, 2012-08-30 at 06:11 +0800, JonY wrote: On 8/29/2012 14:14, Yaakov (Cygwin/X) wrote: On Thu, 2012-08-23 at 19:45 +0100, Jon TURNEY wrote: Yaakov, you might like to try the attached patch. With an appropriate change to prevent BOOL redefinition errors, this builds X server for me. WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I can roll an xproto update and this will be GTG. No problems with ddraw.h status? Jon's xserver patch takes care of that. The only change needed in w32api is for _PROTECT_BOOL_MACRO in windef.h: http://cygwin.com/ml/cygwin-apps/2012-08/msg00074.html Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On 8/24/2012 00:51, Jon TURNEY wrote: On 22/08/2012 10:08, JonY wrote: On 8/22/2012 06:26, JonY wrote: According to mingw.org basetyps.h, GUID_SECT was only necessary for ancient GCC versions. At a minimum, we should be able to just remove the GUID_SECT from those defines. Unfortunately just ifndef _W64 those defines entirely leads to link errors: hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4' winshaddd.o: In function `winAllocateFBShadowDD': hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2' winshadddnl.o: In function `winAllocateFBShadowDDNL': hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4' winpfbdd.o: In function `winAllocateFBPrimaryDD': hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2' It's pretty easy to adapt for this in the existing X server code either by simply defining GUID_SECT as empty if it is not already defined, or removing GUID_SECT. mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't like inlined data. DEFINE_GUID may need fixing, or at least instanced in libuuid or libddraw. I'll need to talk to to the Jacek from Wine to get a solution. Here's a quick and dirty workaround, add and compile the following file and link it with the failing executable: = #define INITGUID 1 #include ddraw.h = It's tempting to conclude that the brokeness alluded to in the comment in the X server source is that the author didn't know about INITGUID. It seems that GUID_SECT is defined by the current w32api headers, but only had any contents for ancient gcc (prior to 2.95) However, Google seems to indicate that we are not totally alone in assuming the existence of GUID_SECT, so you might want to consider providing an empty definition for compatibility. OK, found the proper lib to link with, add -ldxguid for libdxguid.a. I did not know of this until Jacek told me about it. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 22/08/2012 10:08, JonY wrote: On 8/22/2012 06:26, JonY wrote: According to mingw.org basetyps.h, GUID_SECT was only necessary for ancient GCC versions. At a minimum, we should be able to just remove the GUID_SECT from those defines. Unfortunately just ifndef _W64 those defines entirely leads to link errors: hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4' winshaddd.o: In function `winAllocateFBShadowDD': hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2' winshadddnl.o: In function `winAllocateFBShadowDDNL': hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4' winpfbdd.o: In function `winAllocateFBPrimaryDD': hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2' It's pretty easy to adapt for this in the existing X server code either by simply defining GUID_SECT as empty if it is not already defined, or removing GUID_SECT. mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't like inlined data. DEFINE_GUID may need fixing, or at least instanced in libuuid or libddraw. I'll need to talk to to the Jacek from Wine to get a solution. Here's a quick and dirty workaround, add and compile the following file and link it with the failing executable: = #define INITGUID 1 #include ddraw.h = It's tempting to conclude that the brokeness alluded to in the comment in the X server source is that the author didn't know about INITGUID. It seems that GUID_SECT is defined by the current w32api headers, but only had any contents for ancient gcc (prior to 2.95) However, Google seems to indicate that we are not totally alone in assuming the existence of GUID_SECT, so you might want to consider providing an empty definition for compatibility.
Re: [ITA] w32api-3.0b_svn5368-1
On 21/08/2012 23:26, JonY wrote:
On 8/22/2012 02:58, Yaakov (Cygwin/X) wrote:
Once we get past those, there are a few more:
This is what I get for only checking git master :S
In file included from winmultiwindowwm.c:74:0:
taskbar.h:34:16: error: redefinition of ‘struct _tagpropertykey’
/usr/include/w32api/wtypes.h:762:16: note: originally defined here
taskbar.h:37:3: error: conflicting types for ‘PROPERTYKEY’
/usr/include/w32api/wtypes.h:765:3: note: previous declaration of
‘PROPERTYKEY’ was here
taskbar.h:39:0: warning: REFPROPVARIANT redefined
/usr/include/w32api/propidl.h:266:0: note: this is the location of the
previous definition
In file included from winmultiwindowwm.c:74:0:
taskbar.h:67:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘const’
winmultiwindowwm.c: In function ‘winSetAppID’:
winmultiwindowwm.c:2064:44: error: ‘PKEY_AppUserModel_ID’ undeclared
(first use in this function)
This would appear to be fixable by using propkey.h in
hw/xwin/taskbar.h instead of defining this stuff ourselves, but that
header is _W64-specific.
The header details are actually scrapped from MSDN.
It's nice to have more up-to-date PSDK headers.
But, I'm guessing that the issue Yaakov is alluding to here is that
mingw.org's w32api doesn't have a propkey.h, so I would be reluctant to
upstream a patch which unconditionally included propkey.h.
Putatively, the X.org source is compilable using a MinGW toolchain to produce
a native X server, and this would break that for anyone still using the
mingw.org toolchain.
Fortunately, this seems fixable if we can check we are using mingw-w64 or
mingw.org headers . I'm told that checking for __MINGW64_VERSION_MAJOR is the
defined way to do this.
Yaakov, you might like to try the attached patch. With an appropriate change
to prevent BOOL redefinition errors, this builds X server for me.
From 8db8baf111ec25370e1123b300e629c0be6490dd Mon Sep 17 00:00:00 2001
From: Jon TURNEY jon.tur...@dronecode.org.uk
Date: Tue, 21 Aug 2012 15:31:16 +0100
Subject: [PATCH] Fix compilation with mingw-w64 w32api headers
- GUID_SECT was only ever needed for gcc pre-2.95
- Wrap 'Status' when including objbase.h
- Include propkey.h, propsys.h rather than defining necessary stuff ourselves
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/ddraw.h |4
hw/xwin/taskbar.h |9 +
hw/xwin/winshaddd.c |2 +-
hw/xwin/winshadddnl.c |2 +-
4 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/hw/xwin/ddraw.h b/hw/xwin/ddraw.h
index 9463049..fade730 100644
--- a/hw/xwin/ddraw.h
+++ b/hw/xwin/ddraw.h
@@ -3,7 +3,11 @@
#include winnt.h
#include wingdi.h
+#pragma push_macro(Status)
+#undef Status
+#define Status wStatus
#include objbase.h
+#pragma pop_macro(Status)
#if defined(NONAMELESSUNION) !defined(DUMMYUNIONNAME1)
#define DUMMYUNIONNAME1 u1
diff --git a/hw/xwin/taskbar.h b/hw/xwin/taskbar.h
index bfe301d..06c2f5d 100644
--- a/hw/xwin/taskbar.h
+++ b/hw/xwin/taskbar.h
@@ -31,6 +31,13 @@
#include windows.h
+#ifdef __MINGW64_VERSION_MAJOR
+/* If we are using headers from mingw-w64 project, it provides the PSDK
headers this needs ... */
+#include propkey.h
+#include propsys.h
+#else /* !__MINGW64_VERSION_MAJOR */
+/* ... otherwise, we need to define all this stuff ourselves */
+
typedef struct _tagpropertykey {
GUID fmtid;
DWORD pid;
@@ -66,6 +73,8 @@ DEFINE_GUID(IID_IPropertyStore,0x886d8eeb, 0x8cf2, 0x4446,
0x8d,0x02, 0xcd,0xba,
DEFINE_PROPERTYKEY(PKEY_AppUserModel_ID, 0x9F4C2855, 0x9F79, 0x4B39, 0xA8,
0xD0, 0xE1, 0xD4, 0x2D, 0xE1, 0xD5, 0xF3, 5);
+#endif /* !__MINGW64_VERSION_MAJOR */
+
typedef HRESULT (__stdcall
*SHGETPROPERTYSTOREFORWINDOWPROC)(HWND,REFIID,void**);
typedef HRESULT (__stdcall *PROPVARIANTCLEARPROC)(PROPVARIANT*);
diff --git a/hw/xwin/winshaddd.c b/hw/xwin/winshaddd.c
index a2aaa39..cab451a 100644
--- a/hw/xwin/winshaddd.c
+++ b/hw/xwin/winshaddd.c
@@ -42,7 +42,7 @@
*/
#ifdef DEFINE_GUID
#undef DEFINE_GUID
-#define DEFINE_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID n GUID_SECT
= {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
+#define DEFINE_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID n =
{l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
#endif /* DEFINE_GUID */
/*
diff --git a/hw/xwin/winshadddnl.c b/hw/xwin/winshadddnl.c
index f748c4d..b4720b2 100644
--- a/hw/xwin/winshadddnl.c
+++ b/hw/xwin/winshadddnl.c
@@ -42,7 +42,7 @@
*/
#ifdef DEFINE_GUID
#undef DEFINE_GUID
-#define DEFINE_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID n GUID_SECT
= {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
+#define DEFINE_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID n =
{l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
#endif /* DEFINE_GUID */
/*
--
1.7.9
Re: [ITA] w32api-3.0b_svn5368-1
On 8/22/2012 06:26, JonY wrote: According to mingw.org basetyps.h, GUID_SECT was only necessary for ancient GCC versions. At a minimum, we should be able to just remove the GUID_SECT from those defines. Unfortunately just ifndef _W64 those defines entirely leads to link errors: hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4' winshaddd.o: In function `winAllocateFBShadowDD': hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2' winshadddnl.o: In function `winAllocateFBShadowDDNL': hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4' winpfbdd.o: In function `winAllocateFBPrimaryDD': hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2' mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't like inlined data. DEFINE_GUID may need fixing, or at least instanced in libuuid or libddraw. I'll need to talk to to the Jacek from Wine to get a solution. Here's a quick and dirty workaround, add and compile the following file and link it with the failing executable: = #define INITGUID 1 #include ddraw.h = signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 21/08/2012 05:47, JonY wrote: On 8/21/2012 11:46, Christopher Faylor wrote: On Tue, Aug 21, 2012 at 11:31:23AM +0800, JonY wrote: On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. Maybe this is just a sanity check/proof of concept thing but do we really want to have specific ifdef's like this in shipping headers? That would suggest a neverending cascade of ifdefs. If we really need something like this then I'd suggest something more generic like a #ifdef __PROTECT_PROTECT_BOOL_MACRO. yeah, it is just a proof of concept, it is copied from the existing w32api package. If this works, I'll talk to Kai about untangling the ifdefs. I've never been really sure what historical accidents are behind the #ifdef XFree86Server in w32api. It doesn't do anything useful, since in the X server, windows header files are always included via a header which wraps them to avoid name collisions [1], which carefully arranges for XFree86Server to be undefined. [1] http://cgit.freedesktop.org/xorg/proto/xproto/tree/Xwindows.h
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 19:11, Jon TURNEY wrote: On 21/08/2012 05:47, JonY wrote: On 8/21/2012 11:46, Christopher Faylor wrote: On Tue, Aug 21, 2012 at 11:31:23AM +0800, JonY wrote: On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. Maybe this is just a sanity check/proof of concept thing but do we really want to have specific ifdef's like this in shipping headers? That would suggest a neverending cascade of ifdefs. If we really need something like this then I'd suggest something more generic like a #ifdef __PROTECT_PROTECT_BOOL_MACRO. yeah, it is just a proof of concept, it is copied from the existing w32api package. If this works, I'll talk to Kai about untangling the ifdefs. I've never been really sure what historical accidents are behind the #ifdef XFree86Server in w32api. It doesn't do anything useful, since in the X server, windows header files are always included via a header which wraps them to avoid name collisions [1], which carefully arranges for XFree86Server to be undefined. [1] http://cgit.freedesktop.org/xorg/proto/xproto/tree/Xwindows.h Here's the part from mingw-w64 windef.h: #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) typedef int BOOL; #endif #define BOOL WINBOOL typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) #endif /* _DEF_WINBOOL_ */ Note the pragma push and undef, the Xwindows.h macro tricks no longer works. Perhaps guarding against _XFree86Server instead of XFree86Server will work? signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Tue, Aug 21, 2012 at 7:34 AM, JonY jo...@users.sourceforge.net wrote: Here's the part from mingw-w64 windef.h: #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) typedef int BOOL; #endif #define BOOL WINBOOL typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) #endif /* _DEF_WINBOOL_ */ Note the pragma push and undef, the Xwindows.h macro tricks no longer works. Perhaps guarding against _XFree86Server instead of XFree86Server will work? Or just fix Xwindows
Re: [ITA] w32api-3.0b_svn5368-1
On 21/08/2012 13:10, NightStrike wrote:
On Tue, Aug 21, 2012 at 7:34 AM, JonY
jon_y-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org wrote:
Note the pragma push and undef, the Xwindows.h macro tricks no longer
works. Perhaps guarding against _XFree86Server instead of XFree86Server
will work?
Or just fix Xwindows
I am afraid it is a little too late to remove the conflicting definition of
BOOL from X11/X.h
I was able to get X server to compile with the following alteration to
winddef.h, and turning on _PROTECT_BOOL_MACRO in X11/Xwindows.h
#ifndef _DEF_WINBOOL_
#define _DEF_WINBOOL_
typedef int WINBOOL;
#ifndef _PROTECT_BOOL_MACRO
#pragma push_macro(BOOL)
#undef BOOL
#endif /* _PROTECT_BOOL_MACRO */
#if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU)
typedef int BOOL;
#endif
#define BOOL WINBOOL
typedef BOOL *PBOOL;
typedef BOOL *LPBOOL;
#ifndef _PROTECT_BOOL_MACRO
#pragma pop_macro(BOOL)
#endif /* _PROTECT_BOOL_MACRO */
#endif /* _DEF_WINBOOL_ */
I would be very interested in suggestions as to how to fix this without
messing with windef.h
There are a also couple of other issues which prevent X server from compiling
successfully with these headers, which should probably be fixed in the X server:
DEFINE_GUID is defined in terms of GUID_SECT, which no longer exists. I'm not
sure what the broken-ness referred to here is, or if it still exists...
/*
* FIXME: Headers are broken, DEFINE_GUID doesn't work correctly,
* so we have to redefine it here.
*/
#ifdef DEFINE_GUID
#undef DEFINE_GUID
#define DEFINE_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID n GUID_SECT
= {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
#endif /* DEFINE_GUID */
'Status' is used as formal parameter name in some w32api headers, but as a
typename in xkbsrv.h. We wrap this in Xwindows.h to avoid conflict, but
objbase.h is included outside of that wrapper when we are defining directdraw
interface GUIDs, leading to a conflict in rpcdce.h
Re: [ITA] w32api-3.0b_svn5368-1
On 8/22/2012 02:58, Yaakov (Cygwin/X) wrote:
On 2012-08-21 09:13, Jon TURNEY wrote:
There are a also couple of other issues which prevent X server from
compiling
successfully with these headers, which should probably be fixed in the
X server:
DEFINE_GUID is defined in terms of GUID_SECT, which no longer exists.
I'm not
sure what the broken-ness referred to here is, or if it still exists...
/*
* FIXME: Headers are broken, DEFINE_GUID doesn't work correctly,
* so we have to redefine it here.
*/
#ifdef DEFINE_GUID
#undef DEFINE_GUID
#define DEFINE_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID n
GUID_SECT
= {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
#endif /* DEFINE_GUID */
According to mingw.org basetyps.h, GUID_SECT was only necessary for
ancient GCC versions. At a minimum, we should be able to just remove
the GUID_SECT from those defines. Unfortunately just ifndef _W64 those
defines entirely leads to link errors:
hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4'
winshaddd.o: In function `winAllocateFBShadowDD':
hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2'
winshadddnl.o: In function `winAllocateFBShadowDDNL':
hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4'
winpfbdd.o: In function `winAllocateFBPrimaryDD':
hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2'
mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't
like inlined data. DEFINE_GUID may need fixing, or at least instanced in
libuuid or libddraw.
I'll need to talk to to the Jacek from Wine to get a solution.
'Status' is used as formal parameter name in some w32api headers, but
as a
typename in xkbsrv.h. We wrap this in Xwindows.h to avoid conflict,
(The difference being that mingw.org's rpc*.h don't use parameter
names, only types.)
These may also need cooperation from Jacek.
but objbase.h is included outside of that wrapper when we are defining
directdraw
interface GUIDs, leading to a conflict in rpcdce.h
Once we get past those, there are a few more:
In file included from winmultiwindowwm.c:74:0:
taskbar.h:34:16: error: redefinition of ‘struct _tagpropertykey’
/usr/include/w32api/wtypes.h:762:16: note: originally defined here
taskbar.h:37:3: error: conflicting types for ‘PROPERTYKEY’
/usr/include/w32api/wtypes.h:765:3: note: previous declaration of
‘PROPERTYKEY’ was here
taskbar.h:39:0: warning: REFPROPVARIANT redefined
/usr/include/w32api/propidl.h:266:0: note: this is the location of the
previous definition
In file included from winmultiwindowwm.c:74:0:
taskbar.h:67:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘const’
winmultiwindowwm.c: In function ‘winSetAppID’:
winmultiwindowwm.c:2064:44: error: ‘PKEY_AppUserModel_ID’ undeclared
(first use in this function)
This would appear to be fixable by using propkey.h in
hw/xwin/taskbar.h instead of defining this stuff ourselves, but that
header is _W64-specific.
The header details are actually scrapped from MSDN.
signature.asc
Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1 [GOLDSTAR request for Chris Sutcliffe inside]
Hi Jon, many thanks for taking over this package. And again, this time publically, I would like to thank Chris Sutcliffe for maintaining the w32api package for the last 9 years. Can we get a GOLD STAR for Chris, please? Gold stars for Jon and Chris: http://cygwin.com/goldstars/#JY http://cygwin.com/goldstars/#CS
Re: [ITA] w32api-3.0b_svn5368-1
On 8/14/2012 16:02, Kai Tietz wrote: 2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Btw have you checked size with debugging-information, or without? Regards, Kai New version up. Was the first uploaded? http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was here In file included from /usr/include/w32api/windows.h:74:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/wincon.h:324:3: error: expected specifier-qualifier-list before 'wBOOL' In file included from /usr/include/w32api/rpc.h:70:0, from /usr/include/w32api/objbase.h:6, from ../../../hw/xwin/ddraw.h:6, from ../../../hw/xwin/winms.h:45, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/rpcdce.h:142:88: error: expected ';', ',' or ')' before 'int' In file included from /usr/include/w32api/rpc.h:70:0, from /usr/include/w32api/objbase.h:6, from ../../../hw/xwin/ddraw.h:6, from ../../../hw/xwin/winms.h:45, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/rpcdce.h:210:69: error: expected ')' before '*' token In file included from /usr/include/w32api/rpc.h:70:0, from /usr/include/w32api/objbase.h:6, from ../../../hw/xwin/ddraw.h:6, from ../../../hw/xwin/winms.h:45, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/rpcdce.h:471:145: error: expected ';', ',' or ')' before 'int' /usr/include/w32api/rpcdce.h:473:112: error: expected declaration specifiers or '...' before 'RPC_AUTH_KEY_RETRIEVAL_FN' /usr/include/w32api/rpcdce.h:474:112: error: expected declaration specifiers or '...' before 'RPC_AUTH_KEY_RETRIEVAL_FN' /usr/include/w32api/rpcdce.h:513:81: error: expected ';', ',' or ')' before 'int' /usr/include/w32api/rpcdce.h:515:72: error: expected ';', ',' or ')' before 'int' /usr/include/w32api/rpcdce.h:516:69: error: expected ';', ',' or ')' before 'int' /usr/include/w32api/rpcdce.h:517:59: error: expected ';', ',' or ')' before 'int' /usr/include/w32api/rpcdce.h:547:140: error: expected ';', ',' or ')' before 'int' /usr/include/w32api/rpcdce.h:555:85: error: expected ')' before 'AuthorizationFn' In file included from /usr/include/w32api/rpcdce.h:623:0, from /usr/include/w32api/rpc.h:70, from /usr/include/w32api/objbase.h:6, from ../../../hw/xwin/ddraw.h:6, from ../../../hw/xwin/winms.h:45, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/rpcdcep.h:220:62: error: two or more data types in declaration specifiers In file included from /usr/include/w32api/rpc.h:87:0, from /usr/include/w32api/objbase.h:6, from ../../../hw/xwin/ddraw.h:6, from ../../../hw/xwin/winms.h:45, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/rpcasync.h:118:11: error: two or more data types in declaration specifiers In file included from /usr/include/w32api/rpcndr.h:21:0, from /usr/include/w32api/objbase.h:7, from ../../../hw/xwin/ddraw.h:6, from ../../../hw/xwin/winms.h:45, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/rpcnsip.h:21:81: error: two or more data types in declaration specifiers In file included from /usr/include/w32api/objbase.h:7:0, from ../../../hw/xwin/ddraw.h:6, from ../../../hw/xwin/winms.h:45, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/rpcndr.h:673:160: error: two or more data types in declaration specifiers Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. My bad, I did not notice the build stage error, cygport proceeded to install and package. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was iirc the BOOL workaround was removed, I'm not sure if I remember it correctly. If so, it could be reintroduced. Sorry, dropped cygwin-apps by accident from the recipient list. Anyway, new build up, same URL for the 3 files. These are the same revisions, so the BOOL problem is still there, if anybody wants to try their hands on it for anything other Xorg, please do. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. My bad, I did not notice the build stage error, cygport proceeded to install and package. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Tue, Aug 21, 2012 at 11:31:23AM +0800, JonY wrote: On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. My bad, I did not notice the build stage error, cygport proceeded to install and package. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. Maybe this is just a sanity check/proof of concept thing but do we really want to have specific ifdef's like this in shipping headers? That would suggest a neverending cascade of ifdefs. If we really need something like this then I'd suggest something more generic like a #ifdef __PROTECT_PROTECT_BOOL_MACRO. cgf
Re: [ITA] w32api-3.0b_svn5368-1
On 8/21/2012 11:46, Christopher Faylor wrote: On Tue, Aug 21, 2012 at 11:31:23AM +0800, JonY wrote: On 8/21/2012 10:23, JonY wrote: On 8/21/2012 09:15, JonY wrote: On 8/21/2012 07:22, Yaakov (Cygwin/X) wrote: On 2012-08-20 07:15, JonY wrote: New version up. Was the first uploaded? No, nor can it until packages which depend on w32api build correctly. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1-src.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5373-1.tar.bz2/download http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint/download The binary package contains only the headers; the libs are missing. My bad, I did not notice the build stage error, cygport proceeded to install and package. So I built this from SVN trunk myself, and xorg-server still FTBFS: In file included from /usr/include/w32api/windows.h:69:0, from /usr/include/X11/Xwindows.h:60, from ../../../hw/xwin/winms.h:42, from ../../../hw/xwin/win.h:193, from winpriv.c:10: /usr/include/w32api/windef.h:107:13: error: conflicting types for 'BOOL' /usr/include/X11/Xmd.h:143:16: note: previous declaration of 'BOOL' was Yaakov, try this change: Index: include/windef.h === --- include/windef.h(revision 5374) +++ include/windef.h(working copy) @@ -101,6 +101,7 @@ #ifndef _DEF_WINBOOL_ #define _DEF_WINBOOL_ typedef int WINBOOL; +#ifndef XFree86Server /* For xorg-server */ #pragma push_macro(BOOL) #undef BOOL #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) @@ -110,6 +111,7 @@ typedef BOOL *PBOOL; typedef BOOL *LPBOOL; #pragma pop_macro(BOOL) +#endif /* XFree86Server */ #endif /* _DEF_WINBOOL_ */ I'm not sure if things will explode horribly. Maybe this is just a sanity check/proof of concept thing but do we really want to have specific ifdef's like this in shipping headers? That would suggest a neverending cascade of ifdefs. If we really need something like this then I'd suggest something more generic like a #ifdef __PROTECT_PROTECT_BOOL_MACRO. yeah, it is just a proof of concept, it is copied from the existing w32api package. If this works, I'll talk to Kai about untangling the ifdefs. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 13 21:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. Er... what? It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Why? What is the purpose of 64-bit libs with a 32-bit-only Cygwin GCC? It doesn't hurt to have the 64 bit libs already available, does it? It allows to install a cross gcc for x86_64-pc-cygwin at one point and the w32api headers are already available? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:18, Corinna Vinschen wrote: On Aug 13 21:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. Er... what? I had to look it up: Fails To Build From Source. /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’ windef.h:23: typedef unsigned __LONG32 ULONG; It doesn't like the __LONG32. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Corinna
Fixed at rev. 5371. The include should come before the 'extern C {' clause.
Thanks for reporting. It might be that there are some of those issues
remaining caused by the LP64 support-changes.
Regards,
Kai
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:34, Corinna Vinschen wrote:
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
I haven't included windows.h, but just the headers that are actually
needed. (Yeah, I know MSDN doesn't like that, but then why do they
bother documenting which header each function is in.)
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Yep, mintty builds fine with that, and appears to work. For some
reason it's 9K bigger than with the current w32api though.
Andy
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 14 08:46, Andy Koppe wrote:
On 14 August 2012 08:34, Corinna Vinschen wrote:
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
I haven't included windows.h, but just the headers that are actually
needed. (Yeah, I know MSDN doesn't like that, but then why do they
bother documenting which header each function is in.)
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Yep, mintty builds fine with that, and appears to work. For some
reason it's 9K bigger than with the current w32api though.
I think this is because the mingw-w64 libs come with a couple more
static elements built into the libs (GUIDs and stuff).
Kai, can you explain the difference?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Btw have you checked size with debugging-information, or without? Regards, Kai
Re: [ITA] w32api-3.0b_svn5368-1
On 8/14/2012 10:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Why? What is the purpose of 64-bit libs with a 32-bit-only Cygwin GCC? Like Corinna says, 64bit Cygwin has to start somewhere. Yaakov: Can cygport implement a new inherit where it is similar to cross, except it uses --prefix=/usr? Right now, I'm setting CC/CXX manually to get around it. To bootstrap, you could just unset CC/CXX and configure with --host=x86_64-w64-mingw32. But once the new w32api is installed, if you configure with --disable-lib64, this should be buildable with Cygwin's native GCC. I did not think of that, thanks. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1 [GOLDSTAR request for Chris Sutcliffe inside]
Hi Jon, many thanks for taking over this package. And again, this time publically, I would like to thank Chris Sutcliffe for maintaining the w32api package for the last 9 years. Can we get a GOLD STAR for Chris, please? On Aug 12 14:49, JonY wrote: Hi, New w32api preliminary upload, now with mingw-w64 parts. It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Preliminary? Do you want this to be uploaded as is, or do you want to provide it as test package only for now? Or not at all? Special thanks to Corinna for making this possible. Comments? Yaakov: Can cygport implement a new inherit where it is similar to cross, except it uses --prefix=/usr? Right now, I'm setting CC/CXX manually to get around it. setup.hint same as before: sdesc: Win32 API header and library import files category: Libs Links: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5368-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5368-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint The package looks good to me, and I built Cygwin successfully using these headers and libs. Does anybody using Windows headers would like to give this new set of w32api headers a try? Mintty or the X server seem to be pretty good acid tests... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1 [GOLDSTAR request for Chris Sutcliffe inside]
On Mon, Aug 13, 2012 at 04:06:24PM +0200, Corinna Vinschen wrote: many thanks for taking over this package. And again, this time publically, I would like to thank Chris Sutcliffe for maintaining the w32api package for the last 9 years. Can we get a GOLD STAR for Chris, please? Hear, hear! cgf
[ITA] w32api-3.0b_svn5368-1
Hi, New w32api preliminary upload, now with mingw-w64 parts. It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Special thanks to Corinna for making this possible. Comments? Yaakov: Can cygport implement a new inherit where it is similar to cross, except it uses --prefix=/usr? Right now, I'm setting CC/CXX manually to get around it. setup.hint same as before: sdesc: Win32 API header and library import files category: Libs Links: http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5368-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/w32api-3.0b_svn5368-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/w32api/setup.hint signature.asc Description: OpenPGP digital signature
