Code::Blocks

User forums => General (but related to Code::Blocks) => Topic started by: TDragon on September 29, 2013, 12:36:18 am

Title: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: TDragon on September 29, 2013, 12:36:18 am
I've released new packages that should fix the drive-not-present errors, as well as the LTO error. No fix yet for the DW2 EXE-to-DLL exception bug.



For those of you who have patiently waited more than a year since the previous TDM-GCC release, your wait is over. I'm pleased to present:

TDM-GCC 4.8.1
This release includes out-of-the-box DLL-free std::thread support, 64-bit Ada support, and the usual slew of GCC improvements (http://gcc.gnu.org/gcc-4.8/changes.html).

TDM-GCC 4.8.1, the first TDM release in the GCC 4.8 series, is now available for download. As always, I've tested it on wxWidgets (2.8.12) and Code::Blocks SVN (9368) to ensure good compatibility. You can build Code::Blocks with either the TDM32 edition ("out of the box"), or the TDM64 edition (using the MinGW-w64 project's runtime and the "-m32" flag for 32-bit compilation). When building wxWidgets as a MONOLITHIC DLL, you will probably need to use the "-fno-keep-inline-dllexport" flag (mingw32-make ... CXXFLAGS="-fno-keep-inline-dllexport").

Some TDM-specific changes since the last release:

TDM-GCC comes in TWO editions:
You can choose between the classic TDM 32-bit edition and the TDM64 edition. The TDM64 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 be aware, if you build Code::Blocks yourself, that it only works as 32-bit code ("-m32") on Windows, currently -- though that will hopefully change soon. Also, 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.

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

Disclaimer:
As always, please remember:

Cheers,
John E. / TDM
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ollydbg on September 29, 2013, 04:15:49 am
Hi, John, thank you for the good work, I'm going to try your 32 bit dw2 edition now.

BTW, I just create a windows batch script to name all the *-dw2.exe files (strip the -dw2), hope that is useful for someone.
Code: [Select]
Setlocal EnableDelayedExpansion
for /f  %%i in ('dir /b *-dw2.exe') do (
set name=%%i
set name=!name:-dw2=!
ren %%i !name!
)
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: MortenMacFly on September 29, 2013, 02:46:33 pm
For those of you who have patiently waited ...
That includes me then... ;-)

Its always like x-mas if I read posts like this. Thank you once again, John!

...and nice new webpage design, btw...
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: gd_on on September 29, 2013, 03:28:44 pm
Thanks,
nevertheless I have a problem that I don't understand :
When I simply launch CB I obtain error messages like this one (here translated from French) :
mingw32-gcc.exe - No disk
There are no disk in the drive. Insert a disk in \Device\Harddisk4\DR4

and

x86_64-w64-mingw32-gcc.exe - No disk
There are no disk in the drive. Insert a disk in \Device\Harddisk4\DR4

If I load a project and try to compile it, I obtain the same messages at each mingw32 call.
If I click on ignore the message, the project is compiled correctly, but it becomes annoying when you have a big project with many calls to mingw32 (CB for example !).

What could be the problem ?

If I revert to 4.71 version, all is OK again.

gd_on
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: TDragon on September 29, 2013, 03:38:56 pm
Hi gd_on,

Can you see if it's possible to add the "-v" option to your command line and show me the output? I'd just like to see the command line output of compiling *one* file with that option, when it produces these error screens for you.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: gd_on on September 29, 2013, 04:00:28 pm
Here is the output for a simple hello program in C and with gcc 4.71
Code: [Select]
-------------- Clean: Release in Hello_cpp (compiler: GNU GCC Compiler)---------------

Cleaned "Hello_cpp - Release"

-------------- Build: Release in Hello_cpp (compiler: GNU GCC Compiler)---------------

mingw32-g++.exe -Wall -pedantic-errors -v  -c C:\Users\Gerard_2\Documents\Programmes_en_C\CodeBlocks\Hello_Cpp\Hello_cpp.cpp -o obj\Release\Hello_cpp.o
mingw32-g++.exe  -o bin\Release\Hello_cpp.exe obj\Release\Hello_cpp.o   
Using built-in specs.
COLLECT_GCC=mingw32-g++.exe
Target: mingw32
Configured with: ../../src/gcc-4.7.1/configure --build=mingw32 --enable-languages=c,c++,ada,fortran,objc,obj-c++ --enable-threads=win32 --enable-libgomp --enable-lto --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gnu-ld --disable-nls --disable-win32-registry --disable-symvers --disable-build-poststage1-with-cxx --disable-werror --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --enable-cxx-flags='-fno-function-sections -fno-data-sections' --with-pkgversion=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: win32
gcc version 4.7.1 (tdm-1)
COLLECT_GCC_OPTIONS='-Wall' '-pedantic-errors' '-v' '-c' '-o' 'obj\Release\Hello_cpp.o' '-mtune=i386' '-march=i386'
 c:/mingw32/bin/../libexec/gcc/mingw32/4.7.1/cc1plus.exe -quiet -v -iprefix c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/ C:\Users\Gerard_2\Documents\Programmes_en_C\CodeBlocks\Hello_Cpp\Hello_cpp.cpp -quiet -dumpbase Hello_cpp.cpp -mtune=i386 -march=i386 -auxbase-strip obj\Release\Hello_cpp.o -Wall -pedantic-errors -version -o C:\Users\Gerard_2\AppData\Local\Temp\ccQneD7x.s
GNU C++ (tdm-1) version 4.7.1 (mingw32)
compiled by GNU C version 4.7.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/../../../../mingw32/include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/include/c++"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/include/c++/mingw32"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/include/c++/backward"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/../../../../include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/include-fixed"
ignoring nonexistent directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.7.1/../../../../mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include/c++
 c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include/c++/mingw32
 c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include/c++/backward
 c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include
 c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/../../../../include
 c:\mingw32\bin\../lib/gcc/mingw32/4.7.1/include-fixed
End of search list.
GNU C++ (tdm-1) version 4.7.1 (mingw32)
compiled by GNU C version 4.7.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1b05afeca9d712f769248af52f554d5e
COLLECT_GCC_OPTIONS='-Wall' '-pedantic-errors' '-v' '-c' '-o' 'obj\Release\Hello_cpp.o' '-mtune=i386' '-march=i386'
 c:/mingw32/bin/../lib/gcc/mingw32/4.7.1/../../../../mingw32/bin/as.exe -v -o obj\Release\Hello_cpp.o C:\Users\Gerard_2\AppData\Local\Temp\ccQneD7x.s
GNU assembler version 2.22 (mingw32) using BFD version (GNU Binutils) 2.22
COMPILER_PATH=c:/mingw32/bin/../libexec/gcc/mingw32/4.7.1/;c:/mingw32/bin/../libexec/gcc/;c:/mingw32/bin/../lib/gcc/mingw32/4.7.1/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw32/bin/../lib/gcc/mingw32/4.7.1/;c:/mingw32/bin/../lib/gcc/;c:/mingw32/bin/../lib/gcc/mingw32/4.7.1/../../../../mingw32/lib/;c:/mingw32/bin/../lib/gcc/mingw32/4.7.1/../../../
COLLECT_GCC_OPTIONS='-Wall' '-pedantic-errors' '-v' '-c' '-o' 'obj\Release\Hello_cpp.o' '-mtune=i386' '-march=i386'
Output file is bin\Release\Hello_cpp.exe with size 934.66 KB
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))
 
The same one for a compilation with gcc 4.81
Code: [Select]
-------------- Clean: Release in Hello_cpp (compiler: GNU GCC Compiler)---------------

Cleaned "Hello_cpp - Release"

-------------- Build: Release in Hello_cpp (compiler: GNU GCC Compiler)---------------

mingw32-g++.exe -Wall -pedantic-errors -v  -c C:\Users\Gerard_2\Documents\Programmes_en_C\CodeBlocks\Hello_Cpp\Hello_cpp.cpp -o obj\Release\Hello_cpp.o
mingw32-g++.exe  -o bin\Release\Hello_cpp.exe obj\Release\Hello_cpp.o   
Using built-in specs.
COLLECT_GCC=mingw32-g++.exe
Target: mingw32
Configured with: ../../../src/gcc-4.8.1/configure --build=mingw32 --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections -DWINPTHREAD_STATIC' --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --with-pkgversion=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 4.8.1 (tdm-1)
COLLECT_GCC_OPTIONS='-Wall' '-pedantic-errors' '-v' '-c' '-o' 'obj\Release\Hello_cpp.o' '-mtune=generic' '-march=pentiumpro'
 c:/mingw32/bin/../libexec/gcc/mingw32/4.8.1/cc1plus.exe -quiet -v -iprefix c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/ -D_REENTRANT C:\Users\Gerard_2\Documents\Programmes_en_C\CodeBlocks\Hello_Cpp\Hello_cpp.cpp -quiet -dumpbase Hello_cpp.cpp -mtune=generic -march=pentiumpro -auxbase-strip obj\Release\Hello_cpp.o -Wall -pedantic-errors -version -o C:\Users\Gerard_2\AppData\Local\Temp\cccD6LPn.s
GNU C++ (tdm-1) version 4.8.1 (mingw32)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++/mingw32"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.8.1/include/c++/backward"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.8.1/include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../include"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.8.1/include-fixed"
ignoring duplicate directory "c:/mingw32/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/include/c++
 c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/include/c++/mingw32
 c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/include/c++/backward
 c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/include
 c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/../../../../include
 c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/include-fixed
 c:\mingw32\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include
End of search list.
GNU C++ (tdm-1) version 4.8.1 (mingw32)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ba981bdc3051a3f4991ef8e215402d9d
COLLECT_GCC_OPTIONS='-Wall' '-pedantic-errors' '-v' '-c' '-o' 'obj\Release\Hello_cpp.o' '-mtune=generic' '-march=pentiumpro'
 c:/mingw32/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe -v -o obj\Release\Hello_cpp.o C:\Users\Gerard_2\AppData\Local\Temp\cccD6LPn.s
GNU assembler version 2.23.1 (mingw32) using BFD version (GNU Binutils) 2.23.1
COMPILER_PATH=c:/mingw32/bin/../libexec/gcc/mingw32/4.8.1/;c:/mingw32/bin/../libexec/gcc/;c:/mingw32/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw32/bin/../lib/gcc/mingw32/4.8.1/;c:/mingw32/bin/../lib/gcc/;c:/mingw32/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/;c:/mingw32/bin/../lib/gcc/mingw32/4.8.1/../../../
COLLECT_GCC_OPTIONS='-Wall' '-pedantic-errors' '-v' '-c' '-o' 'obj\Release\Hello_cpp.o' '-mtune=generic' '-march=pentiumpro'
Output file is bin\Release\Hello_cpp.exe with size 1.14 MB
Process terminated with status 0 (0 minute(s), 11 second(s))
0 error(s), 0 warning(s) (0 minute(s), 11 second(s))
 

Thanks

gd_on
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: TDragon on September 29, 2013, 05:26:18 pm
The problem could be related to the include search path "/mingw/include" which was missed for relocation, though I can't see why it would lead to Windows referencing an offline drive. I will release new packages in a day or two that get rid of that unrelocated path, but I don't know for sure if it will fix this problem.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on September 29, 2013, 05:51:32 pm
The problem could be related to the include search path "/mingw/include" which was missed for relocation, though I can't see why it would lead to Windows referencing an offline drive. I will release new packages in a day or two that get rid of that unrelocated path, but I don't know for sure if it will fix this problem.

An really only version on MinGW had this issue; is it possible it was looking in an older version of MinGW that has this bug.
It was one of the 3.4.x versions of MinGW with this or a closely related bug.

Tim S.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: MortenMacFly on September 29, 2013, 06:02:38 pm
I got a question myself, too:

Did you (or anyone else in this forum) try to compile wx 2.8.12 with this version?
I get tons of errors, starting with:
../../src/msw/treectrl.cpp:2581:17: error: 'NMTVDISPINFOWW' was not declared in this scope
                 TV_DISPINFO *info = (TV_DISPINFO *)lParam;

...and thats it. Additionally the build log is flooded with deprecated warnings concerning win API headers.

No wx -> no C::B with this version. I wonder how gd_on managed to be able to compile C::b already...?!
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: gd_on on September 29, 2013, 07:01:26 pm
Code: [Select]
No wx -> no C::B with this version. I wonder how gd_on managed to be able to compile C::b already...?!No, I haven't compiled C::B already! I just tried to, but aborted because need a click each time mingw-gcc is invoked !

And I have not even tried to compile wx 2.8.12, so ... probably a source for future problems, but I was prepared to...

gd_on
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: gd_on on September 29, 2013, 07:13:25 pm
And another thing, not related to the previous problem, and not related to C::B, but more to tdm gfortran.
I tried to detect in a fortran program if it's compiled in 32 or 64 bits.
On your previous site, you said we could use conditional compilation. I tried such a code :
Code: [Select]
      PROGRAM hello

! Does not work ?
#ifdef _WIN32
#ifdef _WIN64
        print *, "Windows 64 bits compiler"
#else
        print *, "Windows 32 bits compiler"
#endif
#endif

      print *, "hello there Does this program work"

      END

using -cpp during compilation to activate preprocessing.
But it does not work.
I remember that you said on your previous site version that those environment variables where set if you compile with 32 and/or 64 bit compiler. But I have not found this on your new design.
Do I miss something here too ?
It's not special to 4.81 version, was already there with 4.71.

gd_on
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: TDragon on September 29, 2013, 08:21:12 pm
As of now, the installers have been reverted to use the older stable releases of w32api (3.17-2) and mingwrt (3.20-2) until MinGW.org releases fixed versions.



Did you (or anyone else in this forum) try to compile wx 2.8.12 with this version?
I get tons of errors, starting with:
../../src/msw/treectrl.cpp:2581:17: error: 'NMTVDISPINFOWW' was not declared in this scope
                 TV_DISPINFO *info = (TV_DISPINFO *)lParam;

...and thats it. Additionally the build log is flooded with deprecated warnings concerning win API headers.

My bad. I built wxWidgets and Code::Blocks with TDM-GCC 4.8.1 and MinGW.org's w32api-3.17, but released with MinGW.org's w32api-4.0.3 instead without testing it. I'll revert the installers in a little bit, which should fix this problem. (Users who installed before I revert will need to run the installer and intentionally select the older mingw-rt and w32api versions; it won't select them for you because it will detect them as being older versions, which they are.)
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: TDragon on September 29, 2013, 08:26:07 pm
And another thing, not related to the previous problem, and not related to C::B, but more to tdm gfortran.
I tried to detect in a fortran program if it's compiled in 32 or 64 bits.

Sorry, I don't know much about compiling with GFortran. Apparently it doesn't define those particular macros.

Quote
I remember that you said on your previous site version that those environment variables where set if you compile with 32 and/or 64 bit compiler. But I have not found this on your new design.

I judged this information was no longer relevant enough to post on the site. You can dump a listing of predefined macros with the following command:
gcc -dM -E - <nul
Tack on flags after the "gcc" if you want to see how they affect it.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ollydbg on September 30, 2013, 03:09:50 am
The information below gives some hint on how to choose sjlj or dw2 version of TDM-GCC when building wxWidgets lbirary.

I read a blog from VZ (a wxWidgets developer), http://wxwidgets.blogspot.com/2011/06/choosing-gcc-for-building-wxwidgets.html
Quote
And second, MinGW64 uses the so-called SJLJ exceptions which can propagate through the code not compiled with gcc, e.g. all Windows system DLLs. And in practice this is needed to be able to catch any exceptions thrown by your wxWidgets event handlers. So while DW2 exceptions used by MinGW version do have their advantages (in particular they are much more speed-efficient), SJLJ ones are preferable for wxWidgets GUI applications.
So, he suggest using SJLJ edition.

Here is my testing result of how c++ exception works under wx, the sample is under  \wxWidgets-2.8.12\samples\except, see image below
(http://i.imgur.com/X7FHnII.png)

Condition: wx lib build from TDM-GCC 4.8.1 dw2  ---> Result: crash on any c++ exception from event handler (the crash also happens in wx lib build from PCX-GCC 4.6.3 dw2), see image below:
(http://i.imgur.com/Z4bknf7.png)
Condition: wx lib build from TDM-GCC 4.7.1 sjlj  ---> Result: exception can catch correctly, no crash, see image below:
(http://i.imgur.com/TXcA4vW.png)

I have not tried TDM-GCC 4.8.1 sjlj, I think it is the same as TDM-GCC 4.7.1 sjlj.

BTW: I can successfully build wx 2.8.12 with TDM-GCC 4.8.1 dw2. (I have use the tdm-gcc-webdl.exe, you should to down grade the mingw crt to stable version)

EDIT: it looks like wxWidgets' sample excep program should work for all kinds of exception models GCCs (both sjlj and dw2), because there are no exceptions cross  non-mingw stack, so I suspect it is a bug in TDM-GCC, see this post for details. (http://forums.codeblocks.org/index.php/topic,18383.msg125696/topicseen.html#msg125696)



Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: gd_on on September 30, 2013, 04:12:46 pm
On a PC at work, I have finally been able to compile C::B with tdm 4.81 gcc ;). On this PC I have not the problem of "mingw32-gcc.exe - No disk; There are no disk in the drive. Insert a disk in \Device\Harddisk4\DR4", that I met on my own PC, at home  >:(!
I use also the last updated tdm version with winapi 3.17.
Nevertheless, I have made a small modification within wxWidgets 2.8.12, because compile time was too huge, due to apparently the back tracking of a warning: there were so many warnings that after 4 hours of messages :o, I decided to stop compilation and tried to find a workaround. I had tons of messages like this one:
Code: [Select]
C:\wxWidgets-2.8.12\include/wx/debug.h:194:43: warning: typedef 'wxDummyCheckInt' locally defined but not used [-Wunused-local-typedefs]
     #define wxFORCE_SEMICOLON typedef int wxDummyCheckInt
                                           ^
C:\wxWidgets-2.8.12\include/wx/debug.h:224:9: note: in expansion of macro 'wxFORCE_SEMICOLON'
         wxFORCE_SEMICOLON /* just to force a semicolon */
         ^
C:\wxWidgets-2.8.12\include/wx/debug.h:233:38: note: in expansion of macro 'wxCHECK2_MSG'
 #define wxCHECK_RET(cond, msg)       wxCHECK2_MSG(cond, return, msg)
                                      ^
C:\wxWidgets-2.8.12\include/wx/buffer.h:289:9: note: in expansion of macro 'wxCHECK_RET'
         wxCHECK_RET( m_bufdata->m_data, wxT("invalid wxMemoryBuffer") );
         ^
.....
in my C:\wxWidgets-2.8.12\include\wx folder, I have modified line 194 in debug.h:
original code:
Code: [Select]
#define wxFORCE_SEMICOLON typedef int wxDummyCheckIntreplaced by:
Code: [Select]
#define wxFORCE_SEMICOLON struct wxDummyCheckStruct /*typedef int wxDummyCheckInt*/This is just a hack, because like that it's the same code for gnu and non-gnu gcc compilers, but it works.
Like that, I have been able to compile wxWidget 2.8.12 with gcc 4.8.1, with largely less warnings that without my hack (there are still a few ones!).
And build a new C::B version with gcc 4.81 too (in a few minutes, as usual).
I was not totally sure it will work because of the chicken and egg problem: who is the first?
Effectively, my old version of C::B was compiled with tdm 4.71, my new wxWidgets libraries and dll were compiled with gcc 4.81. But after some tries, it's OK.
Certainly, the order in which you build wxWidgets and intermediate C::B versions is important, because at certain step I had mixed things between 4.71 and 4.81 versions.

If this can help ...


gd_on

[attachment deleted by admin]
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on September 30, 2013, 04:33:45 pm
To gd_on: I would just turn off the "-Wunused-local-typedefs" warning instead.

You way might be faster; but, that way is safer.

Tim S.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: gd_on on September 30, 2013, 04:39:08 pm
You are certainly right, but I did not know where to introduce this setting in C::B and more in wxWidget 2.8.12 generation.
And as I said, my solution is a hack, not THE solution :-\

gd_on
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ollydbg on September 30, 2013, 04:56:26 pm
Bug report about TDM-GCC 4.8.1 32bit dw2 version.

As you can see that I have report that wxWidgets's sample "excep" get crashed under TDM-GCC-dw2, to reproduce this bug, I create a minimal simple project.

The project have an exe and a dll, see attachment.

Case1: The exception can pass from dll to exe.
A() in exe call B() in dll
B() throw an exception, whether A() can catch the exception.
The result is:
TDM-GCC 4.8.1 32bit dw2  : OK
TDM-GCC 4.8.1 32bit sjlj : OK


Case2: The exception firstly pass from exe to dll, then dll to exe.
A() in exe call B() in dll
B() in dll call C() in exe
C() in exe throw an exception, whether A() can catch the exception.
TDM-GCC 4.8.1 32bit dw2    : Crash, showing a Runtime error dialog.
TDM-GCC 4.8.1 32bit sjlj   : OK
MinGW-Build 4.6.4 32bit dw2: OK


Please note that the crash also happens I try to add "-shared-libgcc -shared-libstdc++" options to TDM-GCC 4.8.1 dw2. MinGW-Build use the "-shared-libgcc -shared-libstdc++" as the default option.

The Case2 is just a simplified case of the wxWidgets excep sample.
Exe file is refer as the wx APP, the dll is refer as wx lib(dll).

EDIT:
mingw-builds x32-4.8.1-posix-dwarf-rev5 also works Ok in Case2.

Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ollydbg on September 30, 2013, 05:52:33 pm
To gd_on: I would just turn off the "-Wunused-local-typedefs" warning instead.

You way might be faster; but, that way is safer.

Tim S.

I built wx2.8.12 lib by the command
Code: [Select]
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release CXXFLAGS="-fno-keep-inline-dllexport" >log.txt 2>&1
Then I got a log.txt file which have 111460 lines. (mostly of the lines are the warning messages like: ...warning: typedef 'wxDummyCheckInt' locally defined but not used [-Wunused-local-typedefs].....)
So, maybe, I need to use:
Code: [Select]
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release CXXFLAGS="-fno-keep-inline-dllexport -Wno-unused-local-typedefs" >log.txt 2>&1
to reduce the warnings, right?

Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: TDragon on September 30, 2013, 05:53:14 pm
Bug report about TDM-GCC 4.8.1 32bit dw2 version.

As you can see that I have report that wxWidgets's sample "excep" get crashed under TDM-GCC-dw2, to reproduce this bug, I create a minimal simple project.

I can confirm that this bug is specific to TDM-GCC. No ETA for a fix yet.

-John E. / TDM
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ollydbg on October 01, 2013, 08:57:15 am
Bug report about TDM-GCC 4.8.1 32bit dw2 version.

As you can see that I have report that wxWidgets's sample "excep" get crashed under TDM-GCC-dw2, to reproduce this bug, I create a minimal simple project.

I can confirm that this bug is specific to TDM-GCC. No ETA for a fix yet.

-John E. / TDM
@John, I found a strange thing, today I use mingw-builds x32-4.8.1-posix-dwarf-rev5 to build wx2.8.12, and I see that Except sample still crash, call stack below:
Code: [Select]
[debug]> bt 30
[debug]#0  0x7c90e514 in ntdll!KiFastSystemCallRet () from C:\WINDOWS\system32\ntdll.dll
[debug]#1  0x7e419418 in WaitMessage () from C:\WINDOWS\system32\user32.dll
[debug]#2  0x7e42770a in USER32!CallMsgFilterW () from C:\WINDOWS\system32\user32.dll
[debug]#3  0x7e4249c4 in USER32!GetCursorFrameInfo () from C:\WINDOWS\system32\user32.dll
[debug]#4  0x7e43a956 in USER32!SoftModalMessageBox () from C:\WINDOWS\system32\user32.dll
[debug]#5  0x7e43a2bc in USER32!MessageBoxIndirectA () from C:\WINDOWS\system32\user32.dll
[debug]#6  0x7e4663fd in USER32!MessageBoxTimeoutW () from C:\WINDOWS\system32\user32.dll
[debug]#7  0x7e4664a2 in USER32!MessageBoxTimeoutA () from C:\WINDOWS\system32\user32.dll
[debug]#8  0x7e450877 in USER32!MessageBoxExA () from C:\WINDOWS\system32\user32.dll
[debug]#9  0x7e45082f in USER32!MessageBoxA () from C:\WINDOWS\system32\user32.dll
[debug]#10 0x77c39300 in strerror () from C:\WINDOWS\system32\msvcrt.dll
[debug]#11 0x77c3b127 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
[debug]#12 0x77c36bba in msvcrt!abort () from C:\WINDOWS\system32\msvcrt.dll
[debug]#13 0x0000000a in ?? ()
[debug]#14 0x6fc5a09d in libstdc++-6!_ZN9__gnu_cxx27__verbose_terminate_handlerEv () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#15 0x6fc54fe9 in libstdc++-6!_ZN10__cxxabiv111__terminateEPFvvE () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#16 0x6fca82f0 in libstdc++-6!_ZSt9terminatev () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#17 0x6fcadc1c in libstdc++-6!__cxa_throw () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#18 0x0040233b in MyFrame::OnThrowInt (this=0xb25cd0) at D:\exception\aaa\aaaMain.cpp:417
[debug]#19 0x627015f1 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#20 0x6276a07e in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#21 0x6276a14a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#22 0x6276a545 in wxEvtHandler::ProcessEvent(wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#23 0x004021dc in MyFrame::ProcessEvent (this=0xb25cd0, event=...) at D:\exception\aaa\aaaMain.cpp:382
[debug]#24 0x62804dc7 in wxFrameBase::ProcessCommand(int) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#25 0x627b9d64 in wxFrame::HandleCommand(unsigned short, unsigned short, void*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#26 0x627ba173 in wxFrame::MSWWindowProc(unsigned int, unsigned int, long) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#27 0x627a0cee in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#28 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#29 0x000a0528 in ?? ()
[debug](More stack frames follow...)

The exception was throw from #18 0x0040233b in MyFrame::OnThrowInt (this=0xb25cd0) at D:\exception\aaa\aaaMain.cpp:417.

But mingw-builds x32-4.8.1-posix-dwarf-rev5 can successfully run my Test Case2.

EDIT:
I just test the official MinGW GCC 4.8.1 which is dw2 by default, I also successfully pass the Case2 program, but crash happens when I run except sample code. BTW, to build the wxWidgets 2.8.12 by official MinGW 4.8.1, you need to change the header file:
Quote
edit line 2217 of /mingw/include/commctrl.h to read

#define TV_DISPINFO NMTVDISPINFO

instead of

#define TV_DISPINFO __AW(NMTVDISPINFO)
See: [Mingw-users] win32api version 4 (http://sourceforge.net/mailarchive/message.php?msg_id=31361645)



Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: TDragon on October 01, 2013, 02:16:44 pm
The wxWidgets sample crashes because it tries to throw the exception through the Windows runtime from a callback to the wxWidgets event handler. This is not supported with DW2 exception unwinding. Your test case doesn't throw through a Windows callback, which is why it works as it should under mingw-builds and MinGW.org; it exhibits a bug specific to TDM-GCC.

-John E. / TDM
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ollydbg on October 01, 2013, 02:34:15 pm
The wxWidgets sample crashes because it tries to throw the exception through the Windows runtime from a callback to the wxWidgets event handler. This is not supported with DW2 exception unwinding. Your test case doesn't throw through a Windows callback, which is why it works as it should under mingw-builds and MinGW.org; it exhibits a bug specific to TDM-GCC.

-John E. / TDM
Thanks, I know that exception can not propagate through a non-mingw build frame, but what the wxWidgets' except sample do is:
1, write a overload function the MyFrame::ProcessEvent, and write a try block there:
Code: [Select]
bool MyFrame::ProcessEvent(wxEvent& event)
{
    try
    {
        return wxFrame::ProcessEvent(event);
    }
    catch ( const wxChar *msg )
    {
        wxLogMessage(_T("Caught a string \"%s\" in MyFrame"), msg);

        return true;
    }
}

2, I think all the function up to the MyFrame::ProcessEvent is all build from the same MinGW compiler, see the call stack:
Code: [Select]
[debug]#18 0x0040233b in MyFrame::OnThrowInt (this=0xb25cd0) at D:\exception\aaa\aaaMain.cpp:417
[debug]#19 0x627015f1 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#20 0x6276a07e in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#21 0x6276a14a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#22 0x6276a545 in wxEvtHandler::ProcessEvent(wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#23 0x004021dc in MyFrame::ProcessEvent (this=0xb25cd0, event=...) at D:\exception\aaa\aaaMain.cpp:382
[debug]#24 0x62804dc7 in wxFrameBase::ProcessCommand(int) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#25 0x627b9d64 in wxFrame::HandleCommand(unsigned short, unsigned short, void*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#26 0x627ba173 in wxFrame::MSWWindowProc(unsigned int, unsigned int, long) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#27 0x627a0cee in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#28 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#29 0x000a0528 in ?? ()

You see, the call back is infact the function wxWndProc (#27), and in #23 0x004021dc in MyFrame::ProcessEvent, there is a try catch block. So, I think there is not chance that the exception will go up to the Windows call back function, which is #27 0x627a0cee in wxWndProc.

Am I right?

EDIT: the code below works correctly, my question is: it looks like exception can not propagate up cross the event handler function.
Code: [Select]
void f()
{
    throw 1;
}


void MyFrame::OnThrowInt(wxCommandEvent& WXUNUSED(event))
{
    //throw -17;
    try
    {
        f();
    }
    catch ( int i )
    {
        wxLogWarning(_T("Caught an int %d in MyApp."), i);
    }
}

EDIT2
@John, you are right. I have a mistake, because the original try catch block can not catch int type.
Code: [Select]
bool MyFrame::ProcessEvent(wxEvent& event)
{
    try
    {
        return wxFrame::ProcessEvent(event);
    }
    catch ( const wxChar *msg )
    {
        wxLogMessage(_T("Caught a string \"%s\" in MyFrame"), msg);

        return true;
    }
}
If I add one catch clause (catch ( int i )) here
Code: [Select]
bool MyFrame::ProcessEvent(wxEvent& event)
{
    try
    {
        return wxFrame::ProcessEvent(event);
    }
    catch ( int i )
    {
        wxLogWarning(_T("Caught an int %d in MyFrame."), i);
        return true;
    }
    catch ( const wxChar *msg )
    {
        wxLogMessage(_T("Caught a string \"%s\" in MyFrame"), msg);

        return true;
    }
}
then I can correctly catch this int type exception.

I see that the except sample code do have another level of try/catch block in the app level.
Code: [Select]
bool MyApp::OnExceptionInMainLoop()
{
    try
    {
        throw;
    }
    catch ( int i )
    {
        wxLogWarning(_T("Caught an int %d in MyApp."), i);
    }
    catch ( MyException& e )
    {
        wxLogWarning(_T("Caught MyException(%s) in MyApp."), e.what());
    }
    catch ( ... )
    {
        throw;
    }

    return true;
}
This try block is far up in the call stack train (cross the Windows call back function call), so exception(build with gcc-dw2) can not go there.

Sorry about the noise.

Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: gd_on on October 03, 2013, 09:05:06 pm
Hi,
finally, concerning the problem described in http://forums.codeblocks.org/index.php/topic,18383.msg125671.html#msg125671, I have found a workaround:
On my PC, this harddisk DR4 corresponds the letter H: and physically to a place where I can put some memory cards (from a camera, phone, ...). The one which makes problem is for a memory type that I don't have (MS/Pro Usb).
I simply desactivated the driver for this specific memory card and the problem disappeared ;). If necessary, I can reactivate it.

Concerning the other problem with gfortran and if it's possible to use preprocessing to be able to know if it has been compiled in 32bits ou 64bits, I tried the command you suggested :
gcc -dM -E - <nul
It works with gcc and gfortran 4.71 and 4.81, 32 bits or 64 bits version and gives exactly the same results.
So the #define are there. They are correctly interpreted and used by gcc (the same program already given but rewritten in C works!), but gfortran, even if i use the preprocessing -cpp option, does not seem to transmit them, so my #idfef WIN32 or _WIN32  or _WIN64 ... are ignored apparently!

Thanks for your work

gd_on

Edit:
It works if I add in gfortran compilation options -D_WIN32=1 for 32 bits and add -D_WIN64=1 for 64 bits compiling. But I thought this should be automatic as it is made in gcc.
More, if in the compiler option, #define Tab, I put _WIN32=1 for example, I obtain a compilation error : error unrecognized command line option '-fversion=_WIN32=1' . Is that normal ?
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ollydbg on October 06, 2013, 04:43:06 am
Bug report about TDM-GCC 4.8.1 32bit dw2 version.

As you can see that I have report that wxWidgets's sample "excep" get crashed under TDM-GCC-dw2, to reproduce this bug, I create a minimal simple project.

I can confirm that this bug is specific to TDM-GCC. No ETA for a fix yet.

-John E. / TDM
Hi, John.
I just build my simple project with "-static-libgcc -static-libstdc++" under MinGW-Build-4.6.4-dw2, MinGW-Build-4.8.1-dw2, MinGW-ORG-4.8.1, all of them can correctly catch the exception.

The strange thing is, when I build with "-static-libgcc -static-libstdc++", I see that the generated exe and dll have a implicit dependency on LIBGCC_S_DW2-1.DLL and LIBSTDC++-6.DLL, see the image shot below:
(http://i.imgur.com/MuMCrfu.png)

But I can run the exe correctly without those two dlls in the PATH, so these two dlls are not needed here.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: MortenMacFly on October 06, 2013, 07:01:48 pm
I've successfully compiled wx2.8.12, wx2.9.5 (32 and 64 bit) after adjusting some compiler options and patching the wx sources slightly. However, I am experiencing crashes of the compiler when compiling some C::B source files with wx2.9 (32 bit) only. It seem related to either the compiler options (i.e. if I leave some out some - but no specific ! - it works) or the PCH functionality... unfortunately I didn't figure out a good test case for reproduction.

My question is: Did anybody successfully compile C::B against wx2.9. with GCC 4.8.1 on Windows?
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: MortenMacFly on October 06, 2013, 07:20:00 pm
unfortunately I didn't figure out a good test case for reproduction.
OK, I found a way to reproduce:
For me, it happens when I compile a simple file like configmanager-revision.cpp
What you need to do:
- compile wx 2.9.5 with GCC 4.8.1
- start compiling C::B with the related C::B "-wx29" project -> this will create the PCH file
- when it crashes, run at the command prompt:
- g++.exe -DwxUSE_WX_RESOURCES=0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs29\include -c sdk\configmanager-revision.cpp
--> It will crash for me. Removing ANY of the remaining option will make it work but also changes the handling of the PCH file.
So it really seems related to the handling of PCH file (and yes, I've completely cleaned everything in the first place, so the PCH file is generated with GCC 4.8.1, too).

Any idea of what going on here? Note that PCH works just fine for the older wx 2.8.12... ?!
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on October 06, 2013, 07:21:05 pm
I've successfully compiled wx2.8.12, wx2.9.5 (32 and 64 bit) after adjusting some compiler options and patching the wx sources slightly. However, I am experiencing crashes of the compiler when compiling some C::B source files with wx2.9 (32 bit) only. It seem related to either the compiler options (i.e. if I leave some out some - but no specific ! - it works) or the PCH functionality... unfortunately I didn't figure out a good test case for reproduction.

My question is: Did anybody successfully compile C::B against wx2.9. with GCC 4.8.1 on Windows?

I just experienced Compiler crash (In my cause it was the MinGW GCC run time error) today because of PCH files and wxWidgets trunk compiling.

Once I finish Compiling C::B against wxWidgets trunk using TDM 4.7.1 I will try 4.8.1 TDM.

Tim S.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: MortenMacFly on October 06, 2013, 07:42:55 pm
So it really seems related to the handling of PCH file.
Ok, I've cross-checked what happens if I don't use PCH when compiling C::B and wx2.9.5 -> then it works. So at least I got a work-around. Strange that my own projects that use PCH with wx2.9.5 and this compiler work. The only difference is that they have some other options, include other files (obviously) and the PCH files are smaller.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: TDragon on October 07, 2013, 06:10:38 pm
I've released new packages that should fix the drive-not-present errors, as well as the LTO error. No fix yet for the DW2 EXE-to-DLL exception bug.

For those of you experiencing PCH problems -- are you able to try with the MinGW.org 4.8.1 toolchain (unfortunately not available yet in the TDM-GCC installer) or one of the MinGW-builds toolchains? I don't have time to take a close look at it myself right now.

-John E. / TDM
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: gd_on on October 07, 2013, 07:31:06 pm
Thanks John.
I have seen this on your web site this morning but I have only been able to try it this evening, at home, where I had the problem.
It looks OK. H: is reactivated and do not interfere.
Thanks again. ;)

gd_on
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: ptDev on October 07, 2013, 10:58:11 pm
Thank you so much for all your hard work!
Please forgive my impatience, as I even felt the need to PM you in anticipation... :)
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on October 08, 2013, 08:11:55 pm
unfortunately I didn't figure out a good test case for reproduction.
OK, I found a way to reproduce:
For me, it happens when I compile a simple file like configmanager-revision.cpp
What you need to do:
- compile wx 2.9.5 with GCC 4.8.1
- start compiling C::B with the related C::B "-wx29" project -> this will create the PCH file
- when it crashes, run at the command prompt:
- g++.exe -DwxUSE_WX_RESOURCES=0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs29\include -c sdk\configmanager-revision.cpp
--> It will crash for me. Removing ANY of the remaining option will make it work but also changes the handling of the PCH file.
So it really seems related to the handling of PCH file (and yes, I've completely cleaned everything in the first place, so the PCH file is generated with GCC 4.8.1, too).

Any idea of what going on here? Note that PCH works just fine for the older wx 2.8.12... ?!

Finally had time; it fails Compiling of PCH against wxWidgets trunk.
Disabled PCH and it is working be a while before it finishes building CB.

Googling implies cc1plus.exe might be crashing because of too small a stack size. 91M pch does not crash it; but, the wxWidget trunk results in about 140MB pch.

Possible related bug post: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926)
Possible related bug post: http://sourceforge.net/mailarchive/message.php?msg_id=30821409 (http://sourceforge.net/mailarchive/message.php?msg_id=30821409)

PCH of this size works 128 MB (134,393,772 bytes). I got this size by un-defining WX_PRECOMP and commenting out "#include <wx/wxprec.h>" in sdk_common.h. So, it might be a header included by wxprec.h that is causing the crash.

Tim S.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on October 09, 2013, 04:08:25 pm
unfortunately I didn't figure out a good test case for reproduction.
OK, I found a way to reproduce:
For me, it happens when I compile a simple file like configmanager-revision.cpp
What you need to do:
- compile wx 2.9.5 with GCC 4.8.1
- start compiling C::B with the related C::B "-wx29" project -> this will create the PCH file
- when it crashes, run at the command prompt:
- g++.exe -DwxUSE_WX_RESOURCES=0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs29\include -c sdk\configmanager-revision.cpp
--> It will crash for me. Removing ANY of the remaining option will make it work but also changes the handling of the PCH file.
So it really seems related to the handling of PCH file (and yes, I've completely cleaned everything in the first place, so the PCH file is generated with GCC 4.8.1, too).

Any idea of what going on here? Note that PCH works just fine for the older wx 2.8.12... ?!


Found what I believe to be the real cause of crashing "wx/wxprec.h" was included inside the CB Header xtra_res.h.

I have not yet confirmed this a the cause; I have to cleanup my CB source file first.
Cleanup my CB source and the results do NOT confirm the issue to be fixed by removing the include of "wx/wxprec.h".

I have given up once more; it appears almost to be a un-guarded or circular header inclusion issue.

If I include both xtra_res.h and wx/msw/wrapcctl.h along with several other headers it had an issue; but, it seems to be hard to narrow it down completely.

Tim S.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: ollydbg on October 10, 2013, 02:38:17 am
Also this post:
http://sourceforge.net/p/mingwbuilds/mailman/message/29214215/
It looks like GCC can not handle big PCH file correctly, but no one has debugged this issue. As in the message:http://sourceforge.net/mailarchive/message.php?msg_id=30821409

Kai said:
Quote
Well, this crash can have at least two different causes.  First would
be that precompiled headers are generated by different gcc-versions.
Second would be that precompiled-header-file exceeds in total 512 MB
size.

For both cases there is no real fix available for mingw-targets.

Regards,
Kai
Also, for QT, they have disabled PCH on MinGW GCC target: see:
https://codereview.qt-project.org/#change,34049
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: thomas on October 10, 2013, 01:14:03 pm
Now you only need to explain to me why your binaries are smaller.  ;D

Seriously, I switched to using MinGW-builds some months ago because Evil John wouldn't do a gcc-4.8 build, and building gcc is still something I'm not able to do successfully. I've had the impression that gcc-4.8 produces somewhat bigger executables than gcc-4.7. But alas, that's a possibility. Different compiler versions, different sizes.

Now I'm recompiling things built with the MinGW-builds 4.8.1 compiler using the TDM 4.8.1 compiler, same flags, same everything, and 731 kB becomes 710 kB.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: TDragon on October 10, 2013, 06:17:23 pm
I think you mean Lazy John. :)

At any rate that is certainly an unexpected bonus. I expected all TDM-GCC-compiled binaries to be larger due to statically linking winpthreads into every binary, but I've noticed the same phenomenon -- many binaries are actually smaller with this release.

-John E. / TDM
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on October 14, 2013, 03:36:39 pm
unfortunately I didn't figure out a good test case for reproduction.
OK, I found a way to reproduce:
For me, it happens when I compile a simple file like configmanager-revision.cpp
What you need to do:
- compile wx 2.9.5 with GCC 4.8.1
- start compiling C::B with the related C::B "-wx29" project -> this will create the PCH file
- when it crashes, run at the command prompt:
- g++.exe -DwxUSE_WX_RESOURCES=0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs29\include -c sdk\configmanager-revision.cpp
--> It will crash for me. Removing ANY of the remaining option will make it work but also changes the handling of the PCH file.
So it really seems related to the handling of PCH file (and yes, I've completely cleaned everything in the first place, so the PCH file is generated with GCC 4.8.1, too).

Any idea of what going on here? Note that PCH works just fine for the older wx 2.8.12... ?!

From CB thread http://forums.codeblocks.org/index.php/topic,18412.msg126028.html#msg126028 (http://forums.codeblocks.org/index.php/topic,18412.msg126028.html#msg126028)

Quote
Testing wxWidgets trunk SVN 70513 to see if problem exists; Did NOT see problem.

Testing wxWidgets trunk SVN 70514 to see if problem exists; Did see the problem.

Likely cause is "include/wx/generic/choicdgg.h"
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: ollydbg on October 14, 2013, 04:24:44 pm
If cc1plus.exe has debug information in it, then I think when it crashed, we can at least get a call-stack under GDB. Otherwise, it is hard to find the cause and fix it.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ToApolytoXaos on October 23, 2013, 04:33:50 pm
To gd_on: I would just turn off the "-Wunused-local-typedefs" warning instead.

You way might be faster; but, that way is safer.

Tim S.

I built wx2.8.12 lib by the command
Code: [Select]
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release CXXFLAGS="-fno-keep-inline-dllexport" >log.txt 2>&1
Then I got a log.txt file which have 111460 lines. (mostly of the lines are the warning messages like: ...warning: typedef 'wxDummyCheckInt' locally defined but not used [-Wunused-local-typedefs].....)
So, maybe, I need to use:
Code: [Select]
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release CXXFLAGS="-fno-keep-inline-dllexport -Wno-unused-local-typedefs" >log.txt 2>&1
to reduce the warnings, right?
ollydbg, I have done this myself and many warning messages were logged in a file of mine, which reports far too many warning messages to list them here in a code tag ( I have tried, that's why I said "far too many"; I can't post it due to over excessive line usage lol).

Also, another serious issue is with existing wxMSW projects I have already created. I have tried to recompile them with the currently compiled files, and it seems there's an issue with .rc files:

Code: [Select]
||=== Build: Debug in wxCartridgeStockTaking (compiler: GNU GCC Compiler) ===|
C:\Users\stefanos\GENERAL\Projects\WXPROJ~1\WXCART~1\resource.rc|3|fatal error: wx/msw/wx.rc: No such file or directory|
||can't open icon file `wx/msw/std.ico': No such file or directory|
||preprocessing failed.|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

With tdm's gcc 4.7.1 (32-bit), I did not have such issue before. Anyone else had anything similar to this?
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: grf on January 29, 2014, 10:57:06 am
Some TDM-specific changes since the last release:
  • TDM-GCC now uses POSIX-style threads in its runtime libraries by way of the MinGW-w64 "winpthreads" layer. This allows std::thread and other C++11 pthreads-based features to be used.
  • TDM-GCC's version of winpthreads is patched for fully static use, so you won't be distributing an additional pthreads DLL with your programs. The patch gives winpthreads the ability to share thread handles among DLLs and EXEs.
  • By popular request, the "-static-libstdc++" option is back. It doesn't do anything, because TDM-GCC uses a static libstdc++ by default and you have to use "-shared-libstdc++" to get the DLL version, but it doesn't cause a compile-time error anymore.
  • By dint of some upstream work and some TDM-GCC-specific hacking, the Ada language is finally available for the TDM64 edition (32-bit or 64-bit compilation).

Interesting changes. However, the new tdm-gcc 4.8.1 (32 Bit version) created for my wxWidgets project a binary, which consumes a lot more CPU power than the version before, which was compiled with tdm-gcc 4.7.1. It's a single threaded application and the profiler told me, that about 50% of the runtime was lost in the both functions _spin_lite_lock and _spin_lite_unlock...  :o
Unfortunately I have no idea where to look for the reason...
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
Post by: TDragon on February 01, 2014, 01:40:03 am
Interesting report. Those functions are part of the winpthreads layer used to implement threading functions in libgcc and libstdc++.

Coincidentally, the spinlock portion of winpthreads has been rewritten since the TDM-GCC 4.8.1 release. We'll see if the next release exhibits any improvements.

-John E. / TDM
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on February 01, 2014, 01:46:31 am

Also, another serious issue is with existing wxMSW projects I have already created. I have tried to recompile them with the currently compiled files, and it seems there's an issue with .rc files:

Code: [Select]
||=== Build: Debug in wxCartridgeStockTaking (compiler: GNU GCC Compiler) ===|
C:\Users\stefanos\GENERAL\Projects\WXPROJ~1\WXCART~1\resource.rc|3|fatal error: wx/msw/wx.rc: No such file or directory|
||can't open icon file `wx/msw/std.ico': No such file or directory|
||preprocessing failed.|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

With tdm's gcc 4.7.1 (32-bit), I did not have such issue before. Anyone else had anything similar to this?

That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: ToApolytoXaos on February 01, 2014, 09:50:14 am
That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.

Hey Tim S., thanks for the reply. I have discovered the issue a long time ago and thought it was my problem, but seems it does it occasionally without any "warning" or whatsoever.

I have had created projects in the past with wxMSW-2.8.10, set my global variable names in Build options... > Search directories with standard C::B naming, like $(#wx.include) and so forth, and for some reason it would replace the variables with full expanded path; for example, C:\wxMSW-2.8.10\include etc etc.

That is why it would fail to build them with wxMSW-2.8.12, because the path it would look for, it would not exist anymore as I have removed it in favor of wxMSW-2.8.12.

Yes, I saved the project to accept any changes; besides, it would not let me close the project without accepting or discarding any project changes upon exit. It does not do this every time though; it happens from time to time, only on Windows of course.
Title: Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
Post by: stahta01 on February 01, 2014, 03:30:26 pm
That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.

Hey Tim S., thanks for the reply. I have discovered the issue a long time ago and thought it was my problem, but seems it does it occasionally without any "warning" or whatsoever.

I have had created projects in the past with wxMSW-2.8.10, set my global variable names in Build options... > Search directories with standard C::B naming, like $(#wx.include) and so forth, and for some reason it would replace the variables with full expanded path; for example, C:\wxMSW-2.8.10\include etc etc.

That is why it would fail to build them with wxMSW-2.8.12, because the path it would look for, it would not exist anymore as I have removed it in favor of wxMSW-2.8.12.

Yes, I saved the project to accept any changes; besides, it would not let me close the project without accepting or discarding any project changes upon exit. It does not do this every time though; it happens from time to time, only on Windows of course.

Are you positive you used "$(#wx.include)" instead of $(#wx)/include) or $(#wx)\include) because I never had it happen to me.
But, I use "$(#wx.include)" all the time.

Tim S.