Code::Blocks

User forums => General (but related to Code::Blocks) => Topic started by: TDragon on February 26, 2007, 03:20:04 am

Title: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on February 26, 2007, 03:20:04 am
With many thanks to wxLearner for the tip, a new, fully relocatable build is available directly from my site (removed due to excessive bandwidth usage) or hosted at filefront.com (http://hosted.filefront.com/tldragon7/). (gcc-4.1.2-c+cxx-mingw-tdm-r1.7z: 7-zip archive, 9.39 MB). For more details, see this post (http://forums.codeblocks.org/index.php/topic,5282.msg41161.html#msg41161).

As an extra tidbit, I have succesfully used this 7-zip archive, along with the MinGW components listed below, to install GCC 4.2.1 and successfully build and run Code::Blocks with it on two other machines, one running XP Pro SP2 and one running Win2k.



GCC 4.1.2 was officially released Feb. 13th. I was able to successfully build it in and for a Windows environment with both MinGW's GCC 3.4.5 distribution and my own previous GCC 4.1.1 build (with MinGW's binutils, mingw32-make, etc.).

You can download my build of GCC 4.1.2 for MinGW here (direct link to the file from my website removed due to excessive bandwidth usage) or here (http://hosted.filefront.com/tldragon7/) (hosted at filefront.com). (gcc-4.1.2-c+cxx-mingw-tdm-r1.7z: 7-zip archive, 9.39 MB). Disclaimer on behalf of MinGW: This build is not in any way endorsed by or affiliated with the MinGW project, so don't go asking the MinGW devs for help with problems when using this build.

It's compiled with support for C and C++ only, and was configured with the "--enable-fully-dynamic-string" option, which turns off a certain optimization for static std::string objects and which the developers of the Ogre engine have found necessary to correctly build and use Ogre as DLLs with MinGW/GCC.

In order to use this build with Code::Blocks, I recommend extracting it to an empty directory along with the contents of binutils-2.17.50-20060824-1.tar.gz (http://downloads.sourceforge.net/mingw/binutils-2.17.50-20060824-1.tar.gz?modtime=1156937419&big_mirror=1), mingw32-make-3.81-1.tar.gz (http://downloads.sourceforge.net/mingw/mingw32-make-3.81-1.tar.gz?modtime=1150823860&big_mirror=1), mingw-runtime-3.11.tar.gz (http://downloads.sourceforge.net/mingw/mingw-runtime-3.11.tar.gz?modtime=1163875480&big_mirror=1), and w32api-3.7.tar.gz (http://downloads.sourceforge.net/mingw/w32api-3.7.tar.gz?modtime=1145039963&big_mirror=1), and then installing gdb-6.3-2.exe (http://downloads.sourceforge.net/mingw/gdb-6.3-2.exe?modtime=1133217999&big_mirror=1) to that directory.

Hints for creating a relocatable build came from this mailing list message (http://lists.puremagic.com/pipermail/d.gnu/2006-December/000594.html), although I encountered a few additional necessary steps not mentioned there. In particular, using a nonexistent path as the prefix failed; the installation required various MinGW components to already be present in the installation directory. (See the steps in bold in my build process below.)

This build includes the patch for GCC 4.1 branch attached to this GCC bug report (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067), which fixes the problem building wxWidgets' Media library with GCC 4. I would still recommend that you move your old MinGW installation to another folder rather than deleting it entirely, in case you encounter an error you can't fix in some other code. Final note about wxWidgets and GCC 4: the wxWidgets headers will introduce a ton of "type attributes are honored only at type definition" warnings; I recommend adding the GCC option "-Wno-attributes" to your wxWidgets project's build options to turn these warnings off.

Here is my almost completely unempirical comparison of the official MinGW GCC 3.4.5 and my GCC 4.1.2.
Host machine: Win XP with SP2, Athlon 64 3500+ CPU @ 2.2GHz, 768 MB DDR-400 RAM, 160 GB SATA/150 hard drive

Time to rebuild All in CodeBlocks.cbp:
GCC 4.1.2 -- 5 minutes, 54 seconds (-Wno-attributes added to the compiler options)
GCC 3.4.5 -- 6 minutes, 7 seconds
Final call: Far too close to make any difference.

Final size of codeblocks.exe (with -g and cbDEBUG, no optimization), in "devel" dir
GCC 4.1.2 -- 10.2 MB
GCC 3.4.5 -- 7.81 MB
Final call: A fairly noticeable difference. Does GCC 4 include more debugging info?

Final size of codeblocks.exe (-g and cbDEBUG removed from build options; -s and -O2 added), in "output" dir after running update.bat:
GCC 4.1.2 -- 1.44 MB
GCC 3.4.5 -- 1.12 MB
Final call: 3.4.5 saves a small amount on size, but I would imagine 4.1.2 includes some further speed optimizations.

I don't yet have a good way of comparing speed optimizations and such in other compiled executables, but high-performance games or apps with heavy math will probably see some performance improvement. GUI apps such as Code::Blocks won't have a noticeable gain.
Final call: Only upgrade if you know your codebase would benefit from additional compiler optimization, or if you want to ensure that it can be compiled with later versions of GCC.

For those interested, my build process:
1. Download and extract gcc-core-4.1.2.tar.gz (http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-core-4.1.2.tar.bz2) and gcc-g++-4.1.2.tar.gz (http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-g++-4.1.2.tar.bz2) (creates directory "gcc-4.1.2")
2. Download this patch (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12610&action=diff&context=patch&collapsed=&headers=1&format=raw) and save in the same parent directory (we'll call it <gccbuildpath>)
3. Open mSYS
4. $ cd <gccbuildpath>/gcc-4.1.2
5. $ patch -b -p0 -i ../bug27067.patch
6. Exit mSYS
7. Create directory "gcc-4.1.2-obj" next to "gcc-4.1.2"
8. Ensure that C:\MinGW contains a full MinGW installation with GCC 3.4.5
9. Open <pathtomsys>\etc\fstab and make sure entry "c:/MinGW /mingw" exists
10. Open mSYS
11. $ cd <gccbuildpath>/gcc-4.1.2-obj
12. $ ../gcc-4.1.2/configure --with-gcc --with-gnu-ld --with-gnu-as --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --enable-fully-dynamic-string
13. $ make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s bootstrap 2>errlog.txt
14. Wait a few minutes. Make a pot of coffee.
15. make fails at step "Bootstrapping the compiler"; check errlog.txt to find error: Makefile:1280: *** target pattern contains no `%'.
16. Open <gccbuildpath>\gcc-4.1.2-obj\gcc\Makefile, go to line 1280, see that error is referring to $(ORIGINAL_LD_FOR_TARGET). Find definition of ORIGINAL_LD_FOR_TARGET (line 359), see that it's incorrectly set as "./c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/ld.exe". Change to the saner "/mingw/bin/ld" (following the pattern of ORIGINAL_NM_FOR_TARGET right below it, which is correctly set). Save Makefile.
17. Return to mSYS window, repeat previous make command (make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s bootstrap 2>errlog2.txt)
18. Wait a lot of minutes. Prepare and consume a 5-course dinner.
19. Rename C:\MinGW as C:\MinGW-old
20. Create new C:\MinGW and extract contents of binutils-2.17.50-20060804-1.tar.gz, mingw32-make-3.81-1.tar.gz, mingw-runtime-3.11.tar.gz, and w32api-3.7.tar.gz there.
21. $ make install


At this point, C:\MinGW now contains nearly an entire MinGW installation. This is fine for people who don't want to distribute it; I had to use diff to determine the new and changed files (comparing against a copy of the contents of C:\MinGW before running make install) and separate them out by hand. There's probably a faster way of doing it.

22. Copy i686-pc-mingw32-gcc.exe to mingw32-gcc.exe and i686-pc-mingw32-g++.exe to mingw32-g++.exe (for easy compatibility)
Title: Re: GCC 4.1.2 available
Post by: stahta01 on February 26, 2007, 03:35:40 am
Thanks for the link to your build and even more thanks for the directions on compiling GCC for minGW.
Tim S
Title: Re: GCC 4.1.2 available
Post by: Grom on February 26, 2007, 04:21:17 am
Is that possible to build gcc somehow with enabled cpu instruction (i686) and full optimization to save compilation time of the finall version?
Title: Re: GCC 4.1.2 available
Post by: TDragon on February 26, 2007, 04:45:59 am
Is that possible to build gcc somehow with enabled cpu instruction (i686) and full optimization to save compilation time of the finall version?
Quite simply: add -mtune=i686 (or -march=i686) and whatever other flags you'd like into CFLAGS and CXXFLAGS in the make command. Given the nature of the beast, however, I doubt enabling whatever additional instructions are available in i686, such as MMX, would make any measurable difference in execution speed, or even any difference at all. The optimizations that I've enabled with -O2 usually give the best results without eating up inordinate amounts of memory.
Title: Re: GCC 4.1.2 available
Post by: Grom on February 27, 2007, 03:06:19 am
On my computational algorithms -03 gives a lot
Title: Re: GCC 4.1.2 available
Post by: wxLearner on February 27, 2007, 02:18:56 pm
Thank you very much for this!
Concerning the hardwired search paths, I've found an interesting mailing list entry (http://lists.puremagic.com/pipermail/d.gnu/2006-December/000594.html). It's about compiling gdc, but I think it describes the trick to make gcc relocatable in general. I didn't try it yet, but I will do it with your gcc-4.1.2 version :)
Title: Re: GCC 4.1.2 available
Post by: TDragon on February 27, 2007, 03:03:09 pm
Concerning the hardwired search paths, I've found an interesting mailing list entry (http://lists.puremagic.com/pipermail/d.gnu/2006-December/000594.html). It's about compiling gdc, but I think it describes the trick to make gcc relocatable in general.
Nice spotting! Rebuilding now. :)
Title: Re: GCC 4.1.2 available
Post by: Biplab on February 27, 2007, 03:22:04 pm
@TDragon,

I compiled GCC-3.4.6 couple of times. It compiles applications. But there is a Problem. If I want to compile C::B, while compiling PCH it says something like "Can't open <Temp_dir>\<random_name>.s" and stops the compilation.

I did some search and got the closest match in following thread. Though it's about GCC+CygWin but the problem was similar.
Quote
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00963.html

I've never tested above solution.

My question is-
* Did you ever face such issue? If yes, please suggest me any solution.

Thanks & Regards,

Biplab
Title: Re: GCC 4.1.2 available
Post by: TDragon on February 27, 2007, 03:36:06 pm
I compiled GCC-3.4.6 couple of times. It compiles applications. But there is a Problem. If I want to compile C::B, while compiling PCH it says something like "Can't open <Temp_dir>\<random_name>.s" and stops the compilation.
...
Did you ever face such issue?
No, I haven't -- but I've never tried to use GCC 3.4.6 before. Looking over that mailing list message, I don't actually see anything to suggest that it has anything to do with your problem, either.

Once this new 4.1.2 build is finished, I think I'll try building and running 3.4.6 and see what happens.
Title: Re: GCC 4.1.2 available
Post by: Biplab on February 27, 2007, 03:44:57 pm
I compiled GCC-3.4.6 couple of times. It compiles applications. But there is a Problem. If I want to compile C::B, while compiling PCH it says something like "Can't open <Temp_dir>\<random_name>.s" and stops the compilation.
...
Did you ever face such issue?
No, I haven't -- but I've never tried to use GCC 3.4.6 before. Looking over that mailing list message, I don't actually see anything to suggest that it has anything to do with your problem, either.

Once this new 4.1.2 build is finished, I think I'll try building and running 3.4.6 and see what happens.

Thanks for your reply. I forgot the exact error.  :)

I'll post it later. Shall I upload the binary (Compiled GCC) for you to some location? :)

Thanks & Regards,

Biplab
Title: Re: GCC 4.1.2 available
Post by: TDragon on February 27, 2007, 04:07:59 pm
Shall I upload the binary (Compiled GCC) for you to some location?
Sure -- then I can test it to make sure the issue's not just specific to your machine. I'm sure you already know this: what I would want is the contents of "blah" from the "make DESTDIR=blah install" command. (I don't need any of the MinGW components.)
Title: Re: GCC 4.1.2 available
Post by: Biplab on February 27, 2007, 04:35:37 pm
Please download the file from the following link.

Quote
http://www.fileden.com/files/4628/GCC-3.4.6.7z

AFAIR, the build was configured with ../configure --prefix=/c/temp/gcc-3.4.6 ....

The archive has GCC, G++ and GOBJC.

Thanks & Regards,

Biplab
Title: Re: GCC 4.1.2 available
Post by: TDragon on February 27, 2007, 05:56:49 pm
With many thanks to wxLearner for the tip, a new, fully relocatable build is available directly from my site (removed due to excessive bandwidth usage) or hosted at filefront.com (http://hosted.filefront.com/tldragon7/). (gcc-4.1.2-c+cxx-mingw-tdm-r1.7z: 7-zip archive, 9.39 MB)

As an extra tidbit, I have succesfully used this 7-zip archive, along with the MinGW components listed below, to install GCC 4.2.1 and successfully build and run Code::Blocks with it on two other machines, one running XP Pro SP2 and one running Win2k.

Hints for creating a relocatable build came from this mailing list message (http://lists.puremagic.com/pipermail/d.gnu/2006-December/000594.html), although I encountered a few additional necessary steps not mentioned there. In particular, using a nonexistent path as the prefix failed; the installation required various MinGW components to already be present in the installation directory.
Following is the full set of steps I took: (changes marked in bold)
1. Download and extract gcc-core-4.1.2.tar.gz (http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-core-4.1.2.tar.bz2) and gcc-g++-4.1.2.tar.gz (http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-g++-4.1.2.tar.bz2) (creates directory "gcc-4.1.2")
2. Download this patch (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12610&action=diff&context=patch&collapsed=&headers=1&format=raw) and save in the same parent directory (we'll call it <gccbuildpath>)
3. Open mSYS
4. $ cd <gccbuildpath>/gcc-4.1.2
5. $ patch -b -p0 -i ../bug27067.patch
6. Exit mSYS
7. Create directory "gcc-4.1.2-obj" next to "gcc-4.1.2"
8. Ensure that C:\MinGW contains a full MinGW installation with GCC 3.4.5
9. Open <pathtomsys>\etc\fstab and make sure entry "c:/MinGW /mingw" exists
10. Open mSYS
11. $ cd <gccbuildpath>/gcc-4.1.2-obj
12. $ ../gcc-4.1.2/configure --with-gcc --with-gnu-ld --with-gnu-as --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --enable-fully-dynamic-string
13. $ make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s bootstrap 2>errlog.txt
14. Wait a few minutes. Make a pot of coffee.
15. make fails at step "Bootstrapping the compiler"; check errlog.txt to find error: Makefile:1280: *** target pattern contains no `%'.
16. Open <gccbuildpath>\gcc-4.1.2-obj\gcc\Makefile, go to line 1280, see that error is referring to $(ORIGINAL_LD_FOR_TARGET). Find definition of ORIGINAL_LD_FOR_TARGET (line 359), see that it's incorrectly set as "./c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/ld.exe". Change to the saner "/mingw/bin/ld" (following the pattern of ORIGINAL_NM_FOR_TARGET right below it, which is correctly set). Save Makefile.
17. Return to mSYS window, repeat previous make command (make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s bootstrap 2>errlog2.txt)
18. Wait a lot of minutes. Prepare and consume a 5-course dinner.
19. Rename C:\MinGW as C:\MinGW-old
20. Create new C:\MinGW and extract contents of binutils-2.17.50-20060804-1.tar.gz, mingw32-make-3.81-1.tar.gz, mingw-runtime-3.11.tar.gz, and w32api-3.7.tar.gz there.
21. $ make install


At this point, C:\MinGW now contains nearly an entire MinGW installation. This is fine for people who don't want to distribute it; I had to use diff to determine the new and changed files (comparing against a copy of the contents of C:\MinGW before running make install) and separate them out by hand. There's probably a faster way of doing it.

22. Copy i686-pc-mingw32-gcc.exe to mingw32-gcc.exe and i686-pc-mingw32-g++.exe to mingw32-g++.exe (for easy compatibility)
Title: Re: GCC 4.1.2 available
Post by: Grom on February 27, 2007, 05:58:11 pm
The compilation with 4.1.2 gave me  undefined reference to `__cpu_features_init'
:: === Build finished: 1 errors, 0 warnings ===
 :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry:
Title: Re: GCC 4.1.2 available
Post by: TDragon on February 27, 2007, 06:01:10 pm
The compilation with 4.1.2 gave me  undefined reference to `__cpu_features_init'
Please describe how you installed 4.1.2 and give your project's full command line log (enabled from Settings->Compiler and debugger->Other settings->Compiler logging->Full command line).
Title: Re: GCC 4.1.2 available
Post by: Biplab on February 27, 2007, 06:13:14 pm
If you don't mind, what is the difference between this build and the earlier one. :?
Title: Re: GCC 4.1.2 available
Post by: TDragon on February 27, 2007, 06:25:48 pm
If you don't mind, what is the difference between this build and the earlier one.
It may be installed anywhere (not restricted to C:\MinGW), without needing to add the additional directories I'd mentioned previously to Code::Blocks' compiler search paths. (Note: I haven't yet tried installing it in a path with spaces, such as "Program Files".)
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: Biplab on February 27, 2007, 06:43:00 pm
Understood..  :)
Title: GCC 4.1.2 available (now relocatable!)
Post by: kylove on February 28, 2007, 02:04:44 pm
GCC 4.1.2 Bug

//code
#include <iostream>
using namespace std;

int main()
{
   long double pi=3.141592653589793;
   cout<<"pi=="<<pi<<endl;
   return 0;
}

//Run
pi==-8.87961e+043

//Why?
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on February 28, 2007, 04:33:26 pm
//Why?
After some poking around, I can only say I don't know. Something I find interesting is that GCC 3.4.5's std::cout performs as expected, but its printf() exhibits the same behavior as 4.1.2's cout (and printf). This points to changes in libstdc++.

The problem is only with the output's formatting, as the following program works as expected:
Code: [Select]
#include <iostream>
int main()
{
    long double pi = 3.141592653589793L;
    int add;
    std::cin >> add;
    std::cout << "add: " << add << "\npi + add: " << (double)(pi + add) << std::endl;
    return 0;
}
Note the cast to double -- cout appears to correctly interpret doubles. I believe this program proves that the long double's internal representation is correct.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: runtime on March 01, 2007, 01:20:01 am
tsk tsk tsk C style casts  :P

Anyways...if it's this easy to build gcc (not very easy to figure out though ;) ) why doesn't GNU make official windows binaries?

Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: Ceniza on March 01, 2007, 01:24:30 am
I remember seeing that problem before, but I can't remember the gcc version neither if it was printf or cout. The explanation I got was that gcc had problems displaying and, IIRC, operating on 80-bit float numbers (long double). Maybe that's the reason Digital Mars likes to say their C++ compiler is able to work with 80-bit floats without any problems.
I just tried that with GCC 4.1.2 on Linux, using both cout and printf. It had no problems displaying the right value of pi, so I guess it's a Windows only problem.

Anyways...if it's this easy to build gcc (not very easy to figure out though ;) ) why doesn't GNU make official windows binaries?

GNU doesn't even make Linux binaries, they only provide the source, it's up to you, the OS distribution or someone else to build it.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: stahta01 on March 01, 2007, 01:26:48 am
tsk tsk tsk C style casts  :P

Anyways...if it's this easy to build gcc (not very easy to figure out though ;) ) why doesn't GNU make official windows binaries?



One, GNU does NOT normally offer binary for Windows at all.
Two, MinGW who does is waiting for all of the GCC front-ends the MinGW supports to work to an acceptable level.
MinGW says only the C front-end works at an acceptable level for them.
And, MinGW says the Ada and Java front-ends are very broken.

Note, there are websites that offer Ada and Java front-ends for GCC 4.x that work under windows so take the reason with a grain of salt.

Tim S
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: runtime on March 01, 2007, 01:59:07 am
Well, someone should set up official binaries site...

But it's a heck of a lot easier to compile and all on Linux...you don't need binaries...

Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: kylove on March 02, 2007, 09:03:55 pm
Run Command:

gcc/g++ -m64 test64bit.cpp

Result:

test64bit.cpp:1: sorry, unimplemented: 64-bit mode not compiled in


Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 02, 2007, 09:55:20 pm
64-bit mode not compiled in
The error message is quite correct: 64-bit mode was indeed not compiled in. Although I'll continue looking into the possibilities of a GCC for Windows that can produce 64-bit executables, the fact of the matter is that there are a whole slew of accompanying utilities (binutils, glibc, and various other related binaries), normally provided by the MinGW developers, that I would apparently need to rebuild myself with 64-bit support.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: kylove on March 03, 2007, 12:31:57 am
64 bit, no one can be translated?
SOS!I will not!
Thanks!
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 06, 2007, 06:10:33 pm
After installation I got errors with GDB like
Application popup: gdb.exe - No Disk : There is no disk in the drive. Please insert a disk into drive \Device\Harddisk4\DR6. 
(from system log, gdb send a popup with similar content, approx. 10 times on each "run")
and then codeblocks often lost gdb in any moment. Any idea?
OS: Win2K SP4 codeblocks- last nightly, gdb- 6.3.2
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 06, 2007, 08:24:33 pm
After installation I got errors with GDB like
Application popup: gdb.exe - No Disk : There is no disk in the drive. Please insert a disk into drive \Device\Harddisk4\DR6. 
As I have not encountered errors like this, could you provide a minimal sample case with instructions on how to reproduce it?
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 07, 2007, 12:53:57 am
After installation I got errors with GDB like
Application popup: gdb.exe - No Disk : There is no disk in the drive. Please insert a disk into drive \Device\Harddisk4\DR6. 
As I have not encountered errors like this, could you provide a minimal sample case with instructions on how to reproduce it?
Absolutely nothing special in project. It compliled/debuged fine with 4.1.1 and 3.4.*
But: I replaced one harddrive and had to change letter for new one (so, I had a second pata hdd D: drive, now second hdd is sata U:). And I have a multy-card-reader with 4 letters.   
mingw is c:\wingw
codeblocks is on c:\bin\codeblocks
I made some tests exactly now: old code (from 4.1.1) are debuged normally. Issue is with debug version from 4.1.2
I attached some project, it is placed in c:\MinGW\projects\hello_tst\
Errors with lost connection gdb<-> codeblocks recovered by rollback to older svn.

[attachment deleted by admin]
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 07, 2007, 02:00:48 am
mingw is c:\wingw
codeblocks is on c:\bin\codeblocks
I made some tests exactly now: old code (from 4.1.1) are debuged normally. Issue is with debug version from 4.1.2
I attached some project, it is placed in c:\MinGW\projects\hello_tst\
Errors with lost connection gdb<-> codeblocks recovered by rollback to older svn.

Here are the steps I took to duplicate your setup as closely as possible:
1. Downloaded CB_20070305_rev3665_win32.7z (http://prdownload.berlios.de/codeblocks/CB_20070305_rev3665_win32.7z) (the latest nightly at the time of your post) and wxmsw26u_gcc_cb_wx2.6.3p2AndCbPatch_version3.7z (http://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2AndCbPatch_version3.7z) and extracted them to C:\bin\codeblocks
2. Created empty directory C:\mingw and extracted binutils-2.17.50-20060824-1.tar.gz, mingw32-make-3.81-1.tar.gz, mingw-runtime-3.11.tar.gz, w32api-3.7.tar.gz, and gdb-6.3-2.exe there
3. Removed references to my main MinGW installation from my PATH environment variable (as a result of which I also needed to copy mingwm10.dll to C:\bin\codeblocks)
4. Extracted "hello_tst.7z" to C:\hello_tst
5. Ran the newly installed nightly build
6. Went to Settings->Compiler and debugger, removed all paths in "Search directories" and changed "Compiler's installation directory" to "C:\mingw"
7. Opened C:\hello_tst\hello_tst.cbp (here I was informed that the project was in the older 1.5 format and would be upgraded to the 1.6 format)
8. Built the project with Ctrl+F9 (no errors, created hello_tst.exe)
9. Hit F8 to debug the program; no errors, exited normally with status code 0
As you can see, everything worked correctly for me.

Some thoughts:
- Using what was the latest nightly at the time of your post ("svn build  rev 3665 (2007-02-10 13:44:04)   gcc 3.4.5 Windows/unicode"), Code::Blocks informed me that your provided sample project's version was older than the current internal version, and updated it. Although I doubt this is the source of your problem, you should still try recreating your project from scratch, or at least saving it in the newer version.
- Did you overwrite any of the files from my GCC 4.1.2 with the files from the rest of the MinGW archives? If so, try re-extracting my .7z into your MinGW directory and overwriting files as necessary.
- Are all the paths and executables in C::B's compiler settings correct?
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 07, 2007, 04:04:07 pm
My projects are placed in
c:\mingw\projects\****
I reinstall everything (including last CB svn), gcc 4.1.2 was unpacked last (over refreshed GDB). Results are the same. I made a brand new project placed at c:\MinGW\projects\gdb_bugs01\*** (attached). I can not include binary- it is to big.
Problems with popup arises if I put a breackpoint before press F8. If there are no breakpoints, gdb running OK.


[attachment deleted by admin]
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 07, 2007, 04:31:23 pm
Problems with popup arises if I put a breackpoint before press F8. If there are no breakpoints, gdb running OK.
I'm still unable to reproduce this problem. Extracted gdb_bugs01.7z to C:\mingw\projects\gdb_bugs01, opened gdb_bugs01.cbp with C::B, hit Ctrl+F11 for a full rebuild, set a breakpoint at main.cpp:6, hit F8 to debug. Breakpoint was hit, everything worked as expected (I was able to step and continue), exited normally. This was all on my Win2k SP4 machine; I repeated the process on my WinXP SP2 machine and was still unable to reproduce the problem.

The message "Application popup: gdb.exe - No Disk : There is no disk in the drive. Please insert a disk into drive \Device\Harddisk4\DR6" seems to indicate that there is something unusual going on with your filesystem. Unfortunately I have no idea what it could be.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 07, 2007, 05:01:57 pm
Quote
The message "Application popup: gdb.exe - No Disk : There is no disk in the drive. Please insert a disk into drive \Device\Harddisk4\DR6" seems to indicate that there is something unusual going on with your filesystem. Unfortunately I have no idea what it could be.
I`m afraid you are right. I probably must reinstall windows. I can not find any traces of \Device\Harddisk4\DR6 in registry.  :(
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: mandrav on March 07, 2007, 05:18:25 pm
Quote from: nenin
And I have a multy-card-reader with 4 letters.   
Quote from: nenin
I`m afraid you are right. I probably must reinstall windows. I can not find any traces of \Device\Harddisk4\DR6 in registry.

I used to have similar behaviour with Gimp (http://www.gimp.org) on windows. As it turned out, it was a known problem. And I also had a multi-card reader installed at the time. Disabling that reader device solved everything.
That may spare you a windows re-install, maybe for nothing...
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 07, 2007, 05:26:40 pm
I count numbers- it may be one of the slots in card reader. But! It has 4 slots, one is used...  :x  And- no problems with gimp... but the same with incscape.  :(

Yesss! It works! I disabled unused slots in cardreader and it works just fine!
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: Grom on March 07, 2007, 08:00:53 pm
Strange bug!!! How the gcc can be connected to the card reader :shock:
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 07, 2007, 09:00:16 pm
I`m afraid in some very basic posix libraries exists something like "scan for drives" on initialization of the process.  In present case we have a stub, which works incorrectly. Because incscape has similar bug (but with only 3 popups- gdb makes about 10 on each run).
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: gmiranda on March 07, 2007, 09:12:16 pm
to sum up, could anyone explain the current state of gcc 4 for windows?
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 07, 2007, 09:15:05 pm
For me it is 95% satisfaction. 5% are some issues with gdb (inherrited from beginning). I used mingw gcc 4 since Ceniza 4.* builds. 
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: saddam le pion on March 07, 2007, 09:22:16 pm
Strange bug!!! How the gcc can be connected to the card reader :shock:

Has this bug been reported to the gcc team?
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 08, 2007, 01:21:43 am
to sum up, could anyone explain the current state of gcc 4 for windows?
The build I've provided may be used in exactly the same manner as the official MinGW GCC 3 builds. Bugs may exist in GCC 4 that did not exist in GCC 3, although there are certainly bugs that existed in GCC 3 that have been fixed in GCC 4.

MinGW does not distribute a build of GCC 4, and therefore your level of support in using it will be less.

MinGW's GCC 3 has, obviously, been used far more widely; therefore there will be some software designed to work "out-of-the-box" (no tampering required) with GCC 3 that will not do so with GCC 4. I have not discovered any such. Code::Blocks DOES compile out-of-the-box with GCC 4, and wxWidgets does as well with my build. The fact that as complex a program as C::B works without modification bodes well for GCC 4's compatibility with other code, as does the fact that object code produced by the 3.4 series can be linked with object code produced by the 4.0 and 4.1 series.

To sum up my summation, GCC 4 for Windows seems to be quite usable but not officially supported (except by me where possible); and even if you rely on a library that does not build with GCC 4, you can still build it with GCC 3 and link it with your own GCC 4 compiled code.

Has this bug been reported to the gcc team?
I believe it would be better to report it to the GDB team.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 08, 2007, 04:30:43 pm
To sum up my summation, GCC 4 for Windows seems to be quite usable but not officially supported (except by me where possible); and even if you rely on a library that does not build with GCC 4, you can still build it with GCC 3 and link it with your own GCC 4 compiled code.
Confirmed- I did it, all OK.
Quote
<****>
I believe it would be better to report it to the GDB team.
It is not presented in Ceniza gcc 4.* builds. Source of the bug is unclear.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: Grom on March 08, 2007, 06:21:37 pm
Looks like should be a new chapter in CB web cite - mingw-gcc. Where will be new compilations of gcc. Original one mingw seems to be was dead.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 09, 2007, 11:22:48 pm
Looks like should be a new chapter in CB web cite - mingw-gcc. Where will be new compilations of gcc. Original one mingw seems to be was dead.
It is not dead,  it is a little slow.  :(
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: courage on March 14, 2007, 02:19:43 pm
I try to build the samples of Ogre1.4 RC2, and it will throw a runtime error when starting to render graphics.
I think that maybe buinutils or mingw-runtime should be recompiled by configuring "--enable-fully-dynamic-string". :)
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 14, 2007, 02:28:39 pm
I think that maybe buinutils or mingw-runtime should be recompiled by configuring "--enable-fully-dynamic-string". :)
Not a pertinent option for those packages; they have nothing to do with std::string objects.

Actually, I've been reading a bit further on using Ogre with MinGW and have come across this post on the Ogre forums (http://www.ogre3d.org/phpBB2/viewtopic.php?t=28885), which suggests that GCC's exception handling can be another source of problems. Since I haven't actually built Ogre with GCC 4.1.2 (embarrassed cough), only 4.1.1, I will go ahead and do so and see if I can pin this error down.

Any details you can give me about your configuration, as well as the name of an Ogre sample which always throws the runtime error, would be appreciated as I work on this.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: courage on March 14, 2007, 03:28:22 pm
Not a pertinent option for those packages; they have nothing to do with std::string objects.

Sorry for my ignorance and thanks for your work.  :)

Since I haven't actually built Ogre with GCC 4.1.2 (embarrassed cough), only 4.1.1, I will go ahead and do so and see if I can pin this error down.

Please don't be embarrassed.
I am appreciated your work.  :)

Any details you can give me about your configuration, as well as the name of an Ogre sample which always throws the runtime error, would be appreciated as I work on this.

I think I would find what the mistake I made. :o
I used the official prebuilt SDK and it could be compiled by gcc3.4.5.
I really feel so embarrassed.  :?
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 14, 2007, 04:12:00 pm
I think I would find what the mistake I made. :o
I used the official prebuilt SDK and it could be compiled by gcc3.4.5.
That is likely the source of the problem, although I wish it wasn't. Ideally, you should be able to use your own 4.1.2-compiled programs with the 3.4.5-compiled SDK.

I'm going to continue research in this area with both Ogre's official prebuilt SDK and my own build from sources. Further updates as results warrant.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: wxLearner on March 14, 2007, 04:23:23 pm
I think I would find what the mistake I made. :o
I used the official prebuilt SDK and it could be compiled by gcc3.4.5.
I really feel embarrassed.  :?
The problem seems to be, that the prebuilt SDK uses DWARF2 exception handling, but the default is SJLJ.

On windows there can appear problems with the superior DW2 EH, if functions that throw DW2 exceptions are used as callbacks by non-DW2-enabled functions (like Win32 API). I've read about this here (http://www.cygwin.com/ml/cygwin/2006-03/msg00429.html). There is also information about the DW2 issue in this older thread (http://www.cygwin.com/ml/cygwin/2004-11/msg00962.html).

Edit:
Sorry, it looks like SJLJ isn't the default EH mechanism. I don't know.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: courage on March 14, 2007, 05:11:35 pm
After building Ogre1.4 RC2 by GCC4.1.2, the situation became worse.
When I used prebuilt SDK, it can showed the device configuration window of Ogre samples,
but now it just threw the runtime error and left the message in Build log below:
Process terminated with status 3 (0 minutes, 4 seconds)

I just used default configuration to build under release mode with Code::Blocks and
I had some problems when compiling debug mode.
Sorry that I can't provide any useful message.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: Grom on March 14, 2007, 06:53:36 pm
Would be grate to have a latest nightly build with installer, wxWidgets, and mingw-gcc 4.1.2. That will be really cool. Last time the installer was created in November with gcc 3.4.5 :|.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 14, 2007, 08:28:39 pm
Would be grate to have a latest nightly build with installer, wxWidgets, and mingw-gcc 4.1.2.
Including GCC 4.1.2 probably wouldn't be such a great idea to the Code::Blocks devs, who would start receiving requests for support on issues with software that has no official support. Even personally, I prefer to leave my 4.1.2 build as more of a "use at your own risk" upgrade, where it's clear that some things might break and that people who aren't willing and able to take an active role in bugfixing should stick with the more official 3.4.5 distribution.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: Grom on March 14, 2007, 09:46:54 pm
All "official" seems to be sleeping :lol:. The last one build was unofficial too :wink:.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 14, 2007, 10:13:57 pm
All "official" seems to be sleeping :lol:. The last one build was unofficial too :wink:.
I`m afraid I`m to old to wait for official builds. Life is so short.. :(.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: courage on March 15, 2007, 01:31:29 am
All "official" seems to be sleeping :lol:. The last one build was unofficial too :wink:.
I`m afraid I`m to old to wait for official builds. Life is so short.. :(.

Although I am a amateur programmer(end programmer),
but I think the nightly build is always stable enough for me. :)

I think official release is not very meaningful presently,
because every bug fixed nightly build could be a certain "official build".
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: Grom on March 15, 2007, 06:52:10 am
Yeee official release is not important.... Specially when there is a team and you not absolutely sure in what "night" they have been frozen. The answer was to use unofficial builds... :lol: I have bad stories to say about people from my team, they are buzzy with some work and didn't have a chance to seat on forum and look for stupid new versions.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: wxLearner on March 15, 2007, 10:12:57 am
After building Ogre1.4 RC2 by GCC4.1.2, the situation became worse.
When I used prebuilt SDK, it can showed the device configuration window of Ogre samples,
but now it just threw the runtime error and left the message in Build log below:
Process terminated with status 3 (0 minutes, 4 seconds)

I just used default configuration to build under release mode with Code::Blocks and
I had some problems when compiling debug mode.
Sorry that I can't provide any useful message.

Did you compile the dependencies yourself also? Once I encountered similar problems with the MinGW gcc-DW2-3.4.5 (http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82725&release_id=392771) and other libraries, that were precompiled with an other compiler, that didn't use DW2 EH. After compiling them all with DW2 EH, the problems were gone. One big advantage with DW2 was, that the binaries were much smaller. If you compile for example wxWidgets (monolithic-unicode-release-dll) with gcc-DW2-3.4.5 it's about 1MB smaller than with the usual gcc-3.4.5 release. Of course mostly speed is more important than executable-size, so I also prefer using gcc-4.1.2 now.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: courage on March 15, 2007, 02:54:23 pm
Did you compile the dependencies yourself also?

No, I afraid I don't have time to recompile these, I use the prebuilt dependencies libraries before.
Just like TDragon saying,
"Ideally, you should be able to use your own 4.1.2-compiled programs with the 3.4.5-compiled SDK.",
in my experience, I had used VisualC7 to compile codes and link libraries that Visual6 built,
and it works fine. I think this problem is strange.
Anyway, thanks for your suggestion. :)

Of course mostly speed is more important than executable-size, so I also prefer using gcc-4.1.2 now.

I also prefer better proformance. :)
Pardon me, did you build ogre with gcc4.1.2 and run samples successfully?
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: wxLearner on March 15, 2007, 03:58:54 pm
Pardon me, did you build ogre with gcc4.1.2 and run samples successfully?
No, I didn't build ogre yet. But I've built nearly all the dependencies with gcc-4.1.2, so I'll try soon :)
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nfz on March 15, 2007, 04:08:31 pm
gcc 4.1.x series is missing some MinGW patches that were applied to gcc 3.4.5.  One of the important patches not accepted into the gcc 4 tree is allowing sjlj exceptions to cross dll boundries.  So if you build Ogre from source with a MinGW build of gcc 4.1.x then as soon as Ogre or one of its dependencies dll raises an expection then the runtime will cause your program to terminate because the exception did not get handled inside the dll.  WIth Ogre 1.4 the most likely spot for the first exception is with OIS initialization when it doesn't find a joystick attached.  The demo code normally traps that exception and just continues on.  It can happen earlier depending on ogre configuration.  What I did was apply the missing patches to the 4.1 source to allow sjlj exceptions to cross the dll boundry.  Note that the patches don't apply cleanly to the 4.1 source so you do have todo some fiddlin to get it to work.  In the end I didn't find any performance benefits and builds were bigger.

Just to clear up the confusion: the Ogre 1.4RC2 SDK was built with gcc 3.4.5 using sjlj exception handling code.  Note that 3.4.5 sjlj exception handling was modified to allow exceptions to cross dll boundries.


You can mix some of the pre-built Ogre dependencies with code compiled with gcc 4.1 if the dependencies are just straight c.  But I found that if they are c++ then problems do occur.  I just rebuilt all the dependencies with 4.1.  Using the Ogre 1.4RC2 SDK with code compiled with gcc 4.1.2 will not work correctly due to the differences in how sjlj is being handled between code compiled with gcc 3.4.5 (the Ogre SDK) and code (your app) compiled with gcc 4.1.2.

I also built Ogre with gcc 4.2.0 using DWARF2 exception handling and yes the binaries are much smaller for both debug and release builds and execution speed is quite a bit better than 3.4.5 builds.  The Ogre demos showed between 10% to 30% speed improvement when using DWARF2 instead of sjlj.  As already mentioned there is a problem if you raise an exception inside a windows callback - a crash will occur.  The initial Ogre 1.4RC2 SDK was built with gcc 4.2.0 and the MinGW C++ Toolbox was going to be gcc 4.2.0 but I was still experiencing some strange behaviour in some of the demos and ran out of time to track down the source prior to release.  For now the Ogre SDK will be built with gcc 3.4.5 with the modified libstdc++ until myself and others find solutions to the 4.2 problems.



Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: TDragon on March 15, 2007, 05:01:54 pm
nfz: You've cleared a lot of things up with regard to Ogre and GCC for me at least; thanks.

gcc 4.1.x series is missing some MinGW patches that were applied to gcc 3.4.5.  One of the important patches not accepted into the gcc 4 tree is allowing sjlj exceptions to cross dll boundries.  So if you build Ogre from source with a MinGW build of gcc 4.1.x then as soon as Ogre or one of its dependencies dll raises an expection then the runtime will cause your program to terminate because the exception did not get handled inside the dll.  WIth Ogre 1.4 the most likely spot for the first exception is with OIS initialization when it doesn't find a joystick attached.  The demo code normally traps that exception and just continues on.  It can happen earlier depending on ogre configuration.  What I did was apply the missing patches to the 4.1 source to allow sjlj exceptions to cross the dll boundry.  Note that the patches don't apply cleanly to the 4.1 source so you do have todo some fiddlin to get it to work.  In the end I didn't find any performance benefits and builds were bigger.

Just to clear up the confusion: the Ogre 1.4RC2 SDK was built with gcc 3.4.5 using sjlj exception handling code.  Note that 3.4.5 sjlj exception handling was modified to allow exceptions to cross dll boundries.


You can mix some of the pre-built Ogre dependencies with code compiled with gcc 4.1 if the dependencies are just straight c.  But I found that if they are c++ then problems do occur.  I just rebuilt all the dependencies with 4.1.  Using the Ogre 1.4RC2 SDK with code compiled with gcc 4.1.2 will not work correctly due to the differences in how sjlj is being handled between code compiled with gcc 3.4.5 (the Ogre SDK) and code (your app) compiled with gcc 4.1.2.
Do you mean that the exceptions thrown from the (3.4.5+fully-dynamic-string) prebuilt Ogre SDK will not be caught only because GCC 4.1 series is missing the said patches from 3.4.5, or that there is some other unrelated incompatibility in the SJLJ exception backend between 3.4.5 and the 4.1 series? If only the former, then a build of GCC 4.1.2 using SJLJ exceptions and with these missing patches applied should in theory allow code compiled with it to correctly catch exceptions thrown from the prebuilt Ogre 1.4 SDK (3.4.5+fully-dynamic-string). Would you be able to provide a link to the mentioned patches to enable SJLJ exceptions across DLL boundaries?

Quote
The initial Ogre 1.4RC2 SDK was built with gcc 4.2.0 and the MinGW C++ Toolbox was going to be gcc 4.2.0 but I was still experiencing some strange behaviour in some of the demos and ran out of time to track down the source prior to release.  For now the Ogre SDK will be built with gcc 3.4.5 with the modified libstdc++ until myself and others find solutions to the 4.2 problems.
Even if you do get Ogre and GCC 4.2 working together, there is still a LOT of code "in the wild" that was written to work with MinGW's official GCC 3.4.5 and would have issues with the GCC 4 series. As far as I'm concerned, it's better to distribute and recommend a version that is as close to MinGW's 3.4.5 as possible (like you are right now), for those who don't want to have to concern themselves with inter-version incompatibilities such as we've been discussing. You might then provide something from the GCC 4 series as a sleeker alternative for those who don't need backwards-compatibility (or are good at porting).
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: nenin on March 16, 2007, 12:11:10 am
APROPOS, is it possible to use DWARF2 in mingw? I got messages like "Breakpoint pending"- and thats all.
Title: Re: GCC 4.1.2 available (now relocatable!)
Post by: stahta01 on March 19, 2007, 12:11:33 am
FYI:

Giovanni Bajo created installer for GCC 4.1.2

http://www.develer.com/oss/GccWinBinaries

Tim S