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.
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. :)
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00963.html
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.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.
...
Did you ever face such issue?
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.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.
...
Did you ever face such issue?
Once this new 4.1.2 build is finished, I think I'll try building and running 3.4.6 and see what happens.
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.)
http://www.fileden.com/files/4628/GCC-3.4.6.7z
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).
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".)
//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++.
#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;
}
Anyways...if it's this easy to build gcc (not very easy to figure out though ;) ) why doesn't GNU make official windows binaries?
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?
64-bit mode not compiled inThe 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.
After installation I got errors with GDB likeAs I have not encountered errors like this, could you provide a minimal sample case with instructions on how to reproduce it?
Application popup: gdb.exe - No Disk : There is no disk in the drive. Please insert a disk into drive \Device\Harddisk4\DR6.
Absolutely nothing special in project. It compliled/debuged fine with 4.1.1 and 3.4.*After installation I got errors with GDB likeAs I have not encountered errors like this, could you provide a minimal sample case with instructions on how to reproduce it?
Application popup: gdb.exe - No Disk : There is no disk in the drive. Please insert a disk into drive \Device\Harddisk4\DR6.
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.
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.I`m afraid you are right. I probably must reinstall windows. I can not find any traces of \Device\Harddisk4\DR6 in registry. :(
And I have a multy-card-reader with 4 letters.
I`m afraid you are right. I probably must reinstall windows. I can not find any traces of \Device\Harddisk4\DR6 in registry.
Strange bug!!! How the gcc can be connected to the card reader :shock:
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.
Has this bug been reported to the gcc team?I believe it would be better to report it to the GDB team.
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.
<****>It is not presented in Ceniza gcc 4.* builds. Source of the bug is unclear.
I believe it would be better to report it to the GDB team.
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. :(
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.
Not a pertinent option for those packages; they have nothing to do with std::string objects.
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.
I think I would find what the mistake I made. :oThat 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 used the official prebuilt SDK and it could be compiled by gcc3.4.5.
I think I would find what the mistake I made. :oThe problem seems to be, that the prebuilt SDK uses DWARF2 exception handling
I used the official prebuilt SDK and it could be compiled by gcc3.4.5.
I really feel embarrassed. :?
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.
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.. :(.
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.. :(.
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?
Of course mostly speed is more important than executable-size, so I also prefer using gcc-4.1.2 now.
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 :)
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.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?
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.
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).