Code::Blocks Forums
User forums => General (but related to Code::Blocks) => Topic started by: Ceniza on May 28, 2006, 06:47:04 am
-
For those interested in trying the latest release of GCC, I'll be providing a link to GCC 4.1.1 for MinGW in my signature in a few minutes.
GCC 4.1.0 was able to compile Code::Blocks but failed compiling wxWidgets. GCC 4.0.3 was able to compile wxWidgets but failed compiling Code::Blocks. I wonder how it'll be for GCC 4.1.1 (I'm gonna try soon) :)
That said, wait for the link :D
-
Too bad... this version failed to compile wxWidgets 2.6.3 :(
Anyway, the link is there if anyone feels like trying it.
-
Too bad... this version failed to compile wxWidgets 2.6.3 :(
Anyway, the link is there if anyone feels like trying it.
nice work, thank you!
-
thx.
Ceniza,
did you ever discuss this with the wx people ??
Cheers,
Lieven
-
Too bad... this version failed to compile wxWidgets 2.6.3 :(
Good work. Another GCC version to try out :D.
Did you try to compile C::B with it?
Best wishes,
Michael
-
did you ever discuss this with the wx people ??
Hello,
I have spoken a lot, but concerning GCC 4.1.0. There should be at least one thread in this forum.
To make it short :), I could compile wxWidgets (Patch 2), but not linking it :(.
Unfortunately, no solution until now (AFAIK).
Best wishes,
Michael
-
nice work, thank you!
np :)
did you ever discuss this with the wx people ??
Well, I'd say the real problem is GCC itself, but every single bug I've reported has been marked as duplicated :)
Did you try to compile C::B with it?
Nop. When I saw it failed compiling wx just like 4.1.0 did, I restored 3.4.5 immediately and went to sleep :)
-
Did you try to compile C::B with it?
Nop. When I saw it failed compiling wx just like 4.1.0 did, I restored 3.4.5 immediately and went to sleep :)
Ok :).
Personally, I use wxWidgets 2.6.3 (+Patch 2) built with GCC 4.0.3 for building C::B with GCC 4.1.0 (later with your newest GCC 4.1.1 version) :).
Best wishes,
Michael
-
GCC 4.1.1 - MINGW.7z is not supported archive. The same for all gcc versions from site. Windows xp sp2, 7-zip 4.42.
-
Some download managers seem to have problems getting files from there and they get corrupted. A way to check if your download is fine is to run md5sum on it (a quick search in Google for md5sum.exe should be enough to get it) and compare the hash value you get with that provided in the site (the .md5 file).
If the hash value is different then your file is corrupted, but if it's the same then your "unpacker" has problems.
-
Right, it was downloader problem. Thanks for help.
-
why do newer versions of gcc fail to compile lots of things anyway?
-
why do newer versions of gcc fail to compile lots of things anyway?
Well, the new versions of GCC include many changes and many new optimization features, and just as one would expect, such a big project with such big changes can lead to some evil bugs.
What's sad is the win32 port seems to be the most buggy one :(
-
why do newer versions of gcc fail to compile lots of things anyway?
Well, the new versions of GCC include many changes and many new optimization features, and just as one would expect, such a big project with such big changes can lead to some evil bugs.
What's sad is the win32 port seems to be the most buggy one :(
Thanks a lot for the compilation.
So far, works for me - fine.
I did compile fltk2 and gsl :-)
The only think is that the code is normally a bit ~30kb bigger that the code compiled with gcc (mingw) 3.4.5.
It would be very interest to see if the situation will change with compilation options a bit altered.
Could you please, before rebuilding gcc replace all "-g -o2" and "-o2" instances on "-Os -fno-exceptions -DHAVE_INLINE". This instructions known to drastically reduce size of executables (hence libraries).
-
so it's not that there has been a change in the way c++ works, it's that such a huge upgrade of something like a compiler is bound to cause bugs?
-
so it's not that there has been a change in the way c++ works, it's that such a huge upgrade of something like a compiler is bound to cause bugs?
exactly. as far as i know there aren't changes in the way c++ (or any language for that matter) for looong years. any project of great magnitude like a compiler is bound to have regressions and compatibility problems with the way thing were done before. that's why they release beta versions and make release candidates etc.
-
Just to add a little info:
GCC 4 optimizes MUCH better, than any 3.x version. I have written an image processing plugin for avisynth some time ago, and compiled with gcc 4 with -march=pentium3 -O3, it as about 2 times faster, than compiled with the EXACT same flags with gcc 3.4.5
I have also read about this, that gcc 4 uses much more modern and robust optimization techniques, and my results only confirm this.
Another thing:
Why is it needed to install gcc 4 to C:\MinGW? I tried in other directory, where I prefer, but there it cannot find it's own includes and libs. How come? Is C:\MinGW hard coded into g++.exe? (I hope not)
--
Greets,
B.
-
Another thing:
Why is it needed to install gcc 4 to C:\MinGW? I tried in other directory, where I prefer, but there it cannot find it's own includes and libs. How come? Is C:\MinGW hard coded into g++.exe? (I hope not)
--
Greets,
B.
No it is not hard coded. You just need to tell C::B where to look for GCC 4. :)
-
It seems the path for includes and libs gets hardcoded somewhere in the compilation process. I don't know the reason it happens but it does.
Checking g++.exe from GCC 4.1.1, there's a C:/MinGW hardcoded into it, and checking g++.exe from GCC 3.4.5 there's no path at all there, but just changing that won't fix it.
-
Another thing:
Why is it needed to install gcc 4 to C:\MinGW? I tried in other directory, where I prefer, but there it cannot find it's own includes and libs. How come? Is C:\MinGW hard coded into g++.exe? (I hope not)
--
Greets,
B.
No it is not hard coded. You just need to tell C::B where to look for GCC 4. :)
Hello,
Ceniza is right.
The first time I have tried GCC 4.1.0 in a MinGW not installed in C:\, I got several troubles to make it works with C::B. Since I installed MinGW in C:\ all works like a charm (no need for special tricks).
Best wishes,
Michael
-
Another thing:
Why is it needed to install gcc 4 to C:\MinGW? I tried in other directory, where I prefer, but there it cannot find it's own includes and libs. How come? Is C:\MinGW hard coded into g++.exe? (I hope not)
--
Greets,
B.
No it is not hard coded. You just need to tell C::B where to look for GCC 4. :)
Hello,
Ceniza is right.
The first time I have tried GCC 4.1.0 in a MinGW not installed in C:\, I got several troubles to make it works with C::B. Since I installed MinGW in C:\ all works like a charm (no need for special tricks).
Best wishes,
Michael
Well I stand corrected. :)
-
Is there any way to change the directory it is installed in? I use a couple of versions.
jmccay
-
That's the biggest mystery right now.
What I did was to create many bin directories, like bin-4.0.3 and bin-4.1.1, and rename them to just bin when I want to use that version.
-
Currently, on my winXP system, I am using System variables.
MINGW = %DEVHOME%\compilers\mingw%MINGWVER%
DEVHOME is the base development directories
MINGWVER is the mingw version like:
MINGWVER=3.4.5
under the path variable:
path =%MINGW%\bin
You have to exit cmd prompts & CB to get them to see the change, but it might be easier for some parts. The nice thing about this is I only have to change MINGWVER & exit out of cmd prompts & CB. I also use the system variables in the directory lists.
Him, has anyone mentioned this to the gcc people? It is definately an annoying bug. I hope it's fixed before 4.2 come out because that version should be able to compile wxWidgets without all the annoying warnings. A patch fixing was applied to that version.
jmccay
-
Ceniza, hasn't this been available since May? (Thanks, by the way.)
-
Hmmm... yes, it's been available since May, 4 days after the official release, but I don't get the reason for that question :?
Now, about the path thingy, I haven't reported it, but there must be a way around since the MinGW people get it to work correctly, and the solution could be somewhere in their site :)
-
Oh, never mind. I thought this was a new thread, and that you were only just announcing GCC 4.1.1 for Windows now.