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

TDM-GCC 4.9 series (Latest: 4.9.2-tdm-1 - 2014-12-08)

<< < (3/12) > >>

gd_on:
Better today.
I installed a fresh version of Tdm 32 in C:\MinGW32 and a fresh version of Tdm 64 in C:\MinGW64 (previously I simply updated à Tdm 4.8.1 version)
Like that, it's OK for C::B compiled in 32 bits, using the 32 bits wxwidgets version (2.8.12), both compiled with TDM 4.9.2.
Yesterday, there was probably something, may be an old dll or a library (.a), which was in conflict.

Suggestion : as zip.exe is needed to build Codeblocks, it could be nice to add it in TDM distribution (as it is in C::B with mingw).

Nevertheless, when I compile C::B and wxwidgets 2.8.12 in 64 bits, I have still the same problem, even on a fresh 64 bits installation : C::B freezes after displaying the splash screen.
No problems when everything is compiled with Tdm 4.8.1 64 bits.

gd_on

PS : an other problem with gdb, 64 bits
If I try to debug a simple C hello program, it's OK with Tdm 4.8.1 64 bit, but not OK with Tdm 4.9.2 64 bit (error displayed at gdb.exe startup : code 0xc000007b).
If I copy inside my bin folder, gdb.exe, gdbserver.exe and python27.dll from version Tdm 4.8.1 to tdm 4.9.2 folder, it's OK : debug works.

TDragon:
Hi gd_on,

I was able to successfully build and run C::B 10050 with wxWidgets 2.8.12 using 4.9.2-tdm64-1 and -m32/-F pe-i386. I also had to manually specify which manifest file was used in C::B's resource.rc - without this, it would crash on startup with a 0x7b error due to using the AMD64 manifest instead of the x86.

I can reproduce the GDB 0x7b crash - that is due to a bad libiconv-2.dll linkage in my GDB binaries. I will need to release a new GDB package to fix that problem.

EDIT:
New GDB package released (gdb-7.8.1-tdm64-3). SourceForge has been having some outages today, hopefully they are resolved soon.

-John E. / TDM

gd_on:
Thanks, I'll have a look on monday.
But, if I understand you, when you put :

--- Quote ---wxWidgets 2.8.12 using 4.9.2-tdm64-1 and -m32/-F pe-i386
--- End quote ---
you compile a 32 bit version of C::B with tdm 64.
This is not exactly my problem. I'd like to compile a 64 bit version of C::B, of course with tdm 64.

gd_on

stahta01:

--- Quote from: gd_on on December 13, 2014, 07:35:54 pm ---Thanks, I'll have a look on monday.
But, if I understand you, when you put :

--- Quote ---wxWidgets 2.8.12 using 4.9.2-tdm64-1 and -m32/-F pe-i386
--- End quote ---
you compile a 32 bit version of C::B with tdm 64.
This is not exactly my problem. I'd like to compile a 64 bit version of C::B, of course with tdm 64.

gd_on

--- End quote ---

On windows, wxWidgets does NOT officially support 2.8 as being 64 bit compatible.
I have heard it is possible to get it built; but, it could easily have bugs in it.

Tim S.
 

gd_on:

--- Quote ---On windows, wxWidgets does NOT officially support 2.8 as being 64 bit compatible.
--- End quote ---
I have already seen this information. Nevetheless, I have myself compiled wxwidgets 2.8.12 in 64 bits (adding a cxxflag as suggested by killerbot), and it works well with C::B compiled in 64 bits too, but with TDM 64 4.8.1 version.
All the test cases in wxwidgets 2.8.12 worked as expected if they are compiled with tdm 64 version 4.8.1 and 4.9.2.
May be it's better with wxwidgets 3.x (better 64 bits support), but C::B on Windows has still problems with this version : some assert messages for example.
It's the reason why I try to have C::B with this rather old wxwidgets version. If definitely, it's not possible, i'll wait. (But it worked so well with tdm 64 4.8.1  ???)

gd_on

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version