TDM-Gcc is discontinued

[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 Select Expand


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"

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 Select Expand


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

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?

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.

[gd_on]

I tried to build wxwidgets 3.1.3 (and here not 3.1.4 as previously) and C::B (svn 11979) as ollydbg suggested. I have made, as far as I know, a clean build, in a totally new folder ....
But that was not enough. I have always a crash in lib_finder... strange.
As I told before, no problems with 9.2 version distributed with Msys2 !

[stahta01]

What compiler are you using with the crash?

Tim S.

[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 Select Expand


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

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.

Some more information.
I have build the whole targets in the CodeBlocks_wx31_64.workspace under TDM64bit compiler, except the FortranProject(because I use the git-svn) and the NassiShneiderman(because I don't have the boost headers)

I see no crash in the new built 64bit C::B.

[gd_on]

I use the new TDM 64 bit compiler, 9.2 version, to do these tests. I downloaded it via TDM web site.
As I told before, wxWidgets (3.1.3 or 3.1.4) is correctly compiled.
C::B itself is also correctly compiled and works for many usages, exept when I look at a workspace property, as explained before.
Normally, I use only one compiler each time, though I have several different ones on my PC. But only one is in the path and configured to be used by C::B.
May be there is sometimes a mix at compile time, but I don't see why...
I have to investigate more, sure ... If it works for others, it should work for me !

gd_on

[stahta01]

Has only one that tested lib_finder had it configured to work?
Because, I for one have no idea how to configure it to work.
And, I just wondered if it is a configuration issue that is causing it to crash.

Tim S.

[gd_on]

I don't use lib_finder until now. So it's certainly not configured. Could it be the problem in my case ?
For me disabling it, do the job.

[oBFusCATed]

If it is a configuration option problem you'll have the same problem using a night build. Is this the case? Can you try it?

[gd_on]

As told previously I use already svn 11979 build.

[TDragon]

Since the crash happens in std::locale, what's your system locale? Default character set / code page. Does the configuration contain any non-ascii characters? If so, this is a good place to dig further.

[gd_on]

My locale is fr_FR : I am french. My standard C::B is configured to use French also in the GUI.
Nevertheless, for these tries I use an other folder where the translation file of the GUI is not installed, and it appears in English.
By default, my C::B uses utf-8.
The strange thing if that it works correctly if I compile wxWidgets and C::B with gcc 8.1, 9.2 (Msys2), 9.2 (Equation), 9.2 (Winlibs) in 64 bits (not tested in 32 bits). Only TDM version gives me this problem and apparently only in a specific menu (I have not found such problems elsewhere, but surely I have not tested everithing !)