Code::Blocks Forums
User forums => General (but related to Code::Blocks) => Topic started by: TDragon on December 09, 2014, 04:31:16 am
-
Yep, it's that time again. With apologies for the extra-long wait (GCC is not getting any easier), I'm happy to present:
TDM-GCC 4.9.2
A few more Windows patches for GCC provide libatomic, gnatdll, and a bunch of GCC upstream improvements (http://gcc.gnu.org/gcc-4.9/changes.html).
TDM-GCC 4.9.2, the first TDM release in the GCC 4.9 series, is now available for download. As always, I've tested it on wxWidgets (2.8.12) and Code::Blocks SVN (10050) to ensure good compatibility. 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:
- With thanks to the MinGW-Builds maintainers at MinGW-w64, libatomic now works on MinGW targets.
- With thanks to the same guys, the GNATDLL tool is now distributed with the Ada package.
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 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:
- TDM-GCC is not formally affiliated with or endorsed by the MinGW project.
- No level of support for TDM-GCC is in any way guaranteed (although a best effort is made to fix bugs as they are found or forward them to GCC Bugzilla).
Cheers,
John E. / TDM
-
excellent news, many thanks :D
-
Well done, John!
-
Hi,
I tried to compile and link C::B with this new TDM version on windows 7 pro (64 bits), but I don't really success.
1) compile wxWidgets 2.8.12 (32 bits) : OK
2) Test cases in samples : OK (with new dll but also even with the old dll in my path, compiled with TDM 4.8.1)
3) Compile CB Svn 10050 (in 32 bits) : OK
4) Run this CB with the old wxwidgets dll (compiled with TDM 4.8.1) : OK
5) Run this CB with the new dlls : freeze : splash screen not displayed. codeblocks *32 must be killed in task manager.
Trying the same thing but in 64 bits.
step 1 : OK
step 2 : OK, but here works only with the new dlls
step 3 : OK
step 4 : Not OK : splash screen not displayed. To be honest, I was suprised that it worked in 32 bits !
step 5 : here, splash screen is displayed but C::B freezes after.
I have used the same procedures than with tdm 4.8.1 which worked perfectly.
So, I missed something or there is a problem with this new version.
Do somebody succeeded to compile and run both C::B and wxWidgets 2.8.12 under Windows 7 with this TDM 4.9.2 version ?
gd_on
-
Yes, I successfully compiled and ran Code::Blocks 10050 with wxWidgets 2.8.12, both compiled from scratch with TDM-GCC 4.9.2.
Did you remember to run update.bat?
-John E. / TDM
[attachment deleted by admin]
-
Yes, I successfully compiled and ran Code::Blocks 10050 with wxWidgets 2.8.12, both compiled from scratch with TDM-GCC 4.9.2.
Did you remember to run update.bat?
-John E. / TDM
What are all the places you had to put "-m32" in building wxWidgets and Code::Blocks?
In the CB Global compiler settings I added "-m32" to Compiler Settings/Other Options and to Linker Settings/Other linker options.
I changed the resource compiler to "windres.exe -F pe-i386" in hope it fixes the build error.
Still waiting on wxWidgets 2.8.12 to finish building so no idea if I did those options right or if the CB Options are right.
Tim S.
-
That seems right, but I haven't built Code::Blocks with the TDM64 edition recently; only the TDM32 edition (MinGW-based).
-John E. / TDM
-
Yes, I successfully compiled and ran Code::Blocks 10050 with wxWidgets 2.8.12, both compiled from scratch with TDM-GCC 4.9.2.
Did you remember to run update.bat?
-John E. / TDM
Yes, I ran update.bat. So, if it works for you and not for me, it's because I missed something, but I don't know what ?
For the 32 bits version, I use the TDM 32 bits version, so no need to add -m32.
I can obtain the same screen capture as you, but with wxwidgets dll compiled with tdm 4.8.1 !
Strange ...
I have to search what's wrong on my config !
gd_on
-
Good work, only one comment: the installer icon is black on transparent, so it dissapears on my black desktop.
-
Good work, only one comment: the installer icon is black on transparent, so it dissapears on my black desktop.
Hm, I think the effect looks cool. 8) Let's pretend I did it on purpose.
-John E. / TDM
-
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.
-
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
-
Thanks, I'll have a look on monday.
But, if I understand you, when you put :
wxWidgets 2.8.12 using 4.9.2-tdm64-1 and -m32/-F pe-i386
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
-
Thanks, I'll have a look on monday.
But, if I understand you, when you put :
wxWidgets 2.8.12 using 4.9.2-tdm64-1 and -m32/-F pe-i386
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
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.
-
On windows, wxWidgets does NOT officially support 2.8 as being 64 bit compatible.
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
-
Well, last time I tried compiling C::B 64-bit I ran into problems. Looks like some progress has been made. I was able to compile and run wxWidgets 2.8.12 and C::B svn10050 under 4.9.2-tdm64-1 with no problems. :)
(I used CXXFLAGS=-fpermissive for the wxWidgets build; no special flags for C::B).
-John E. / TDM
[attachment deleted by admin]
-
TDMGCC 4.9.2 is also working well with wxWidgets 3.0.2. The only detail I had to change was adding -std=c++11 to CXXFLAGS. Other than that, compilation of wxWidgets was free of problems.
To build wxWidget apps, it's also necessary to add -std=c++11.
Eduardo
-
Hi
I'm happy to present:
TDM-GCC 4.9.2
Thank you for the great job provided.
Just one thing : some links are wrong on your download page.
In the "TDM32 Packages" list : there is a problem with the following :
- gdb-7.6.1-1-mingw32-bin.tar.lzma
- zlib-1.2.8-1-mingw32-dll.tar.lzma
I didn't have any problem with the "TDM64 Packages list".
Regards
Xav'
-
Almost OK now.
C::B and wxwidget 2.8.12, both compiled in 32 bits with TDM 32, are OK all different PC I tried (at home and at work)
C::B and wxwidget 2.8.12, both compiled in 64 bits with TDM 64, are OK on different PC (at home and at work) but at work, there is at least one PC which has a problem with this TDM version. Why, I don't know. Probably a conflict with something, but I have not been able to locate it.
Gdb in 32 and 64 bits look OK now.
Thanks John :D
gd_on
-
TDMGCC 4.9.2 is also working well with wxWidgets 3.0.2. The only detail I had to change was adding -std=c++11 to CXXFLAGS. Other than that, compilation of wxWidgets was free of problems.
To build wxWidget apps, it's also necessary to add -std=c++11.
Eduardo
I had to use CXXFLAGS="-std=gnu++11" rather than "-std=c++11" to get wxwidgets 3.0.2 (debug) to successfully build with the 4.9 version. With 4.8.1, I never had to use any CXXFLAGS at all to build wx 3.0.2. Is 4.9 just more finicky than 4.8?
At least I learned how to add flags to the compiler options checkbox list at last, and modify existing ones, to add gnu++11 to the c++XX options already there, and keep them from stepping on each other's toes, so to speak, with the "superceded" lists.
Edit: Who knew all that was hiding behind the right-click button? ;)
-
Just one thing : some links are wrong on your download page.
In the "TDM32 Packages" list : there is a problem with the following :
- gdb-7.6.1-1-mingw32-bin.tar.lzma
- zlib-1.2.8-1-mingw32-dll.tar.lzma
Thanks for the report! These links are now fixed.
-John E. / TDM
-
Great once again, John!
-
Great once again, John!
One thing I noticed: The BFD stuff (bfd.h, libbfd.a and so on) is missing. Is this on purpose? Whats the reason?
-
TDM-GCC is a minimalist distribution without any extraneous files or supplemental libraries. I removed the development libraries generated by binutils & GDB because they weren't necessary to use GCC or GDB.
-John E. / TDM
-
Superb work, as always.
Just a question: Would you consider setting the flag -std=c++11 as active for g++ by default in the next release?
-
Superb work, as always.
Just a question: Would you consider setting the flag -std=c++11 as active for g++ by default in the next release?
I think doing -std=gnu++11 would be better and safer than -std=c++11.
Tim S.
-
Just a question: Would you consider setting the flag -std=c++11 as active for g++ by default in the next release?
Nope, if you ask me. It is up to the compiler's vendor to decide if c++11 support is safe to use as the default mode.
-
It is up to the compiler's vendor to decide if c++11 support is safe to use as the default mode.
I concur. :)
When GCC's developers implement the change, TDM-GCC will.
-John E. / TDM
-
On windows, wxWidgets does NOT officially support 2.8 as being 64 bit compatible.
I have already seen this information. Nevetheless, I have myself compiled wxwidgets 2.8.12 in 64 bits
I can hardly believe that, since wxWidgets 2.8 contains code that casts pointers to int. Which of course doesn't work too well under 64 bits, even if you somehow get the compiler to do this without bailing out.
That said, I've not been successful at compiling any version of wxWidgets with the most recent TDM compilers, neither 32 nor 64.
-
That said, I've not been successful at compiling any version of wxWidgets with the most recent TDM compilers, neither 32 nor 64.
This is what I hate about wxWidgets... I just tried again because I was sure someone would ask "What error exactly...?" and I wouldn't remember.
So I ran the same batch file that I've been using to build wxWidgets for 8 or 10 years, which of course fails with the most recent TDM compiler, and now it built just fine with the most recent TDM compiler.
How can building a piece of software be non-deterministic, this is beyond me? Only wxWidgets is ever giving me this trouble.
-
Quote from: gd_on on December 13, 2014, 08:02:13 pm
On windows, wxWidgets does NOT officially support 2.8 as being 64 bit compatible.
I have already seen this information. Nevetheless, I have myself compiled wxwidgets 2.8.12 in 64 bits
I can hardly believe that, since wxWidgets 2.8 contains code that casts pointers to int. Which of course doesn't work too well under 64 bits, even if you somehow get the compiler to do this without bailing out.
May be I'm very lucky !!
I have not found any problem in compiling and using C::B 64 with my wxwidgets 2.8.12 64 bits version. All the wxwidgets tests cases I tried, worked as expected.
May be, one day, I'll use such code with int pointers (certainly specific to Windows code), but until this, I cross my fingers !
gd_on
-
I'm very sorry if that question was already asked.
But what I'm supposed to do with that compiler if I want to build something more complicated than "Hello world!" from GNU world?
Am I need to put it in installation of mingw? Or mingw-w64? Or cygwin? Or MSYS? Or MSYS2?
With all mentioned software it is all simple - I could install packages in predefined environment and they will be detected afterwards when needed as dependencies for compiling something else. But what to do with bare metal Windows command prompt? Add every directory in PATH? Or TDM-GCC do it for me?
I've tried to find at least small tutorial on how to setup environment for TDM-GCC but with no luck.
So I need some help with that.
Oh, to avoid X Y problem - I'm currently trying to build gcc-4.9.2 with non-POSIX mingw-w64-x86_64-gcc and... yep, no luck, <sys/wait.h> not found and so on...
I hope TDM GCC could help me with that.
-
I'm very sorry if that question was already asked.
But what I'm supposed to do with that compiler if I want to build something more complicated than "Hello world!" from GNU world?
Am I need to put it in installation of mingw? Or mingw-w64? Or cygwin? Or MSYS? Or MSYS2?
With all mentioned software it is all simple - I could install packages in predefined environment and they will be detected afterwards when needed as dependencies for compiling something else. But what to do with bare metal Windows command prompt? Add every directory in PATH? Or TDM-GCC do it for me?
I've tried to find at least small tutorial on how to setup environment for TDM-GCC but with no luck.
So I need some help with that.
Oh, to avoid X Y problem - I'm currently trying to build gcc-4.9.2 with non-POSIX mingw-w64-x86_64-gcc and... yep, no luck, <sys/wait.h> not found and so on...
I hope TDM GCC could help me with that.
Trying to build MinGW GCC on Windows is very hard (I believe it is possible; I could be wrong) most people building Ming GCC builds it under Linux OS after setting up a cross GCC toolchain.
NOTE: Using the TDM GCC Compiler for a more complex program is just like using any compiler with a more complex program.
Edit: If you need Linux GNU compatible environment to run your program then Cygwin is better than MSys.
If you just need a build environment instead run env. then MSys is normally good enough unless you are doing socket programming Cygwin socket programming is closer to Unix/Linux Msys socket programming is like Windows OS.
My copy of Cygwin has a sys/wait.h header for its native gcc compiler.
No idea about TDM GCC or Msys.
Tim S.
-
No, my goal is diametric.
I want to compile gcc for specific target (SH4) to use it in Windows just like TDM-GCC I guess with some IDE without any POSIX environment shells like Cygwin or MSYS. Because if I build something in cygwin or msys that means that I need to run it in that shell or copy thousands of dlls which emulates something I don't need at all and slows down execution speeds of program.
And on the contrary I aspire to native speeds, so I need to avoid using of any POSIX-emulations.
-
No, my goal is diametric.
I want to compile gcc for specific target (SH4) to use it in Windows just like TDM-GCC I guess with some IDE without any POSIX environment shells like Cygwin or MSYS. Because if I build something in cygwin or msys that means that I need to run it in that shell or copy thousands of dlls which emulates something I don't need at all and slows down execution speeds of program.
And on the contrary I aspire to native speeds, so I need to avoid using of any POSIX-emulations.
I suggest trying to say what you really want to do!
Edit: If you want to build GCC I strongly suggest using Linux!!
I still DO NOT know if you want to build or use GCC!!
And, you have no idea what Msys is; and only a slight idea what an IDE is.
Edit2: I suggest read the rules before you are banned from this site http://forums.codeblocks.org/index.php/topic,9996.0.html (http://forums.codeblocks.org/index.php/topic,9996.0.html)
Tim S.
-
I wrote twice that I want to build regular GCC 4.9.2 with targetting of SH4 (Hitachi SuperH 4 processor) outwards of any POSIX environment.
I following the rules because I'm not asking general programming questions and I do not ask to do something for me. Is this thread not for supporting TDM-GCC users? If no then sorry, but I need confirmation from topic starter and it is not you.
And please do not share your opinion about my knowing of things. It is not gentle.
-
I wrote twice that I want to build regular GCC 4.9.2 with targetting of SH4 (Hitachi SuperH 4 processor) outwards of any POSIX environment.
I following the rules because I'm not asking general programming questions and I do not ask to do something for me. Is this thread not for supporting TDM-GCC users? If no then sorry, but I need confirmation from topic starter and it is not you.
And please do not share your opinion about my knowing of things. It is not gentle.
So ask a question on topic in this thread or for this site.
Ask TDM what steps he used to build TDM.
Because building GCC (for an non window target) is NOT an valid topic for this site; please read and follow the rules or I will ask that you be banned!
Tim S.
-
You don't get it.
I said that just to avoid X-Y problem (http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem).
What I'm asking is strongly related to this topic.
My question was - how to setup TGM-GCC in MSYS or something that allow me to build UNIX programs easily (jus by typing ./configure && make)?
-
You don't get it.
I said that just to avoid X-Y problem (http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem).
What I'm asking is strongly related to this topic.
My question was - how to setup TGM-GCC in MSYS or something that allow me to build UNIX programs easily (jus by typing ./configure && make)?
Well no, it's not strongly related, although I can see where your confusion comes from.
This site/forum is about Code::Blocks, and to keep the noise level down, our rules don't allow non-Code::Blocks content (for legal reasons -- server being located in Germany -- the moderators have to read through all posts, so there is a practical reason to keep noise down).
That actually means that the entirety of TDM threads don't belong here since they're not related to Code::Blocks at all, but it so happens that John is a cool guy and he makes cool compiler build which is also the best fit both for building and using Code::Blocks, so whatever the rules are, this is OK for us, and we're not going super-prick on him ;D
Now of course, your question about setting up a Unix-like build environment is a totally different thing (and besides, it's nowhere like you type ./configure && make to build GCC, only in your dreams -- I wish it was that easy!). Which is what stahta01 tried to point out.
-
Is there a possibility to share the bfd libs from the build so we can build a new exchndl (crash handler) against this version of GCC? Without it the build will not succeed and the old version will not work (at least for me - it makes C::B and other wx apps hang forever).
-
That actually means that the entirety of TDM threads don't belong here since they're not related to Code::Blocks at all, [...]
Well, no:
1.) C::B is build using exactly these compilers
2.) C::B ships wit exactly this (and only this) compiler.
So I'd say its definitely a C::B topic... but maybe more for the C::B developers.
-
I think this forum is the perfect place for both developers of Code::Blocks and developers that use TDM-GCC with Code::Blocks to be apprised of updates. If at any time TDM-GCC becomes no longer relevant, I will happily cease. :)
Regarding bfd, GCC itself doesn't include it, so do you mean the bfd from TDM64 binutils, or ???
-
Regarding bfd, GCC itself doesn't include it, so do you mean the bfd from TDM64 binutils, or ???
bfd is built when you build gdb. Normally, running "make -C gdb install" is enough, which means libbfd is not installed.
-
The 32-bit TDM-GCC uses the MinGW project's binutils package - that's probably where you should get libbfd.a from:
https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.24/binutils-2.24-1-mingw32-dev.tar.xz/download
-
The 32-bit TDM-GCC uses the MinGW project's binutils package - that's probably where you should get libbfd.a from:
https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.24/binutils-2.24-1-mingw32-dev.tar.xz/download
Yes, there it is. :-) Thank you...
However, I just figured out that we (I) use a completely outdated version of exchndl. "jrfonseca" did a great job in continuously further developing it - he just switched from SVN to GIT and I didn't realise. So maybe we don't even need to compile it ourselves any longer. He ships binaries (Version 0.6.4 currently) for 32 and 64 bit also supporting DWARF meanwhile.
If at any time TDM-GCC becomes no longer relevant, I will happily cease. :)
NOOOOOOOOO! ;-)
-
If at any time TDM-GCC becomes no longer relevant, I will happily cease. :)
You seem to have misunderstood me there. What I'm saying is that there's rules, but the same rules don't apply equally to everybody ;D
That's true in particular since TDM-GCC is a really nice compiler build, and the best option for building and using Code::Blocks (plus, as Morten pointed out, the compiler we bundle by default). So whether it's technically unrelated or not, I wouldn't care :)
-
John, could you explain a bit more on this : http://forums.codeblocks.org/index.php/topic,20018.msg136723.html#msg136723
-
John, could you explain a bit more on this : http://forums.codeblocks.org/index.php/topic,20018.msg136723.html#msg136723
I think its not Johns fault and what the heck, lets include this text document... so what? I think we don even need it for the installer with MinGW bundled. However, I just complained on the link provided...
-
No, it is not Johns fault, but just to get some more insights ;D
-
@TDragon: I just wanted to say thank you for all the hard work that you put into TDM-GCC. I just managed to get a 64 bit Windows shell extension working.
TDM-GCC + Code::Blocks = Awesome! 8)
-
I was thinking about replacing old MinGW env with TDM.... just not sure if I should
I would like to be able to compile and debug(gdb) for 32&64bit....
though I don't like the idea of it defaulting to compiling 64bit binaries.....
what I was hoping/looking from TDM64 is
a 64bit compiler/linker/gdb/etc that run native on 64bit windows so they run more efficiently
but since I only compile 32bit programs at this point,
I would have to retool every thing I am compiling to force 32bit --> -m32
- CodeBlocks as debug and WxWidgets compiled as debug for use with C::B
- ZSNES (SNES emu) I have followed it svn since 2004 or so though it hasn't been updated since
SVN-Info__r4838__jbo__8-39-08 PM, Thursday, March 01, 2007__ is the last commit I have from that program...
- My own Temperature Converter console app in C
(original I wrote as an assignment for cs140 2001-2002, converted F° to C° and C° to F°)
2012 I completed it does all 6 conversions, F° to C°, C° to F°, F° and C° to K, and K back to F° and C°.
I converted to C++ after that.
-
John, could you explain a bit more on this : http://forums.codeblocks.org/index.php/topic,20018.msg136723.html#msg136723
C++11 std::threads (and associated functionality) require a pthreads interface in GCC.
On Windows, the options to fulfill this requirement are pthreads-win32 or winpthreads.
Winpthreads has a MIT-like license; pthreads-win32 is LGPL. Of the two, the winpthreads license is less restrictive. However, a conscientious reading still requires distributing the text of the license with binaries based on it. (I have argued this elsewhere and won't rehash the argument here.)
Every binary created with a pthreads-enabled GCC includes portions of the pthreads library (even C programs that don't link to libstdc++, or other languages). I have personally confirmed this to be true.
Ergo, I feel compelled to warn users that they are apparently required to distribute the winpthreads license text with every program created by TDM-GCC, be it the TDM/MinGW edition or the TDM64/MinGW-w64 edition. This started with the 4.8.1 release.
Feel free to respectfully request of the MinGW-w64 project - particularly of Kai Tietz, who I believe was the primary developer of winpthreads - that the license be altered. :)
-John E. / TDM
-
I would actually prefer a compiler with no thread support, since C++11 threading sucks big time anyway ;D
Being able to fire off a lambda in a thread is admittedly cool, but the rest is just a poor rip-off of a 1990s threading API which was already unreasonable back then (such as requiring a condition variable to be protected by a mutex because, hey, there exists some 35 year old computers from Sun which have a broken implementation that requires this, so better make it standard for everyone).
That, plus some really stupefying requirements that compel library writers to add extra code which is not beneficial to anyone, except to please the guy who wrote the proposal (such as having a mutex that is not explicitly recursive throw exceptions when called recursively, even if it could be called recursively without harm).
-
Oh, Please forgive me digress！I encountered a problem, although it is estimated that the wxWidgets 3.x problem, but still want to confirm with you :-)
I also asked the same question on wxWidgets forum, please allow me to repeat here:
https://forums.wxwidgets.org/viewtopic.php?f=19&t=40788
I want to know it's not the TDM-GCC-64 issues.
Thank you.
--------------------------------------
The wxWidgets 3.0 seems to have problems, the problem does not appear in 2.8.
The TDM-GCC-64 compiled of 32bit code with the option -m32 under Windows64 will always be 0xc000007b error.
This windres also used --target = pe-i386 parameters, the compiler has succeeded. But the emergence of this 0xc000007b execution error.
The wxWidgets comes with examples you can reproduce the problem, for example: wxWidgets-3.0.2\samples\display.
In the same example wxWidgets 2.8.12 did not have this problem, it's correct.
=========================================================
For wxWidgets-3.0.2\samples\display.
In wxWidgets 3.0.2:
mingw32-make -f makefile.gcc CXXFLAGS="-std=gnu++11 -IC:\Project\wxWidgets-3.0.2\lib\gcc_dll_m32\mswu -IC:\Project\wxWidgets-3.0.2\include" CPPFLAGS="-m32 -IC:\Project\wxWidgets-3.0.2\lib\gcc_dll_m32\mswu -IC:\Project\wxWidgets-3.0.2\include" LDFLAGS="-m32 -LC:\Project\wxWidgets-3.0.2\lib\gcc_dll_m32" WINDRES="windres --target=pe-i386 --use-temp-file" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release
For wxWidgets-2.8.12\samples\display.
In wxWidgets 2.8.12 ( I modified the makefile.gcc adding parameters --target=pe-i386 ) :
mingw32-make -f makefile.gcc CXXFLAGS="-std=gnu++11 -IC:\Project\WX_2_8\lib\gcc_dll_m32\mswu -IC:\Project\WX_2_8\include" CPPFLAGS="-m32 -IC:\Project\WX_2_8\lib\gcc_dll_m32\mswu -IC:\Project\WX_2_8\include" LDFLAGS="-m32 -LC:\Project\WX_2_8\lib\gcc_dll_m32" WINDRES="windres --target=pe-i386 --use-temp-file" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release
==========================================================
C:\Project\WX_2_8\samples\display>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Tools/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/4.
9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure --build=x86_64-w64-mingw32 --e
nable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable
-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC -
-disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-d
ebug --enable-threads=posix --enable-version-specific-runtime-libs --enable-full
y-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-l
d --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm -
-with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://td
m-gcc.tdragon.net/bugs
Thread model: posix
gcc version 4.9.2 (tdm64-1)
C++11 std::threads (and associated functionality) require a pthreads interface in GCC.
On Windows, the options to fulfill this requirement are pthreads-win32 or winpthreads.
-
Check your %PATH% for incompatible DLLs. Better yet, try executing in a clean environment.
I was able to successfully compile and run Code::Blocks in TDM64 -m32 mode, so I doubt this indicates any compiler flaw.
-
Check your %PATH% for incompatible DLLs. Better yet, try executing in a clean environment.
I was able to successfully compile and run Code::Blocks in TDM64 -m32 mode, so I doubt this indicates any compiler flaw.
Thank you :-)
I also think that the compiler does not issue. Because everything is fine to use wxWidgets 2.8.12 with TDM-GCC, except wxWidgets 3.0.2 .