[Mingw-w64-public] TDM-GCC 4.5.1 released

[John E. / TDM]

Greetings!

*TDM-GCC 4.5.1 is now available!*

* With the 4.5.1 release, GCC now includes support for LTO on MinGW and
MinGW-w64 targets, so it's enabled in TDM-GCC.
* As with the 4.5.0 release, I've maintained the *reversal* of the GCC
change that caused an out-of-memory problem building wxWidgets due to
the forced emission of class inline functions in DLL code. This means
that you shouldn't have to perform any unusual steps when building
wxWidgets.

***WARNING!***
In the TDM64 edition, a widespread change has been introduced that
affects compatibility with previous versions. In summary, for the
x86_64-w64-mingw32 target, symbol names _*WILL NOT*_, by default, have
an additional underscore affixed, as was previously the case for this
target (and remains the case for 32-bit targets). This was done for
better compatibility with Microsoft's compiler.
*This means that you must recompile all code that was compiled with an
older TDM64 edition!*
If you fail to recompile any part of a self-contained module, or
inadvertently mix code compiled by an older edition with code compiled
by a newer edition, you _will_ encounter undefined symbol errors.
Consider yourself warned.

(If you truly must, you can revert to the previous underscoring rule
with the "-fleading-underscore" command-line option -- but don't do this
unless you really know what you're doing.)

*TDM-GCC is available in TWO editions:*
Along with the classic MinGW 32-bit edition, a new *TDM64* edition is
also available. This edition is based on the MinGW-w64 runtime API and
the x86_64-w64-mingw32 GCC target, and can create both 32-bit and 64-bit
code, with the "-m32"/"-m64" compiler flags. Please never mix 32-bit
object files (.o), libraries (.a), DLLs or EXEs with 64-bit versions,
and don't report it as a bug if you inadvertently do.

Alongside the GCC 4.5.1 packages are binary packages of the MinGW-w64
runtime (based on SVN r3427), binutils (CVS as of 2010-08-16), and gdb
(7.1).

More information and downloads are available at
<http://tdm-gcc.tdragon.net/>. TDM-GCC includes support for C, C++,
Fortran, Objective-C/C++, and Ada (MinGW edition only), as well as
support for LTO and the OpenMP multithreading extensions, packaged in a
simple Windows installer.

Cheers,
John E. / TDM

[NightStrike]

 Greetings!
*TDM-GCC 4.5.1 is now available!*
* With the 4.5.1 release, GCC now includes support for LTO on MinGW and
MinGW-w64 targets, so it's enabled in TDM-GCC.
* As with the 4.5.0 release, I've maintained the *reversal* of the GCC
change that caused an out-of-memory problem building wxWidgets due to
the forced emission of class inline functions in DLL code. This means
that you shouldn't have to perform any unusual steps when building
wxWidgets.

Is there a GCC PR for that?

[Luis Lavena]

Post by NightStrike
Is there a GCC PR for that?

http://gcc.gnu.org/ml/gcc/2010-07/msg00440.html

[NightStrike]

Post by Luis Lavena

Post by NightStrike
Is there a GCC PR for that?

http://gcc.gnu.org/ml/gcc/2010-07/msg00440.html

That's the status report...

[Ozkan Sezer]

Post by NightStrike

Post by Luis Lavena

Post by NightStrike
Is there a GCC PR for that?

http://gcc.gnu.org/ml/gcc/2010-07/msg00440.html

That's the status report...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601

[Luis Lavena]

Post by NightStrike

Post by Luis Lavena

Post by NightStrike
Is there a GCC PR for that?

http://gcc.gnu.org/ml/gcc/2010-07/msg00440.html

That's the status report...

http://gcc.gnu.org/

Which links to 4.5 page http://gcc.gnu.org/gcc-4.5/

Which link to the general changes page:

http://gcc.gnu.org/gcc-4.5/changes.html

That seems to help?

[Ruben Van Boxem]

I get this error with TDM GCC (x64) with Qt 4.7 configure:

*In file included from

f:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/sspi.h:10:0,
*
* from
f:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/security.h:31,
*
* from
F:\Development\Source\Qt/src/corelib/io/qfsfileengine_win.cpp:69:*
error: macro names must be identifiers*
*mingw32-make: *** [qfsfileengine_win.o] Error 1*
*Building qmake failed, return code 2*

I have not investigated further, have no time right now, will do later. This
was not present in the 4.5.0 release.

Ruben

[John E. / TDM]

*snip*

error: macro names must be identifiers*

Looks like jon_y fixed it a few revisions later in r3440. You can fix it
by changing the #ifdef on that line to an #if.

-John E. / TDM

[Bidski]

Just uninstalled TDM64 GCC-4.5.0 and installed 4.5.1 and attempted to
re-build wxWidgets 2.9.1. However I am met with this error during the
configure stage

C:/MinGW/lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o): In function `main':
c:\crossdev\build-mingw64-crt\mingw-w64-crt/../../mingw-w64-svn/mingw-w64-crt/crt/crt0_c.c:18:
undefined reference to `_WinMain'
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/libgcc.a(__main.o): In
function `__do_global_ctors':
c:\crossdev\build\gcc-tdm64\x86_64-w64-mingw32\libgcc/../../../../src/gcc-4.5.1/libgcc/../gcc/libgcc2.c:2168:
undefined reference to `atexit'
collect2: ld returned 1 exit status
configure:14803: $? = 1
configure:14841: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "wxWidgets"
| #define PACKAGE_TARNAME "wxwidgets"
| #define PACKAGE_VERSION "2.9.1"
| #define PACKAGE_STRING "wxWidgets 2.9.1"
| #define PACKAGE_BUGREPORT "wx-***@lists.wxwidgets.org"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:14848: error: C compiler cannot create executables
See `config.log' for more details.

I used the auto-installer to download and install the pre-built packages of
TDM64.

In this a problem with wxWidgets or with TDM64?

Regards
Bidski

[Bidski]

Just uninstalled TDM64 GCC-4.5.0 and installed 4.5.1 and attempted to
re-build wxWidgets 2.9.1. However I am met with this error during the
configure stage

C:/MinGW/lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o): In function `main':
c:\crossdev\build-mingw64-crt\mingw-w64-crt/../../mingw-w64-svn/mingw-w64-crt/crt/crt0_c.c:18:
undefined reference to `_WinMain'
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/libgcc.a(__main.o): In
function `__do_global_ctors':
c:\crossdev\build\gcc-tdm64\x86_64-w64-mingw32\libgcc/../../../../src/gcc-4.5.1/libgcc/../gcc/libgcc2.c:2168:
undefined reference to `atexit'
collect2: ld returned 1 exit status
configure:14803: $? = 1
configure:14841: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "wxWidgets"
| #define PACKAGE_TARNAME "wxwidgets"
| #define PACKAGE_VERSION "2.9.1"
| #define PACKAGE_STRING "wxWidgets 2.9.1"
| #define PACKAGE_BUGREPORT "wx-***@lists.wxwidgets.org"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:14848: error: C compiler cannot create executables
See `config.log' for more details.

I used the auto-installer to download and install the pre-built packages of
TDM64.

Can anyone tell me what is happening here?

Regards
Bidski

[Bidski]

OK, I solved that original problem by copying the files from the
C:\MinGW\x86_64-w64-mingw32 directory to the C:\MinGW directory, but now I
am getting a problem with strnlen not being declared. The error is once
again from building wxWidgets-2.9.1, during the make stage this time though.

In file included from ../include/wx/crt.h:20:0,
from ../include/wx/string.h:4280,
from ../include/wx/memory.h:16,
from ../include/wx/object.h:20,
from ../include/wx/utils.h:19,
from ../include/wx/vector.h:31,
from ../src/stc/scintilla/src/Selection.h:134,
from ../src/stc/scintilla/src/Editor.cxx:41:
../include/wx/wxcrt.h: In function 'size_t wxStrnlen(const char*, size_t)':
../include/wx/wxcrt.h:174:92: error: 'strnlen' was not declared in this
scope
make: *** [wxscintilla_Editor.o] Error 1

The check in configure returns positive for finding strnlen

configure:36036: checking for strnlen
configure:36092: gcc -o conftest.exe -m64 -m64
conftest.c -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32
-lwsock32 -lgdi32 >&5
configure:36098: $? = 0
configure:36116: result: yes

Im sure this has to be a problem with TDM64-4.5.1 as this exact copy of
wxWidgets was built successfully without any problems at all under
TDM64-4.5.0.

Is anyone else having problems like this?

Regards
Bidski

[JonY]

Post by Bidski
OK, I solved that original problem by copying the files from the
C:\MinGW\x86_64-w64-mingw32 directory to the C:\MinGW directory, but now I
am getting a problem with strnlen not being declared. The error is once
again from building wxWidgets-2.9.1, during the make stage this time though.
In file included from ../include/wx/crt.h:20:0,
from ../include/wx/string.h:4280,
from ../include/wx/memory.h:16,
from ../include/wx/object.h:20,
from ../include/wx/utils.h:19,
from ../include/wx/vector.h:31,
from ../src/stc/scintilla/src/Selection.h:134,
../include/wx/wxcrt.h:174:92: error: 'strnlen' was not declared in this
scope
make: *** [wxscintilla_Editor.o] Error 1
The check in configure returns positive for finding strnlen
configure:36036: checking for strnlen
configure:36092: gcc -o conftest.exe -m64 -m64
conftest.c -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32
-lwsock32 -lgdi32>&5
configure:36098: $? = 0
configure:36116: result: yes
Im sure this has to be a problem with TDM64-4.5.1 as this exact copy of
wxWidgets was built successfully without any problems at all under
TDM64-4.5.0.
Is anyone else having problems like this?
Regards
Bidski

Hi,

Note the driver used for the compile test. C test passes but not C++. I
think strnlen is disabled for C++, or maybe somebody forgot to include
the correct headers.

[Bidski]

Post by JonY
Note the driver used for the compile test. C test passes but not C++. I
think strnlen is disabled for C++, or maybe somebody forgot to include
the correct headers.

In C:\MinGW\string.h there is the following

#if 0
size_t __cdecl strnlen(const char *_Str,size_t _MaxCount);
#endif

It is the only reference to strnlen that I can find.

Regards
Bidski

[Bidski]

Is there a reason why strnlen has been excluded thusly?

Regards
Bidski

[Kai Tietz]

Post by Bidski
Is there a reason why strnlen has been excluded thusly?
Regards
Bidski

Hmm, not sure. I think it was due an issue in building bootstrap, but
I can't recall it.

Kai

[Ozkan Sezer]

Post by Kai Tietz

Post by Bidski
Is there a reason why strnlen has been excluded thusly?
Regards
Bidski

Hmm, not sure. I think it was due an issue in building bootstrap, but
I can't recall it.
Kai

strnlen doesn't exist in msvcrt.dll from x86-winxp

we can implement it roughly like:

size_t __cdecl strnlen (const char *s, size_t maxlen)
{
size_t siz = __builtin_strlen(s);
if (siz > maxlen) siz = maxlen;
return siz;
}

... either as an inline or as a macro and/or in libmingwex.a

[Kai Tietz]

Post by Ozkan Sezer

Post by Kai Tietz

Post by Bidski
Is there a reason why strnlen has been excluded thusly?
Regards
Bidski

Hmm, not sure. I think it was due an issue in building bootstrap, but
I can't recall it.
Kai

strnlen doesn't exist in msvcrt.dll from x86-winxp
size_t __cdecl strnlen (const char *s, size_t maxlen)
{
 size_t siz = __builtin_strlen(s);
 if (siz > maxlen) siz = maxlen;
 return siz;
}
... either as an inline or as a macro and/or in libmingwex.a

Yeah, this would be a good work-a-round for it. We should add it to
our libmingwex library. Then we can remove this #if 0 ... #endif for
it. Patch is pre-approved for it.

Kai

[Ozkan Sezer]

Post by Kai Tietz

Post by Ozkan Sezer

Post by Kai Tietz

Post by Bidski
Is there a reason why strnlen has been excluded thusly?
Regards
Bidski

Hmm, not sure. I think it was due an issue in building bootstrap, but
I can't recall it.
Kai

strnlen doesn't exist in msvcrt.dll from x86-winxp
size_t __cdecl strnlen (const char *s, size_t maxlen)
{
 size_t siz = __builtin_strlen(s);
 if (siz > maxlen) siz = maxlen;
 return siz;
}
... either as an inline or as a macro and/or in libmingwex.a

Yeah, this would be a good work-a-round for it. We should add it to
our libmingwex library. Then we can remove this #if 0 ... #endif for
it. Patch is pre-approved for it.
Kai

See v1.0 ***@3512 and ***@3513. Notify me of any problems with it.

--
O.S.

[John E. / TDM]

Post by Ozkan Sezer
strnlen doesn't exist in msvcrt.dll from x86-winxp
size_t __cdecl strnlen (const char *s, size_t maxlen)
{
size_t siz = __builtin_strlen(s);
if (siz> maxlen) siz = maxlen;
return siz;
}

This is not a good implementation of strnlen. The purpose of using
strnlen is to avoid reading past the end of a buffer of known size --

Quote from
<http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx>:
*

Post by Ozkan Sezer
*strnlen* is not a replacement for *strlen*; *strnlen* is only
intended to be used to calculate the size of incoming untrusted data
in a buffer of known size (such as a network packet). *strnlen* will
calculate the length but not walk past the end of your buffer if the
string is unterminated.

*
Here is a correct (albeit slightly less performant than assembly)
strnlen implementation:

size_t strnlen(const char* s, size_t maxlen)
{
const char* s2 = s;
while (s2 - s < maxlen && *s2)
++s2;
return s2 - s;
}

Post by Ozkan Sezer
However, *strnlen* and *strnlen_l* interpret the string as a
single-byte character string, so its return value is always equal to
the number of bytes, even if the string contains multibyte characters.

-John E. / TDM

[Ozkan Sezer]

Post by Ozkan Sezer
strnlen doesn't exist in msvcrt.dll from x86-winxp
size_t __cdecl strnlen (const char *s, size_t maxlen)
{
  size_t siz = __builtin_strlen(s);
  if (siz>  maxlen) siz = maxlen;
  return siz;
}

This is not a good implementation of strnlen. The purpose of using strnlen
is to avoid reading past the end of a buffer of known size --
Quote from
*

Post by Ozkan Sezer
*strnlen* is not a replacement for *strlen*; *strnlen* is only intended to
be used to calculate the size of incoming untrusted data in a buffer of
known size (such as a network packet). *strnlen* will calculate the length
but not walk past the end of your buffer if the string is unterminated.

*
Here is a correct (albeit slightly less performant than assembly) strnlen
size_t strnlen(const char* s, size_t maxlen)
{
 const char* s2 = s;
 while (s2 - s < maxlen && *s2)
   ++s2;
 return s2 - s;
}

Post by Ozkan Sezer
However, *strnlen* and *strnlen_l* interpret the string as a single-byte
character string, so its return value is always equal to the number of
bytes, even if the string contains multibyte characters.

-John E. / TDM

Kai, OK I guess?

[Kai Tietz]

Post by Ozkan Sezer

Post by Ozkan Sezer
strnlen doesn't exist in msvcrt.dll from x86-winxp
size_t __cdecl strnlen (const char *s, size_t maxlen)
{
  size_t siz = __builtin_strlen(s);
  if (siz>  maxlen) siz = maxlen;
  return siz;
}

This is not a good implementation of strnlen. The purpose of using strnlen
is to avoid reading past the end of a buffer of known size --
Quote from
*

Post by Ozkan Sezer
*strnlen* is not a replacement for *strlen*; *strnlen* is only intended to
be used to calculate the size of incoming untrusted data in a buffer of
known size (such as a network packet). *strnlen* will calculate the length
but not walk past the end of your buffer if the string is unterminated.

*
Here is a correct (albeit slightly less performant than assembly) strnlen
size_t strnlen(const char* s, size_t maxlen)
{
 const char* s2 = s;
 while (s2 - s < maxlen && *s2)
   ++s2;
 return s2 - s;
}

Post by Ozkan Sezer
However, *strnlen* and *strnlen_l* interpret the string as a single-byte
character string, so its return value is always equal to the number of
bytes, even if the string contains multibyte characters.

-John E. / TDM

Kai, OK I guess?

Yep, is ok. Maybe we can do here later an assembly implementation for
this, but well first comes correct behavior before speed.

Thanks,
Kai

[Ozkan Sezer]

Post by Kai Tietz

Post by Ozkan Sezer

Post by Ozkan Sezer
strnlen doesn't exist in msvcrt.dll from x86-winxp
size_t __cdecl strnlen (const char *s, size_t maxlen)
{
  size_t siz = __builtin_strlen(s);
  if (siz>  maxlen) siz = maxlen;
  return siz;
}

This is not a good implementation of strnlen. The purpose of using strnlen
is to avoid reading past the end of a buffer of known size --
Quote from
*

Post by Ozkan Sezer
*strnlen* is not a replacement for *strlen*; *strnlen* is only intended to
be used to calculate the size of incoming untrusted data in a buffer of
known size (such as a network packet). *strnlen* will calculate the length
but not walk past the end of your buffer if the string is unterminated.

*
Here is a correct (albeit slightly less performant than assembly) strnlen
size_t strnlen(const char* s, size_t maxlen)
{
 const char* s2 = s;
 while (s2 - s < maxlen && *s2)
   ++s2;
 return s2 - s;
}

Post by Ozkan Sezer
However, *strnlen* and *strnlen_l* interpret the string as a single-byte
character string, so its return value is always equal to the number of
bytes, even if the string contains multibyte characters.

-John E. / TDM

Kai, OK I guess?

Yep, is ok. Maybe we can do here later an assembly implementation for
this, but well first comes correct behavior before speed.
Thanks,
Kai
--
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

***@3514, v1.0 ***@3515. TDM: please check with the svn to verify.

--
O.S.

[John E. / TDM]

Here is a correct (albeit slightly less performant than assembly) strnlen
size_t strnlen(const char* s, size_t maxlen)
{
const char* s2 = s;
while (s2 - s< maxlen&& *s2)
++s2;
return s2 - s;
}

Looks fine. :)

-John E. / TDM

[Bidski]

Not to seem impatient or anything, but when will TDM64 be updated with this?
If it is not going to be anytime soon can someone provide me with a patched
header/library?

Regards
Bidski

[John E. / TDM]

Post by Bidski
Not to seem impatient or anything, but when will TDM64 be updated with
this? If it is not going to be anytime soon can someone provide me
with a patched header/library?

I am able to build wxWidgets 2.9.1 and wxWidgets SVN trunk with a single
one-line patch under TDM64, and would not have released it if I
couldn't. However, I always use makefile.gcc from the Windows shell, not
MSYS.

At any rate, the only way to prove to me that there is a TDM-GCC bug is
with a single-file test case that should compile but does not.

-John E. / TDM

--

--- a/src/msw/dlmsw.cpp
+++ b/src/msw/dlmsw.cpp
@@ -83,7 +83,7 @@
// recent SDK versions and is no PCSTR instead of old PSTR, we
know that
// it's const in version 11 and non-const in version 8 included
with VC8
// (and earlier), suppose that it's only changed in version 11
- #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 11
+ #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 9
typedef PCSTR NameStr_t;
#else
typedef PSTR NameStr_t;

[Ozkan Sezer]

Post by John E. / TDM

Post by Bidski
Not to seem impatient or anything, but when will TDM64 be updated with
this? If it is not going to be anytime soon can someone provide me
with a patched header/library?

I am able to build wxWidgets 2.9.1 and wxWidgets SVN trunk with a single
one-line patch under TDM64, and would not have released it if I
couldn't. However, I always use makefile.gcc from the Windows shell, not
MSYS.
At any rate, the only way to prove to me that there is a TDM-GCC bug is
with a single-file test case that should compile but does not.
-John E. / TDM
--
--- a/src/msw/dlmsw.cpp
+++ b/src/msw/dlmsw.cpp
@@ -83,7 +83,7 @@
     // recent SDK versions and is no PCSTR instead of old PSTR, we
know that
     // it's const in version 11 and non-const in version 8 included
with VC8
     // (and earlier), suppose that it's only changed in version 11
-    #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 11
+    #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 9
         typedef PCSTR NameStr_t;
     #else
         typedef PSTR NameStr_t;

Is this about dbghelp.h and/or imagehlp.h? At rev. 2254 (and
later) we had made string arguments of PSYM_ENUMMODULES_CALLBACK64,
PSYM_ENUMSYMBOLS_CALLBACK64, PSYM_ENUMSYMBOLS_CALLBACK64W,
PENUMLOADED_MODULES_CALLBACK64 and PSYM_ENUMMODULES_CALLBACK64
const. We hould increment the API_VERSION_NUMBER, too, I guess?
(added Kai to the CC list.)

--
Ozkan

[Kai Tietz]

Post by John E. / TDM

Post by Bidski
Not to seem impatient or anything, but when will TDM64 be updated with
this? If it is not going to be anytime soon can someone provide me
with a patched header/library?

I am able to build wxWidgets 2.9.1 and wxWidgets SVN trunk with a single
one-line patch under TDM64, and would not have released it if I
couldn't. However, I always use makefile.gcc from the Windows shell, not
MSYS.
At any rate, the only way to prove to me that there is a TDM-GCC bug is
with a single-file test case that should compile but does not.
-John E. / TDM
--
--- a/src/msw/dlmsw.cpp
+++ b/src/msw/dlmsw.cpp
@@ -83,7 +83,7 @@
     // recent SDK versions and is no PCSTR instead of old PSTR, we
know that
     // it's const in version 11 and non-const in version 8 included
with VC8
     // (and earlier), suppose that it's only changed in version 11
-    #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 11
+    #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 9
         typedef PCSTR NameStr_t;
     #else
         typedef PSTR NameStr_t;

Is this about dbghelp.h and/or imagehlp.h?  At rev. 2254 (and
later) we had made string arguments of PSYM_ENUMMODULES_CALLBACK64,
PSYM_ENUMSYMBOLS_CALLBACK64, PSYM_ENUMSYMBOLS_CALLBACK64W,
PENUMLOADED_MODULES_CALLBACK64 and PSYM_ENUMMODULES_CALLBACK64
const.  We hould increment the API_VERSION_NUMBER, too, I guess?
(added Kai to the CC list.)
--
Ozkan

Yeah, this we have missed. Patch is pre-approved for it.

Thanks,
Kai

[Ozkan Sezer]

Post by Kai Tietz

Post by John E. / TDM

Post by Bidski
Not to seem impatient or anything, but when will TDM64 be updated with
this? If it is not going to be anytime soon can someone provide me
with a patched header/library?

I am able to build wxWidgets 2.9.1 and wxWidgets SVN trunk with a single
one-line patch under TDM64, and would not have released it if I
couldn't. However, I always use makefile.gcc from the Windows shell, not
MSYS.
At any rate, the only way to prove to me that there is a TDM-GCC bug is
with a single-file test case that should compile but does not.
-John E. / TDM
--
--- a/src/msw/dlmsw.cpp
+++ b/src/msw/dlmsw.cpp
@@ -83,7 +83,7 @@
     // recent SDK versions and is no PCSTR instead of old PSTR, we
know that
     // it's const in version 11 and non-const in version 8 included
with VC8
     // (and earlier), suppose that it's only changed in version 11
-    #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 11
+    #if defined(API_VERSION_NUMBER) && API_VERSION_NUMBER >= 9
         typedef PCSTR NameStr_t;
     #else
         typedef PSTR NameStr_t;

Is this about dbghelp.h and/or imagehlp.h?  At rev. 2254 (and
later) we had made string arguments of PSYM_ENUMMODULES_CALLBACK64,
PSYM_ENUMSYMBOLS_CALLBACK64, PSYM_ENUMSYMBOLS_CALLBACK64W,
PENUMLOADED_MODULES_CALLBACK64 and PSYM_ENUMMODULES_CALLBACK64
const.  We hould increment the API_VERSION_NUMBER, too, I guess?
(added Kai to the CC list.)
--
Ozkan

Yeah, this we have missed. Patch is pre-approved for it.

Hmm, did some research, const changes aren't the only api changes
from 9 to 11 (ie. from xp to vista). Will post a patch for review in the dev.
list soon.

Post by Kai Tietz
Thanks,
Kai
--
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

--
Ozkan

[Bidski]

Post by Kai Tietz
Hmm, not sure. I think it was due an issue in building bootstrap, but
I can't recall it.

Is there a suggested work-a-round?

Regards
Bidski

[Ruben Van Boxem]

Post by John E. / TDM
Looks like jon_y fixed it a few revisions later in r3440. You can fix it
by changing the #ifdef on that line to an #if.

Thanks, that did it.

Next problem:

In file included from
F:\Development\Source\Qt/src/corelib/tools/qlocale.cpp:73:0:
f:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/float.h:17:24:
error: no include path in which to search for float.h

GCC's float.h is not present in GCC's lib/gcc/....../include
directory. Maybe a mixup of the workaround removal of gcc's float.h
and the new include_next fix or something? There is an upcoming
definitive fix for the stddef, stdarg and float headers in GCC 4.6,
and the newest float.h from mingw-w64 contains some code to accomodate
that I think.

I can't just comment the include_next out... there are undefined
macros then. For now I used the float.h from the previous TDM64
release to work around the problem (together with _mingw_float.h).
This allowed qmake/configure to finish, will build all of Qt in the
near future to see if any more problems pop up.

Ruben

[Ruben Van Boxem]

I have since released mingw64-runtime svn3485
(mingw64-runtime-tdm64-gcc45-svn3485), which fixes this problem and a few
others.
I have also released TDM-GCC core patch 2 (gcc-4.5.1-tdm64-1-core-2), which
fixes this problem.

You're the man! Thanks.

Ruben

[Bidski]

Post by John E. / TDM
I am able to build wxWidgets 2.9.1 and wxWidgets SVN trunk with a single
one-line patch under TDM64, and would not have released it if I couldn't.
However, I always use makefile.gcc from the Windows shell, not MSYS.
At any rate, the only way to prove to me that there is a TDM-GCC bug is
with a single-file test case that should compile but does not.
What does this have to do with strnlen?

And I now have a successfully built copy of wxWidgets-2.9.1 built under MSYS
....... dont know how considering I didnt actually change anything (except
for copying the lib and include folders from C:\MinGW\x86_64-mingw32 to
C:\MinGW and the one line patch that John E mentioned) ....... why do I
always gets these weird errors

Regards
Bidski