User forums > General (but related to Code::Blocks)

TDM-Gcc is discontinued

<< < (4/10) > >>

gd_on:
OK.
I tried to run codeblocks under gdb. As it's the first time I do such a thing, I'm not totally sure of the result.
I compiled a wxWidget debug version (3.1.4 as told previously, not tested with 3.1.3 version).
I compiled codeblocks project, all wx* plugins and only lib_finder, using -g as cb_release_type and using <Variable name="WX_SUFFIX" value="ud" /> in each compiled project.

Here is a copy of the backtrace obtained in a cmd window after the crash.
If this can help...
gd_on

TDragon:
Thanks for grabbing the stack trace! It definitely confirms that the problem happens in the lib_finder contrib plugin's ~ProjectConfigurationPanel() destructor.

Does it happen if you build with CXXFLAGS="-shared-libgcc -shared-libstdc++"?

The problem happens when one of the wxTextCtrl destructors triggers a std::locale::~locale() destructor, which I'm not familiar with and don't see the dependency yet in wxWidgets' code. I'm generally suspicious of double-deletion in cases like this but I don't see anything in lib_finder triggering a deletion when it shouldn't.

gd_on:
I suppose you mean that I have to modify my wxWidgets build, which becomes :

--- Code: ---mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug CFLAGS=-g UNICODE=1 USE_OPENGL=1 VENDOR=cb_64 CXXFLAGS="-g -shared-libgcc -shared-libstdc++ -fpermissive -fno-keep-inline-dllexport -std=gnu++11 -Wno-deprecated-declarations" LDFLAGS="-Wl,--allow-multiple-definition"

--- End code ---
if it's still useful to build a debug version.

And, shall I have to generate C::B also with these flags ?

PS :
I tried with these flags in wxWidgets and C::B. The crash is always there. :-[

ollydbg:
Hi, gd_on.
I just did some test with tdm gcc 9.2 64bit. I don't see crash of the lib_finder plugin. Here is my steps:

1. download wx 3.1.3 release.
2, modify the setup.h to enable the direct2d support
3, use the command line below to build the wx library

--- Code: ---mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport" >log-release.txt 2>&1

--- End code ---
4, I build the CodeBlocks_wx31_64.cbp, all the targets in this cbp are built. (I set the cb_release_type string : -g -O0)
5, open the CodeBlocks_wx31_64.workspace, and set the lib finder plugin as the active plugin, and build this single plugin.
6, run the command: update31_64.bat
7, start the new built cb inside the cb
8, open some test project, and close the new built cb

There is no crash here.

TDragon:
That's good news @ollydbg!

This means that @gd_on could be using a version of the lib_finder plugin DLL, or a dependency DLL, built by a different toolchain.

I try to make it possible to mix DLLs and EXEs between TDM-GCC and other toolchains, but there are some cases where it's not. I'll continue to try and spot the incompatibility if I have time, but it sounds like doing a clean build of Code::Blocks and all plugins with TDM-GCC could be enough?


--- Quote ---README-gcc-tdm64.md

If you pass the -shared-libgcc and -shared-libstdc++ flags to TDM-GCC, it will built DLLs and EXEs that depend on the libgcc and libstdc++ DLLs. A DLL or EXE built with these options can safely link to a MinGW.org or MinGW-w64 DLL or EXE and pass exceptions into and out of DLLs, if the other GCC and TDM-GCC share the same GCC libstdc++ ABI. The ABI may change between GCC minor releases. 32-bit and 64-bit DLLs and EXEs mostly cannot interoperate.

--- End quote ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page