Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: TDragon on May 01, 2009, 09:19:10 pm

Title: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on May 01, 2009, 09:19:10 pm
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:

Cheers,
John E. / TDM
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Lifof on May 01, 2009, 10:25:50 pm
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
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: killerbot on May 02, 2009, 10:04:55 am
Thanks !!!


But I could not build CB : (wxwidgets was ok):

Code
-------------- 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
 
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Lifof on May 02, 2009, 10:56:20 am
Code
-------------- 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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: gd_on on May 02, 2009, 04:30:49 pm
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
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on May 02, 2009, 05:04:58 pm
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?)

Code
[ 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

Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on May 02, 2009, 06:20:18 pm
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on May 03, 2009, 01:24:39 am
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on May 03, 2009, 03:05:46 am
Thanks for your effort!
I will download and test it now. :D

Edit:

build codeblocks successfully! Great!
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: thomas on May 03, 2009, 01:50:45 pm
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: thomas on May 03, 2009, 02:09:08 pm
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...
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: thomas on May 03, 2009, 02:22:49 pm
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on May 03, 2009, 04:56:00 pm
Would you by any chance be able to post code for a testcase?
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: thomas on May 03, 2009, 05:32:01 pm
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on May 03, 2009, 05:37:41 pm
Excuse me, What does the ICE means?
Thanks.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Biplab on May 03, 2009, 05:40:46 pm
Excuse me, What does the ICE means?
Thanks.

Internal Compiler Error, if I'm not wrong. ;)
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: 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.





[attachment deleted by admin]
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Jenna on May 03, 2009, 05:48:33 pm
Excuse me, What does the ICE means?
Thanks.
Internal Compiler Error
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on May 03, 2009, 06:06:06 pm
I understand.
Thanks to jens and Biplab. :D
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on May 03, 2009, 09:35:09 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?

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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: thomas on May 04, 2009, 12:23:22 am
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)
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on May 04, 2009, 01:43:36 am
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on May 04, 2009, 03:11:25 am
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!

Edit

Why not move these DLLs from

MinGW/lib/gcc/mingw32/bin

to

MinGW/bin

Thanks.

Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: killerbot on May 08, 2009, 12:58:29 pm
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 :

Code
-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 :
Code
-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 ??
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: thomas on May 08, 2009, 03:39:14 pm
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: drac on May 08, 2009, 03:45:21 pm
Quote
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

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)

Code
#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!
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: killerbot on May 08, 2009, 04:07:53 pm
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 ??
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on May 08, 2009, 10:26:59 pm
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).
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: sahasranaman on June 12, 2009, 04:31:02 pm
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?

Code
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
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on June 12, 2009, 04:40:49 pm
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: sahasranaman on June 13, 2009, 09:20:12 am
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.

Code
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
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on June 13, 2009, 09:29:54 pm
Post the output after adding "-v" to the link command for libsigc-2.0.dll.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on June 24, 2009, 04:51:37 pm
Hi, I found a problem that I can't set breakpoint in a inline function.

For example: I have three files:

main.cpp

Code
#include <iostream>
using namespace std;
#include "a.h"
int main()
{
   f1();
    return 0;
}

a.cpp
Code
#include "a.h"
void f2(){
    f1();
}

a.h
Code
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


Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on June 25, 2009, 04:42:16 am
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??
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Ceniza on June 25, 2009, 07:35:02 am
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on June 25, 2009, 07:51:54 am
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
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Ceniza on June 25, 2009, 08:03:46 am
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>
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on June 25, 2009, 08:13:11 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:

Edit2
nm -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
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: 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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on June 25, 2009, 04:00:16 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
Code

__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
Code
#include <iostream>

using namespace std;

#include "a.h"

int main()
{
   TestClass a;
   a.func_inline();
    return 0;
}


a.cpp
Code
#include "a.h"
void f2(){
    TestClass b;
    b.func_inline();
}


a.h
Code
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:
Code
> 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
Code
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

Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: ollydbg on June 25, 2009, 04:52:13 pm
Hi.
I searched on Google, but finally return to CB forum again. I find one solution that in this post by Jens.

http://forums.codeblocks.org/index.php/topic,9295.msg66259.html#msg66259

Code
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

Edit2
If I use both -gstabs -gstabs+ , then the problem can totally be solved :D
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: yipinx on July 02, 2009, 09:47:46 pm
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)
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on July 04, 2009, 06:04:31 pm
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: nenin on July 14, 2009, 06:05:14 pm
Hello!
I got odd message with GCC 4.4.0-tdm-1-dw2 after "Compile current file" in C::B
Code
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
op\op.exe should not be linked at all...  :shock:
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: TDragon on July 15, 2009, 01:32:23 am
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: nenin on July 15, 2009, 11:34:41 am
You are right, I found that by unclear reasons C::B uses full path for such files.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Justin Brimm on July 27, 2009, 10:10:06 am
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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Conan Kudo on August 21, 2009, 07:21:51 pm
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?
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: 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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: Conan Kudo on August 22, 2009, 10:51:17 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.
Title: Re: GCC 4.4.0-tdm-1 for MinGW (with installer)
Post by: billyonthemountain on September 27, 2009, 05:48:21 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...