[ITA] w32api-3.0b_svn5368-1

[ITA] w32api-3.0b_svn5368-1

[JonY]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1 [GOLDSTAR request for Chris Sutcliffe inside]

[Corinna Vinschen]

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]

[Christopher Faylor]

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

Re: [ITA] w32api-3.0b_svn5368-1 [GOLDSTAR request for Chris Sutcliffe inside]

[Andrew Schulman]

> 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

[Yaakov (Cygwin/X)]

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?

> 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.


Yaakov

Re: [ITA] w32api-3.0b_svn5368-1

[Corinna Vinschen]

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

[Andy Koppe]

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

[Corinna Vinschen]

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?


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

[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

-- 
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

[Kai Tietz]

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

[Andy Koppe]

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

[Corinna Vinschen]

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

[Kai Tietz]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Yaakov (Cygwin/X)]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Christopher Faylor]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

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.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Jon TURNEY]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 3138 bytes --]

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?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[NightStrike]

On Tue, Aug 21, 2012 at 7:34 AM, JonY <jon_y@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

[Jon TURNEY]

On 21/08/2012 13:10, NightStrike wrote:
> On Tue, Aug 21, 2012 at 7:34 AM, JonY <jon_y-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@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

[Yaakov (Cygwin/X)]

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'

> '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.)

> 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.


Yaakov

Re: [ITA] w32api-3.0b_svn5368-1

[JonY]

[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

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>
=====================


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Jon TURNEY]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Jon TURNEY]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

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.


[-- Attachment #2: 0001-Fix-compilation-with-mingw-w64-w32api-headers.patch --]
[-- Type: text/plain, Size: 2928 bytes --]

From 8db8baf111ec25370e1123b300e629c0be6490dd Mon Sep 17 00:00:00 2001
From: Jon TURNEY <jon.turney@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.turney@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

[Yaakov (Cygwin/X)]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

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?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Yaakov (Cygwin/X)]

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

[Jon TURNEY]

On 30/08/12 00:16, Yaakov (Cygwin/X) wrote:
> 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?

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...

Re: [ITA] w32api-3.0b_svn5368-1

[NightStrike]

On Thu, Aug 30, 2012 at 4:56 AM, Jon TURNEY <jon.turney@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

[Corinna Vinschen]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Jon TURNEY]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

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)


[-- Attachment #2: windef.h.patch --]
[-- Type: text/plain, Size: 682 bytes --]

--- windef.h.bak	2012-09-03 16:54:05.156250000 +0100
+++ windef.h	2012-09-03 16:54:25.343750000 +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;

[-- Attachment #3: more_windef.h.patch --]
[-- Type: text/plain, Size: 682 bytes --]

--- windef.h.bak	2012-09-03 16:54:05.156250000 +0100
+++ windef.h	2012-09-03 16:54:25.343750000 +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

[Jon TURNEY]

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

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...


[-- Attachment #2: windef.h.patch --]
[-- Type: text/plain, Size: 420 bytes --]

--- windef.h.bak	2012-09-03 16:54:05.156250000 +0100
+++ windef.h	2012-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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[JonY]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Yaakov (Cygwin/X)]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

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?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Corinna Vinschen]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Corinna Vinschen]

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

[Yaakov (Cygwin/X)]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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 -0000	1.18
+++ include/cygwin/in.h	10 Oct 2012 08:36:33 -0000	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

[Yaakov (Cygwin/X)]

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

[Corinna Vinschen]

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

[Yaakov (Cygwin/X)]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITA] w32api-3.0b_svn5368-1

[Yaakov (Cygwin/X)]

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]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

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




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[Corinna Vinschen]

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]

[Christopher Faylor]

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]

[Corinna Vinschen]

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]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

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?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[Christopher Faylor]

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]

[Christopher Faylor]

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: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[Corinna Vinschen]

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]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

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 :)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[Corinna Vinschen]

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]

[Yaakov (Cygwin/X)]

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]

[Corinna Vinschen]

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]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[Yaakov (Cygwin/X)]

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]

[Corinna Vinschen]

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]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

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 :)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[Corinna Vinschen]

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]

[Christopher Faylor]

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]

[Corinna Vinschen]

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]

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: gold stars Re: [ITP] w32api r5431 [Was: Re: [ITA] w32api-3.0b_svn5368-1]

[Andrew Schulman]

> > 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.

Awarded.  Don't worry, we still have plenty.

http://cygwin.com/goldstars/#JY

Re: [ITA] w32api-3.0b_svn5368-1

[Andy Koppe]

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

[JonY]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]