Author Topic: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)  (Read 71033 times)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7576
    • My Best Post
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #15 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.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline gd_on

  • Lives here!
  • ****
  • Posts: 795
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #16 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
« Last Edit: September 30, 2013, 05:34:23 pm by gd_on »
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #17 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.

« Last Edit: September 30, 2013, 05:35:32 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #18 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
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
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?

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #19 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
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #20 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
[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



« Last Edit: October 01, 2013, 11:31:45 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #21 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
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #22 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
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
[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
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
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
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
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.

« Last Edit: October 01, 2013, 02:58:48 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline gd_on

  • Lives here!
  • ****
  • Posts: 795
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #23 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 ?
« Last Edit: October 03, 2013, 10:01:46 pm by gd_on »
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #24 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:


But I can run the exe correctly without those two dlls in the PATH, so these two dlls are not needed here.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #25 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?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #26 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... ?!
« Last Edit: October 06, 2013, 07:22:10 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7576
    • My Best Post
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #27 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.
« Last Edit: October 06, 2013, 07:23:17 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #28 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #29 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
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)