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
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
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.
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.
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,
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
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
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?
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
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.
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
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
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,
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:
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
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?
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
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
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?
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
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
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
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
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
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
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?
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
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:
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.
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
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
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
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,
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
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
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
On 9/4/2012 00:05, Jon TURNEY wrote:
On 03/09/2012 16:59, Jon TURNEY wrote:
So, how about the attached (minimal) change? (where NOBOOLTYPE is named
whatever you think is appropriate)
This time with correct patch attached...
Done in trunk, used _NOBOOLTYPEDEF.
signature.asc
Description:
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
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
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
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
On 03/09/2012 16:59, Jon TURNEY wrote:
So, how about the attached (minimal) change? (where NOBOOLTYPE is named
whatever you think is appropriate)
This time with correct patch attached...
--- windef.h.bak2012-09-03 16:54:05.15625 +0100
+++ windef.h2012-09-03 17:03:49.359375000
On Thu, Aug 30, 2012 at 4:56 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I
can roll an xproto update and this will be GTG.
No problems with ddraw.h status?
There's probably some decruftification which can take place
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
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
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
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
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
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
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’
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:
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
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
On Tue, Aug 21, 2012 at 7:34 AM, JonY jo...@users.sourceforge.net wrote:
Here's the part from mingw-w64 windef.h:
#ifndef _DEF_WINBOOL_
#define _DEF_WINBOOL_
typedef int WINBOOL;
#pragma push_macro(BOOL)
#undef BOOL
#if !defined(__OBJC__) !defined(__OBJC_BOOL)
On 21/08/2012 13:10, NightStrike wrote:
On Tue, Aug 21, 2012 at 7:34 AM, JonY
jon_y-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org wrote:
Note the pragma push and undef, the Xwindows.h macro tricks no longer
works. Perhaps guarding against _XFree86Server instead of XFree86Server
will
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,
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
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
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
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.
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
74 matches
Mail list logo
