User forums > General (but related to Code::Blocks)
TDM-GCC 4.9 series (Latest: 4.9.2-tdm-1 - 2014-12-08)
Melchior:
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.
TDragon:
--- Quote from: killerbot on February 18, 2015, 08:02:36 pm ---John, could you explain a bit more on this : http://forums.codeblocks.org/index.php/topic,20018.msg136723.html#msg136723
--- End quote ---
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
thomas:
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).
Chun Jiu:
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)
--- Quote ---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.
--- End quote ---
TDragon:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version