The first TDM-GCC release in the 4.4 series is now available!Yes, it did take a bit longer than usual from GCC vanilla release to TDM release, but hopefully you'll find it's worth it. Beyond a whole slew of minor improvements to standards-compliance and error checking, there are some nifty new optimizations -- particularly the Graphite loop optimizations. See http://gcc.gnu.org/gcc-4.4/changes.html for an overview of changes in the 4.4 series.
As usual, I tested this release by successfully building wxWidgets (2.8.10) and Code::Blocks (SVN r5554). Some helpful coding style diagnostics were produced, but no untoward errors in either!
Binary packages are available for the Ada, C, C++, Fortran, Objective-C, and Objective-C++ languages, as drop-in replacements for the MinGW (http://www.mingw.org/) project's official gcc packages. Full details and download links are at http://www.tdragon.net/recentgcc/ .
Disclaimer:The TDM-GCC builds are unofficial replacements for the official MinGW releases of GCC binaries. TDM-GCC was previously recommended for experimentation purposes only, but constant use in day-to-day development and a total download count of over 60,000 have proven the TDM-GCC releases to be at least as usable as the most recent official MinGW GCC release.
(Please note that this does not mean that there are no bugs; merely that there is a different set of bugs with a similar or lesser average criticality.) Therefore, TDM-GCC is now heartily endorsed for production use in any non-critical environment, with only the following caveats:
- TDM-GCC is not formally affiliated with or endorsed by the MinGW project (although several MinGW team members make use of it)
- 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
Great ^^ I was waiting for this release since gcc.gnu.org announced the 4.4.0 of this marvelous cpp compiler.
Thanks for porting it to Windows and thanks to the Code::Blocks team for their wonderful IDE
Thanks !!!
But I could not build CB : (wxwidgets was ok):
-------------- Build: src in Code::Blocks ---------------
mingw32-g++.exe -Ldevel -Lsrc\wxAUI -Lbase\tinyxml -LC:\wxMSW-2.8.10\lib\gcc_dll -LC:\MinGW\lib -o devel\codeblocks.exe .objs\src\app.o .objs\src\appglobals.o .objs\src\associations.o .objs\src\compilersettingsdlg.o .objs\src\crashhandler.o .objs\src\dlgabout.o .objs\src\dlgaboutplugin.o .objs\src\environmentsettingsdlg.o .objs\src\infopane.o .objs\src\ipc.o .objs\src\main.o .objs\src\printdlg.o .objs\src\scriptconsole.o .objs\src\scriptingsettingsdlg.o .objs\src\splashscreen.o .objs\src\startherepage.o .objs\src\resources\resources.res -Wl,--enable-auto-import -lcodeblocks -lwxaui -lwxscintilla -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw28u -mwindows
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Unregister':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:189: multiple definition of `_Unwind_SjLj_Unregister'
devel/libcodeblocks.a(d000028.o):(.text+0x0): first defined here
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Register':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:142: multiple definition of `_Unwind_SjLj_Register'
devel/libcodeblocks.a(d000025.o):(.text+0x0): first defined here
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Resume':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_SjLj_Resume'
devel/libcodeblocks.a(d000026.o):(.text+0x0): first defined here
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 9 seconds)
3 errors, 0 warnings
-------------- Build: src in Code::Blocks ---------------
mingw32-g++.exe -Ldevel -Lsrc\wxAUI -Lbase\tinyxml -LC:\wxMSW-2.8.10\lib\gcc_dll -LC:\MinGW\lib -o devel\codeblocks.exe .objs\src\app.o .objs\src\appglobals.o .objs\src\associations.o .objs\src\compilersettingsdlg.o .objs\src\crashhandler.o .objs\src\dlgabout.o .objs\src\dlgaboutplugin.o .objs\src\environmentsettingsdlg.o .objs\src\infopane.o .objs\src\ipc.o .objs\src\main.o .objs\src\printdlg.o .objs\src\scriptconsole.o .objs\src\scriptingsettingsdlg.o .objs\src\splashscreen.o .objs\src\startherepage.o .objs\src\resources\resources.res -Wl,--enable-auto-import -lcodeblocks -lwxaui -lwxscintilla -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw28u -mwindows
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Unregister':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:189: multiple definition of `_Unwind_SjLj_Unregister'
devel/libcodeblocks.a(d000028.o):(.text+0x0): first defined here
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Register':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:142: multiple definition of `_Unwind_SjLj_Register'
devel/libcodeblocks.a(d000025.o):(.text+0x0): first defined here
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Resume':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_SjLj_Resume'
devel/libcodeblocks.a(d000026.o):(.text+0x0): first defined here
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 9 seconds)
3 errors, 0 warnings
I think that's because you have installed gcc in 2 directories c:\mingw and d:\crossdev\b4.4.0-tdm-1 and pardon me if i'm wrong.
Hi,
same problem and same messages here.
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc is not on my PC, but may be on TDM's one ! Probably this path comes from somewhere in a distributed file...
Previously, I had TDM 4.3.3. To install this new one 4.4, I made first a copy of 4.3.3, then only replaced in folders by the content of core, g++ and fortran.
gd_on
I have the same problem like killerbot.
By the way, I haven't rebuilt the wxWidgets library with gcc 4.4.(I use the old library built with tdm-gcc 3.3, is it the problem?)
[ 94.7%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -Iinclude -Iinclude\wxFlatNotebook\include -Iinclude\scripting\include -Iinclude\scripting\sqplus -ID:\wxWidgets-2.8.10\include -ID:\wxWidgets-2.8.10\lib\gcc_dll\mswu -Iinclude\wxscintilla\include -Iinclude\tinyxml -c F:\cb_svn\src\src\startherepage.cpp -o .objs\src\startherepage.o
[100.0%] g++.exe -Ldevel -Lsrc\wxAUI -Lbase\tinyxml -LD:\wxWidgets-2.8.10\lib\gcc_dll -o devel\codeblocks.exe .objs\src\app.o .objs\src\appglobals.o .objs\src\associations.o .objs\src\compilersettingsdlg.o .objs\src\crashhandler.o .objs\src\dlgabout.o .objs\src\dlgaboutplugin.o .objs\src\environmentsettingsdlg.o .objs\src\infopane.o .objs\src\ipc.o .objs\src\main.o .objs\src\printdlg.o .objs\src\scriptconsole.o .objs\src\scriptingsettingsdlg.o .objs\src\splashscreen.o .objs\src\startherepage.o .objs\src\resources\resources.res -Wl,--enable-auto-import -lcodeblocks -lwxaui -lwxscintilla -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw28u -mwindows
d:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Unregister':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:189: multiple definition of `_Unwind_SjLj_Unregister'
devel/libcodeblocks.dll.a(d000028.o):(.text+0x0): first defined here
d:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Register':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:142: multiple definition of `_Unwind_SjLj_Register'
devel/libcodeblocks.dll.a(d000025.o):(.text+0x0): first defined here
d:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Resume':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_SjLj_Resume'
devel/libcodeblocks.dll.a(d000026.o):(.text+0x0): first defined here
collect2: ld returned 1 exit status
Process terminated with status 1 (3 minutes, 26 seconds)
3 errors, 27 warnings
My original TDM-MinGW was in D:\mingw.
I just update this folder with the new 4.4.0 version.
It seems there is no such folder named "d:\crossdev\b4.4.0-tdm-1". in my system. :D
Apparently the one change I made between the version I used to build Code::Blocks and the release version affected more than I thought!
Until this is fixed, adding "-Wl,--exclude-libs,libgcc_eh.a" to the Other linker options for the "sdk" target will allow the build to succeed.
I've uploaded patched versions of the core, g++ and fortran packages, and this problem should be gone. As always, the TDM/MinGW installer should detect the upgrades automatically when you choose "Manage"; or, if downloading manually, be sure to get the new packages ending in "-2".
Also I uploaded a new version of the installer (1.905.0) that doesn't add the "bin" directory to the PATH environment variable if it's already there.
Thanks for your effort!
I will download and test it now. :D
Edit:
build codeblocks successfully! Great!
Thanks once again for the effort :)
Unluckily this build gives me internal compiler errors (segfault) which I'm unable to properly identify.
I've got a function declared __attribute__ (( __cold__ )) contained in a namespace, and it ICEs on a harmless for() loop. If I comment out the for() or remove either attribute or namespace, it compiles fine. If I copy and paste the function as-is into a "hello world" project, it works fine.
The 4.3 compiler has no problems with the same code.
Hmm actually it turns out my my target-specific macros contain
#if(GCC_VERSION >= 440)
#define cold_func __attribute__ (( __cold__, optimize("Os") ))
and removing the optimize("Os") removes the ICE after a clean rebuild. So it's "optimize", not "cold".
Interestingly, it seems that anything other than "O1" gives an ICE... hmm...
Ok, I've manually tried all options that the big-O options turn on one by one, and -fcaller-saves is the culprit.
If one writes __attribute__ (( __optimize__ ("Os,no-caller-saves") )) the ICE is gone.
Would you by any chance be able to post code for a testcase?
Well, like I said, if I make a new project with just a main() function and the offending attribute declaration and a bogus function definition, the ICE does not occur, so that'll be no help. Posting the entire project is not an option, unluckily.
However, as described above, I found out that -fcaller-saves (which O2, O3, Os enable) is the culprit. Explicitely disabling caller saves makes the ICE go away. This might possibly give someone interested in the problem a clue where to look.
Alternatively, is there a way to tell gcc not to install signal handlers? Since it reports a segfault, this should actually kick off the just-in-time debugger if gcc didn't catch the exception, so I should be able to get a core dump.
Excuse me, What does the ICE means?
Thanks.
Quote from: ollydbg on May 03, 2009, 05:37:41 PM
Excuse me, What does the ICE means?
Thanks.
Internal Compiler Error, if I'm not wrong. ;)
It seems some DLL support OpenMP are lost in the new TDM GCC 4.4 release. ( It works fine in the TDM GCC 4.3.3)
Hi, I just generate the OpenCV library with OpenMP enabled. But it seems that a DLL file is lost. See the dependencies below.
[attachment deleted by admin]
Quote from: ollydbg on May 03, 2009, 05:37:41 PM
Excuse me, What does the ICE means?
Thanks.
Internal
Compiler
Error
I understand.
Thanks to jens and Biplab. :D
Quote from: thomas on May 03, 2009, 05:32:01 PM
However, as described above, I found out that -fcaller-saves (which O2, O3, Os enable) is the culprit. Explicitely disabling caller saves makes the ICE go away. This might possibly give someone interested in the problem a clue where to look.
Alternatively, is there a way to tell gcc not to install signal handlers? Since it reports a segfault, this should actually kick off the just-in-time debugger if gcc didn't catch the exception, so I should be able to get a core dump.
Normally with an ICE GCC reports the line number and function within its own source; is that not happening?
Quote from: ollydbg on May 03, 2009, 05:44:06 PM
It seems some DLL support OpenMP are lost in the new TDM GCC 4.4 release. ( It works fine in the TDM GCC 4.3.3)
Hi, I just generate the OpenCV library with OpenMP enabled. But it seems that a DLL file is lost. See the dependencies below.
It wouldn't really be so hard to do a search in the MinGW directory for libgomp-1.dll, would it? Check lib/gcc/mingw32/bin.
Quote from: TDragon on May 03, 2009, 09:35:09 PM
Normally with an ICE GCC reports the line number and function within its own source; is that not happening?
Afraid not :(
This is the complete thing (include paths etc. elided):
mingw32-g++-dw2.exe -O2 -Wall -g -fno-rtti -mfpmath=sse,387 -fbranch-target-load-optimize -pipe -march=core2 -msse2 -ftree-vectorize -ffast-math -funit-at-a-time -std=gnu++0x -U__STRICT_ANSI__ -funsafe-loop-optimizations -Wunsafe-loop-optimizations -Wall -Wextra -Wnon-virtual-dtor -Wfloat-equal -Wno-missing-field-initializers -Wno-multichar -Wcast-align -Wstrict-aliasing -Wshadow -I (...) -c (...) -o (...)
H:\checkout\mtc\trunk\sys\system.cpp: In function 'bool sys::init()':
H:\checkout\mtc\trunk\sys\system.cpp:177: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://www.tdragon.net/recentgcc/bugs.php> for instructions.
Process terminated with status 1 (0 minutes, 2 seconds)
Well, if you posted the file I would be happy to try to narrow it down to a simple test case.
Also, this page (http://gcc.gnu.org/bugs/segfault.html) has info on debugging a GCC segfault. TDM-GCC is compiled with --enable-checking=release (the default for upstream releases), but without -g and with -O2, so there may not be much else to be discovered without using a debug build of GCC.
Quote from: TDragon on May 03, 2009, 09:35:09 PM
It wouldn't really be so hard to do a search in the MinGW directory for libgomp-1.dll, would it? Check lib/gcc/mingw32/bin.
Shame on me :D!
It's there, Thanks for your help!
EditWhy not move these DLLs from
MinGW/lib/gcc/mingw32/bin
to
MinGW/bin
Thanks.
Here's an issue I also discovered in a TDM 4.3.x.
When I compile some simple code I get errors on GCC's own headers [I don't have this with the latest MinGW 4.2.1], the issue also does not occur on linux (4.3.1).
Quote
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/bits/postypes.h:42,
from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/iosfwd:42,
from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/ios:39,
from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/istream:40,
from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/sstream:39,
from C:\view_vipnt_buildserver\vipnt\Codec\src\CodecDisplay.cpp:1:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:159: error: '::swprintf' has not been declared
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:166: error: '::vswprintf' has not been declared
I can only get it to work when I use the following warning options :
-Winit-self -Wredundant-decls -Wcast-align -Wundef -Wfloat-equal -Winline -Wmissing-declarations -Wmissing-include-dirs -Wswitch-enum -Wswitch-default -pedantic -Wextra -Wall
-Winit-self -Wredundant-decls -Wcast-align -Wundef -Wfloat-equal -Winline -Wmissing-declarations -Wmissing-include-dirs -Wswitch-enum -Wswitch-default -pedantic -Wextra -Wall
Normally I use :
-Winit-self -Wredundant-decls -Wcast-align -Wundef -Wfloat-equal -Winline -Wmissing-declarations -Wmissing-include-dirs -Wswitch-enum -Wswitch-default -pedantic -std=c++98 -Wextra -Wall -ansi
So the moment I add any of these the error already occurs :
-std=c++98
-ansi
Is there any chance this can be fixed ??
Try this: -std=c++98 -U__STRICT_ANSI__.
Strict ANSI mode which all of the -std= options enable is pretty useless insofar as it disables 90% of CRT, at no benefit. However, you can get MinGW to compile your code using the respective standard without going into moron mode by undefining that macro in said manner.
Quotec:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:159: error: '::swprintf' has not been declared
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:166: error: '::vswprintf' has not been declared
You need to patch the cwchar header, others have done it http://www.nabble.com/-ANN--GCC-4.4.0-Released-td23207147.html
With that patch you can compile this new C++0x hello program (g++ hello.cpp -o hello.exe -std=c++0x)
#include <iostream>
#include <vector>
int main()
{
std::vector<char> v = {
0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x43, 0x2b,
0x2b, 0x30, 0x78, 0x20, 0x57, 0x6f, 0x72, 0x6c,
0x64, 0x21 };
for (auto it = v.begin(); it != v.end(); ++it)
{
std::cout << *it;
}
std::cout << std::endl;
}C++0x is cool!
I can confirm Thomas' suggestion works :-)
So I now have among the previously working options :
-std=c98++ -ansi -U__STRICT_ANSI__
What will be the real difference, with this being undefined, with respect to ensuring portable codes and very little extensions creeping in from gcc ?
How save is the workaround of just commenting out the 2 offending lines ? Is this something that will make it in the official (mingw)-gcc ??
Rather than commenting out the two lines in cwchar, surround them with #ifndef __STRICT_ANSI__/#endif. This is actually the correct fix for the problem, which I believe is merely a small oversight. This issue should be discussed with the mingw-runtime maintainer and then forwarded to GCC (probably Danny Smith).
I have been trying this for some time. I installed from the latest bundled installer, then I've got the new -2 packages seperately, still I keep getting the error. By the way, I'm linking with libsigc++, which was actually built using MinGW GCC 3.4.5. I'm pasting the error. Could someone help?
g++.exe -o dist/Debug/MinGW-Windows/urllib__ build/Debug/MinGW-Windows/urllibpp.o build/Debug/MinGW-Windows/main.o -L/C/Python26/libs -L/C/msys/1.0/local/lib -L../gtk+/lib -L/c/mingw/lib/gcc/mingw32/4.4.0 -lglibmm-2.4.dll -lpython26 -lboost_python-mgw44-mt-1_38 -lsigc-2.0 -lglib-2.0.dll
c:/mingw/lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Unregister':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:189: multiple definition of `_Unwind_SjLj_Unregister'
c:/msys/1.0/local/lib/libsigc-2.0.dll.a(d000019.o):(.text+0x0): first defined here
c:/mingw/lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Register':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:142: multiple definition of `_Unwind_SjLj_Register'
c:/msys/1.0/local/lib/libsigc-2.0.dll.a(d000016.o):(.text+0x0): first defined here
c:/mingw/lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Resume':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_SjLj_Resume'
c:/msys/1.0/local/lib/libsigc-2.0.dll.a(d000017.o):(.text+0x0): first defined here
collect2: ld returned 1 exit status
Seems like libsigc-2.0.dll.a was actually built with the first release of 4.4.0-tdm-1, or some other build that doesn't properly hide the _Unwind_* symbols. Whatever the case, it needs to be rebuilt, preferably with 4.4.0-tdm-1 r2.
Hi.
I tried rebuilding libsigc++ from source with GCC 4.4.0-tdm-1 (r2), and the .a file I get here appears to have the _Unwind_* symbols.
I downloaded libsigc++-2.2.3 and tried building with the newer release. I did a make, and the library file got built successfully, but the test programs that come with the source didn't get built, and it gave the same redefinition of _Unwind_* found, even when it was using the newly built library files built by the same make command. I'm pasting the output here.
I'm not sure if I have missed something. Or is there something I should change in the makefile? Please advice.
g++ -shared -nostdlib c:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../dllcrt2.o c:/mingw/bin/../lib/gcc/mingw32/4.4.0/crtbegin.o .libs/signal.o .libs/signal_base.o .libs/trackable.o .libs/connection.o .libs/slot.o .libs/slot_base.o .libs/lambda.o -Lc:/mingw/bin/../lib/gcc/mingw32/4.4.0 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../.. -L/mingw/lib -lstdc++ -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/4.4.0/crtend.o -Wl,--export-all-symbols -o .libs/libsigc-2.0-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libsigc-2.0.dll.a
Creating library file: .libs/libsigc-2.0.dll.a
copying selected object files to avoid basename conflicts...
rm -fr .libs/libsigc-2.0.lax
mkdir .libs/libsigc-2.0.lax
ar cru .libs/libsigc-2.0.a signal.o signal_base.o trackable.o connection.o slot.o slot_base.o lambda.o
ranlib .libs/libsigc-2.0.a
rm -fr .libs/libsigc-2.0.lax
creating libsigc-2.0.la
(cd .libs && rm -f libsigc-2.0.la && cp -p ../libsigc-2.0.la libsigc-2.0.la)
make[3]: Leaving directory `/c/opt/libsigc++-2.2.3/sigc++'
make[2]: Leaving directory `/c/opt/libsigc++-2.2.3/sigc++'
Making all in tests
make[2]: Entering directory `/c/opt/libsigc++-2.2.3/tests'
g++ -I. -I.. -I.. -I.. -g -O2 -MT test_trackable.o -MD -MP -MF .deps/test_trackable.Tpo -c -o test_trackable.o test_trackable.cc
mv -f .deps/test_trackable.Tpo .deps/test_trackable.Po
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o test_trackable.exe test_trackable.o ../sigc++/libsigc-2.0.la
mkdir .libs
g++ -g -O2 -o .libs/test_trackable.exe test_trackable.o ../sigc++/.libs/libsigc-2.0.dll.a -L/usr/local/lib
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Unregister':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:189: multiple definition of `_Unwind_SjLj_Unregister'
../sigc++/.libs/libsigc-2.0.dll.a(d000019.o):(.text+0x0): first defined here
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Register':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind-sjlj.c:142: multiple definition of `_Unwind_SjLj_Register'
../sigc++/.libs/libsigc-2.0.dll.a(d000016.o):(.text+0x0): first defined here
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/libgcc_eh.a(unwind-sjlj.o): In function `Unwind_SjLj_Resume':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_SjLj_Resume'
../sigc++/.libs/libsigc-2.0.dll.a(d000017.o):(.text+0x0): first defined here
collect2: ld returned 1 exit status
make[2]: *** [test_trackable.exe] Error 1
Post the output after adding "-v" to the link command for libsigc-2.0.dll.
Hi, I found a problem that I can't set breakpoint in a inline function.
For example: I have three files:
main.cpp
#include <iostream>
using namespace std;
#include "a.h"
int main()
{
f1();
return 0;
}a.cpp
#include "a.h"
void f2(){
f1();
}
a.h
inline void f1(){
int a=7;
a=a+1;
a=5;
};
Note, I can't set breakpoint in a.h in function f1().
When start debugging, I will receive this error from debugger(debug)
Quote
> break "C:/test/test_for_xiaowei/a.h:3"
Breakpoint 2 at 0x6: file C:/test/test_for_xiaowei/a.h, line 3. (2 locations)
>>>>>>cb_gdb:
> break "C:/test/test_for_xiaowei/main.cpp:11"
Breakpoint 3 at 0x401343: file C:\test\test_for_xiaowei\main.cpp, line 11.
>>>>>>cb_gdb:
> run
Warning:
Cannot insert breakpoint 2.
Error accessing memory address 0x6: Input/output error.
gdb: win32_init_thread_list
Any comments?
Thanks.
By the way ,I have tried many mingw package. Only TDM-MinGW can set breakpoints in a header file in CB :D
@John
Since the offical MinGW package abandon the SJLJ and use Dwarf-2 Unwinding by default.
Can TDM GCC do like this?
Thanks. :D
I have fond this gdb return a bad address
Quote
> break "C:/test/test_for_xiaowei/a.h:3"
Breakpoint 2 at 0x6: file C:/test/test_for_xiaowei/a.h, line 3. (2 locations)
Why the address is
0x6??
I wouldn't be surprised you cannot set a breakpoint in an inline function, unless you tell the compiler not to inline it. Think about it. How can you break in a function that is no longer a function? I mean, once it is inlined, its code becomes part of the calling function.
I have no idea why it considers address 0x6, though.
Thanks!
I have Googled a lot. But too confusing
1.Someone said when "-g" is enabled, a inline function will treated as a normal function.
2,I use "nm" tool to exam the symbol table in the exe file, there is a 0x4XXXXX address of an inline function :D
Edit
Here is another test:
If the inline function be referenced in two CPP file, like (main.cpp and a.cpp), then, this will reproduce the bug.
But if the inline function was only called in single cpp file, ( for example, only main.cpp call this inline function), then, I can successfully set breakpoint in the header :D
A personal God (actually a guy who works for nvidia (I guess he still works there)) once told me a way to guarantee the compiler generates the function code for that case (inline) is to query the address of the function (and use it, I think... (it was a long time ago)). However, since the code is still... inlined... everywhere else it is called, setting a breakpoint there is not likely to work, unless you call it through a function pointer (I haven't tried it myself, though).
Why don't you try with "-fno-inline"?
<edit>
Every "translation unit" (roughly each cpp file with all the included headers) that uses an inline function should get a copy of it in case it is not inlined. It would be something similar to static functions.
</edit>
Quote from: Ceniza on June 25, 2009, 08:03:46 AM
Why don't you try with "-fno-inline"?
Thanks for your help. I tested it, but this options has no effect :(.
Edit
function f1() has address
Quote
> p f1
$1 = {void (void)} 0x41894c <f1()>
So, the
0xd value is quite strange :shock:
Edit2nm -s
result:
Quote
00418818 t .text
0040d7a8 t .text
004141b8 t .text
0041894c t .text$_Z2f1v
00418968 t .text$_ZN9__gnu_cxx13__scoped_lockD1Ev
00418a1c t .text$_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE2fdEv
00418a2c t .text$_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE4fileEv
__attribute__ ((used)) is the canonical way of forcing gcc to emit a function body whether all calls are inlined or not. However, this is mostly useful for libraries or for cases where the compiler cannot possibly know that you call a function (out of inline assembly, for example). It's of little use for your debugging problem, as the function is never called, like in Ceniza's proposal.
Try __attribute__ ((noinline)), which prevents the compiler from inlining a particular function. This, however, only disables inlining, you may still face problems due to CSE and other optimisations which dead-strip function calls that have no effect.
If you want to prevent those too, use said attribute and add asm(""); in the function body. Due to the asm statement, the compiler cannot prove that no side effects take place, so it can't eleminate the function call.
EDIT:
Would have been good if I had looked at your code snippet too before answering. Class member declar-finitions as in your example are problematic. Why? Because the standard says (7.1.2.3) that these are inline, so it may be that the compiler still inlines those even if you tell it not to, as it's required by the language. Not sure what it does exactly, have to try.
Quote from: thomas on June 25, 2009, 03:08:57 PM
__attribute__ ((used)) is the canonical way of forcing gcc to emit a function body whether all calls are inlined or not. However, this is mostly useful for libraries or for cases where the compiler cannot possibly know that you call a function (out of inline assembly, for example). It's of little use for your debugging problem, as the function is never called, like in Ceniza's proposal.
Try __attribute__ ((noinline)), which prevents the compiler from inlining a particular function. This, however, only disables inlining, you may still face problems due to CSE and other optimisations which dead-strip function calls that have no effect.
If you want to prevent those too, use said attribute and add asm(""); in the function body. Due to the asm statement, the compiler cannot prove that no side effects take place, so it can't eleminate the function call.
EDIT:
Would have been good if I had looked at your code snippet too before answering. Class member declar-finitions as in your example are problematic. Why? Because the standard says (7.1.2.3) that these are inline, so it may be that the compiler still inlines those even if you tell it not to, as it's required by the language. Not sure what it does exactly, have to try.
Thank you for your help. I have tried these code below, but still has the same debug problem :(
a.h
__attribute__ ((noinline)) inline void f1(){
int a=7;
a=a+1;
a=5;
asm("");
};
By the way, I have tried another "Class member declar-finitions" examples.
main.cpp
#include <iostream>
using namespace std;
#include "a.h"
int main()
{
TestClass a;
a.func_inline();
return 0;
}
a.cpp
#include "a.h"
void f2(){
TestClass b;
b.func_inline();
}
a.h
class TestClass{
public:
void func_inline(){
int a;
a = 0;
a++;
}
};
And still I can't set breakpoint in "func_inline" function body. see below:
> break "C:/test/inline_2/main.cpp:12"
Breakpoint 2 at 0x401346: file C:\test\inline_2\main.cpp, line 12.
>>>>>>cb_gdb:
> break "C:/test/inline_2/a.h:7"
Breakpoint 3 at 0x6: file C:/test/inline_2/a.h, line 7. (2 locations)
>>>>>>cb_gdb:
> break "C:/test/inline_2/main.cpp:19"
No line 19 in file "C:\test\inline_2\main.cpp".
>>>>>>cb_gdb:
> run
Warning:
Cannot insert breakpoint 3.
Error accessing memory address 0x6: Input/output error.
Seems I can't find any way to solve this. :(
By the way , If I totally comment the code in
void f2(){
//TestClass b;
//b.func_inline();
}
then, breakpoint can be set successfully in header file. This is the same as my previous example, if an inline function be called only once, we can set breakpoints in function body. :D
Hi.
I searched on Google, but finally return to CB forum again. I find one solution that in this post by Jens.
http://forums.next.codeblocks.org/index.php/topic,9295.msg66259.html#msg66259
Using "-gstabs" in "Compiler settings -> Other options" instead works for me.This can solve my problem! :shock:
Edit
I can set breakpoints in a header file, but the program will hit that breakpoint with no line information output :(. this method still can't work.
Quote
Breakpoint 3, 0x00418952 in f1 ()
>>>>>>cb_gdb:
> cont
Breakpoint 4, 0x0041895c in f1 ()
>>>>>>cb_gdb:
> cont
Breakpoint 2, main () at C:/test/inline_test/main.cpp:12
Edit2If I use both
-gstabs -gstabs+ , then the problem can totally be solved :D
Hi guys,
does this release support elf32 object, sharedlib and exec files? the last distro didn't... not sure why though... i was forced do use this objdump tool, but that wasn't really compatible either....
why did the mingw guys turned this feature off in the first place.... i know plenty of projects that incorporate there own elf32 object loader into their programs.
cheers,
yipinx
btw.... since you took over the job to make a great install of the mingw distro *THANK YOU*... would you be so kind to repeat that with the latest nightlybuild of codeblocks, since these fellows don't like to make installers either. :? (or a updatebutton to latest nightlybuild button in codeblocks)
Why should a compiler that targets desktop Windows support ELF in the first place?
And it's not that difficult to download and unpack a Code::Blocks nightly by hand.
Hello!
I got odd message with GCC 4.4.0-tdm-1-dw2 after "Compile current file" in C::B
Compiling: op\op.cpp
Linking console executable: op\op.exe
C:\mingw\lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined reference to `WinMain@16'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings
The line "Linking console executable" shows that the link process is being executed by C::B, so this certainly is no fault of TDM-GCC. Since I never use the "Compile current file" command, I'm not sure whether this behavior is expected of Code::Blocks or not.
You are right, I found that by unclear reasons C::B uses full path for such files.
I just want to give extra thanks because for whatever crazy reason, gcc 4.4.0 broke Objective-C compiling and no amount of quick hacks from others have managed to get it working correctly. Installing gcc 4.4.0-tdm-1 completely fixed it though and I'm extremely grateful that you were working on this.
I have been using TDM-GCC in place of the official MinGW for quite some time now, and I am really happy with it.
I would like to know if mingw64 support will be available in TDM-GCC soon?
Luckily for you -- yes, hopefully, it will. I recently acquired a new dev machine running Windows 7 RC 64-bit, so once the 4.4.1 TDM release is out the door I plan to start work on the 64-bit build.
Quote from: TDragon on August 21, 2009, 07:59:58 PM
Luckily for you -- yes, hopefully, it will. I recently acquired a new dev machine running Windows 7 RC 64-bit, so once the 4.4.1 TDM release is out the door I plan to start work on the 64-bit build.
If you need help testing 64-bit builds, let me know and I would be happy to try out compiling some code in MinGW64.
Quote from: TDragon on August 21, 2009, 07:59:58 PM
Luckily for you -- yes, hopefully, it will. I recently acquired a new dev machine running Windows 7 RC 64-bit, so once the 4.4.1 TDM release is out the door I plan to start work on the 64-bit build.
Was looking forward to this one !
Do you plan to create a complete native Mingw64 environment ? (ie. binutils, make, gdb, etc.)
Thanks for the TDM releases and continue the good job...