When I #include fstream with mingw64-g++ the PRId64 value is no longer
interpreted correctly.
Here is the test program:
#define __STDC_FORMAT_MACROS
#include inttypes.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include stdint.h
#include fstream
int main(int argc,char **argv)
{
Hi!
I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an
application using TAPI, however tapi.h cannot be
compiled:
c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2074:107:
error: declaration of C function 'LONG
2012/7/10 Corinna Vinschen vinsc...@redhat.com:
Hi,
The checkin for revision 5161 from 2012-07-04 breaks installing only
the required crt header files for a PSDK-only installation. excpt.h
now includes crtdefs.h instead of windows.h. The below patch fixes
BASEHEAD_LIST in configure.ac
On 7/11/12, Peter Schaefer peter.schae...@gmx.de wrote:
Hi!
I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an
application using TAPI, however tapi.h cannot be
compiled:
2012/7/11 JonY jo...@users.sourceforge.net:
On 7/11/2012 14:51, Peter Schaefer wrote:
Hi!
I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an
application using TAPI, however tapi.h cannot be
compiled:
On 07/11/12 11:14, JonY wrote:
On 7/11/2012 14:51, Peter Schaefer wrote:
Hi!
I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an
application using TAPI, however tapi.h cannot be
compiled:
On 7/11/12, Kai Tietz ktiet...@googlemail.com wrote:
2012/7/11 JonY jo...@users.sourceforge.net:
On 7/11/2012 14:51, Peter Schaefer wrote:
Hi!
I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an
application using TAPI, however tapi.h cannot be
compiled:
On 7/11/2012 17:39, Ozkan Sezer wrote:
Ok looked at the header and reproduced the error. The specific
problem with tapi.h and the unicode macros is that some functions
have their xxxA/xxxW variants _along_ with the ones without them:
e.g. we have lineUnpark() _and_ lineUnparkA() and
On 7/11/12, JonY jo...@users.sourceforge.net wrote:
On 7/11/2012 17:39, Ozkan Sezer wrote:
Ok looked at the header and reproduced the error. The specific
problem with tapi.h and the unicode macros is that some functions
have their xxxA/xxxW variants _along_ with the ones without them:
e.g.
Hi Ozkan,
patches are looking ok to me. Please go ahead.
Thanks,
Kai
2012/7/11 Ozkan Sezer seze...@gmail.com:
On 7/11/12, JonY jo...@users.sourceforge.net wrote:
On 7/11/2012 17:39, Ozkan Sezer wrote:
Ok looked at the header and reproduced the error. The specific
problem with tapi.h and
On 7/11/12, Kai Tietz ktiet...@googlemail.com wrote:
Hi Ozkan,
patches are looking ok to me. Please go ahead.
Thanks,
Kai
trunk: r5212, stable/v1.x: r5213, stable/v2.x: r5214.
--
O.S.
2012/7/11 Ozkan Sezer seze...@gmail.com:
On 7/11/12, JonY jo...@users.sourceforge.net wrote:
On
Hi,
the below patch extends winternl.h slightly. OK to apply?
Thanks,
Corinna
* winternl.h (NT_SUCCESS): Define.
(enum _PROCESSINFOCLASS): Add ProcessDebugFlags.
(NtSetInformationProcess): Declare.
Index: winternl.h
Hello Corinna,
2012/7/11 Corinna Vinschen vinsc...@redhat.com:
Hi,
the below patch extends winternl.h slightly. OK to apply?
Thanks,
Corinna
patch is ok, could you order enum-values so that they are ascending?
Thanks,
Kai
On Jul 11 17:28, Kai Tietz wrote:
Hello Corinna,
2012/7/11 Corinna Vinschen vinsc...@redhat.com:
Hi,
the below patch extends winternl.h slightly. OK to apply?
Thanks,
Corinna
patch is ok, could you order enum-values so that they are ascending?
They are ascending already. Or
14 matches
Mail list logo
