Re: [Mingw-w64-public] Detecting libexpat library failed with undefined reference to _time32

2013-10-03 Thread asmwarrior
On 2013-10-3 12:27, LRN wrote: Always use --build=i686-w64-mingw32 or --build=x86_64-w64-mingw32 when using mingw-w64 toolchains (obviously, for cross-toolchains you would use --host=i686-w64-mingw32 and --host=x86_64-w64-mingw32). - --build=mingw32 only works for mingw.org toolchains.

Re: [Mingw-w64-public] Win 8 API support

2013-10-03 Thread Vaibhav Sood
Yes, that's correct. GetPointerFrameTouchInfo is one of the new Windows 8 API's that I could not find in the mingw-64 headers (it should ideally be in winuser.h). Also, would it be possible for me to know which of the new Windows 8 APIs have been added to mingw (if you could point me to some

Re: [Mingw-w64-public] Win 8 API support

2013-10-03 Thread Kai Tietz
Hello Vaibhav, well, some there are already. Nevertheless a lot of new windows 8 stuff is still missing. I concentrated on winbase/winnt, and some ole2 stuff. A lot of idl-files were updated for this. Parts of the shlobj-API were updated too. Additionally we added some parts required for VLC

Re: [Mingw-w64-public] Detecting libexpat library failed with undefined reference to _time32

2013-10-03 Thread LRN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.10.2013 11:06, asmwarrior wrote: On 2013-10-3 12:27, LRN wrote: Always use --build=i686-w64-mingw32 or --build=x86_64-w64-mingw32 when using mingw-w64 toolchains (obviously, for cross-toolchains you would use --host=i686-w64-mingw32 and

[Mingw-w64-public] New Windows 8 touch API support

2013-10-03 Thread Vaibhav Sood
Hi, I am trying to compile code which has the new Windows 8 touch messages like WM_POINTERDOWN etc. as well as APIs like GetPointerFrameTouchInfo (supported only on Windows 8 and above clients). However I could not find these signatures in the latest mingw-64 builds. I want to confirm whether

[Mingw-w64-public] compile C curses program under mingw-w64

2013-10-03 Thread Daniel Goldman
Background - There is a C language curses program I gcc compile under Linux, using ncurses. It works great. I also compile the curses program under DOS, using pdcurses included with mingw. The DOS version works fine in production mode. But there are some problems: 1) in test mode some printf

Re: [Mingw-w64-public] compile C curses program under mingw-w64

2013-10-03 Thread LRN
On 30.09.2013 05:22, Daniel Goldman wrote: Background - There is a C language curses program I gcc compile under Linux, using ncurses. It works great. I also compile the curses program under DOS, using pdcurses included with mingw. The DOS version works fine in production mode. But there

Re: [Mingw-w64-public] [doc] Which compiler should I use FAQ entry

2013-10-03 Thread JonY
On 10/3/2013 06:27, Jon wrote: FAQ entry added under Execution section https://sourceforge.net/apps/trac/mingw-w64/wiki/FAQ Answer added as https://sourceforge.net/apps/trac/mingw-w64/wiki/Usable%20compiler%20executable Correct, modify, or make clearer as you see fit. If you don't

Re: [Mingw-w64-public] MSYS2

2013-10-03 Thread Vasileios Anagnostopoulos
builds dependencies (but not the qt recipe due to lack of PSDK on my machine) in order to build useful software mainly for fun and research. On Thu, Oct 3, 2013 at 1:46 PM, Alexey Pavlov alex...@gmail.com wrote: New MSYS2 snapshots: 32-bit: x32-msys2-20131003.tar.xzhttp://sourceforge.net

Re: [Mingw-w64-public] [doc] Which compiler should I use FAQ entry

2013-10-03 Thread Jon
On Thu, Oct 3, 2013 at 5:27 AM, JonY jo...@users.sourceforge.net wrote: On 10/3/2013 06:27, Jon wrote: FAQ entry added under Execution section https://sourceforge.net/apps/trac/mingw-w64/wiki/FAQ Answer added as

Re: [Mingw-w64-public] where to create winsup/mingw

2013-10-03 Thread Frédéric Bron
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.1/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.1/ So I have tried to mix objects compiled with my own w64

[Mingw-w64-public] download link may need to be updated

2013-10-03 Thread Roger Pack
As a note, this page: http://sourceforge.net/projects/mingw-w64/files/ still says looking for the latest version? download 2.0.8 which maybe isn't expected? Cheers, and thank you for a great project, makes my cross compilers rock :) -roger-

Re: [Mingw-w64-public] download link may need to be updated

2013-10-03 Thread JonY
On 10/4/2013 02:32, Roger Pack wrote: As a note, this page: http://sourceforge.net/projects/mingw-w64/files/ still says looking for the latest version? download 2.0.8 which maybe isn't expected? Cheers, and thank you for a great project, makes my cross compilers rock :) -roger- There is

Re: [Mingw-w64-public] where to create winsup/mingw

2013-10-03 Thread JonY
On 10/3/2013 23:06, Frédéric Bron wrote: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.1/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.1/ So I have tried

[Mingw-w64-public] stralign.h again

2013-10-03 Thread G M
Hello Everyone I'm trying to track a few tricky problems with stralign.h I was looking at this previously but had to drop it but I'm now looking at it again. Consider this program (distilled from stralign.h): #define TRUE 1 #define WSTR_ALIGNED(s) TRUE inline int strwhatever(const char*

Re: [Mingw-w64-public] download link may need to be updated

2013-10-03 Thread Yaakov (Cygwin/X)
On 2013-10-03 16:08, JonY wrote: On 10/4/2013 02:32, Roger Pack wrote: As a note, this page: http://sourceforge.net/projects/mingw-w64/files/ still says looking for the latest version? download 2.0.8 which maybe isn't expected? Cheers, and thank you for a great project, makes my cross

[Mingw-w64-public] _lrotr - take 2

2013-10-03 Thread dw
Sorry for the delayed response on this topic, things got busy. To pick this back up, this is where we stand now: - There's a bug in gcc's x86intrin.h. They assume that under x64, longs are always 8 bytes. For native Windows (ie not cygwin), that's not correct, and leads to incorrect results