-------------- Build: Win32 DLL Release in isosurf ---------------
windres.exe -i F:\SOURCE~1\Projects\WXWIDG~1\WXWIDG~1.X\samples\sample.rc -J rc -o gcc_mswudll\isosurf\samples\sample.res -O coff -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\lib\gcc_dll_multi_26\mswu -I.\..\..\..\include -I. -I.\..\..\..\samples -IC:\Apps\MinGW_GCC_tdm_423\include -IF:\SOURCE~1\Projects\WXWIDG~1\WXWIDG~1.X\samples -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x
g++.exe -g -O2 -Wall -DWIN32 -D__WXMSW__ -D_UNICODE -DWXUSINGDLL -D_WINDOWS -DNOPCH -fno-strict-aliasing -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\lib\gcc_dll_multi_26\mswu -I.\..\..\..\include -I. -I.\..\..\..\samples -IC:\Apps\MinGW_GCC_tdm_423\include -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\samples\opengl\isosurf -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x -c F:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\samples\opengl\isosurf\isosurf.cpp -o gcc_mswudll\isosurf\isosurf.o
In file included from c:/apps/mingw_gcc_tdm_423/bin/../lib/gcc/mingw32/4.2.3/../../../../include/c++/4.2.3/istream:845,
from c:/apps/mingw_gcc_tdm_423/bin/../lib/gcc/mingw32/4.2.3/../../../../include/c++/4.2.3/fstream:45,
from F:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\samples\opengl\isosurf\isosurf.cpp:50:
c:/apps/mingw_gcc_tdm_423/bin/../lib/gcc/mingw32/4.2.3/../../../../include/c++/4.2.3/bits/istream.tcc:46:18: error: F:/SourceCode/Projects/wxWidgets/wxWidgets-2.9.x/locale: Permission denied
Process terminated with status 1 (0 minutes, 4 seconds)
1 errors, 0 warnings
With GCC 4.2.3 now released, I've created the usual TDM binary distribution for MinGW. As always, binary packages are available as drop-in replacements for the MinGW project's official gcc packages.Why while compiling an OpenMP program with your GCC distribution... it seems to recognize only one core?
I haven't deviated from my standard build process in creating this release, so I don't expect any problems. I always test every release to ensure that it can successfully build the latest version of wxWidgets and Code::Blocks SVN -- however, I haven't yet done so for this release because the majority of my CPU is currently occupied in a different build process. As soon as that's finished, I'll finish testing and confirm that everything works as expected.
Update:
Yes, C::B SVN and wxWidgets work fine with this release.
Full details are at http://www.tdragon.net/recentgcc/ .
Disclaimer:
You should only use this build if you need the features or bugfixes done since GCC 4.2.1. If you don't need them or aren't sure, you should instead use the official MinGW GCC 4.2.1 Technology Preview, or (most preferably) the official MinGW GCC 3.4.5 stable release.
Cheers,
John E. / TDM
By the way, TD... I tried your 4.3.0 build too, very much appreciated (because I'm too stupid to build myself, for some reason it never works).Yeah...let's just say that while the process is indeed as simple as "configure, make, install", when things go wrong it's confoundedly hard to figure out why. Apparently, buying your sacrificial chickens from the correct vendor plays an important role.
Unluckily, it seems like the GCC team still has to do some serious overhauling on the optimizer before 4.3.0 becomes usable. I had it move code which wasn't invariant and which was marked __volatile__ out of a loop. To make matters worse, the exit condition depended on that code (resulting in an infinite loop). So basically, that makes 4.3.0 unusable.Wow. Thanks for pointing this out. I've finally finished porting the patchset from the official MinGW 4.2.1 release to the 4.3 series for a soon-to-be TDM release with shared libgcc&libstdc++ and DW2 unwinding; now it looks like it might be a good idea to apply it to another 4.2 release as well.
I also tried your 4.3.0 release and it complains about CreateProcess not being found whenever I try to build a program. Mr. Thomas told me to rename it, but it didn't work. More or less like Mr. T, I'm too stupid to make it work.If you can post the output with -v added to the command line here or in a support request (http://sourceforge.net/tracker/?func=add&group_id=200665&atid=974440), I can try to troubleshoot for you and add pertinent info to the README so other people don't run into the same problem. Also, it may well be a bug.
Why while compiling an OpenMP program with your GCC distribution... it seems to recognize only one core?I only have a single-core CPU currently, so this one would be harder for me to troubleshoot. I recommend you try your program on the official MinGW GCC 4.2.1 release. If it works as you expect there but not in TDM-GCC, I can try comparing the two to see what changes to make.
(The program that i tested works fine on Linux and used flag -fopenmp)
thomas:By the way, TD... I tried your 4.3.0 build too, very much appreciated (because I'm too stupid to build myself, for some reason it never works).Yeah...let's just say that while the process is indeed as simple as "configure, make, install", when things go wrong it's confoundedly hard to figure out why. Apparently, buying your sacrificial chickens from the correct vendor plays an important role.
Why while compiling an OpenMP program with your GCC distribution... it seems to recognize only one core?
(The program that i tested works fine on Linux and used flag -fopenmp)
set OMP_NUM_THREADS=2
export OMP_NUM_THREADS=2
omp_set_num_threads(2);
Did you try specifying the number of threads before running your app?? On Windows, export the following environment variable as-Codeor in Linux,set OMP_NUM_THREADS=2
Codeexport OMP_NUM_THREADS=2
You can also add the following code at the top of your main() function in your code to set the number of threads.Codeomp_set_num_threads(2);
Please note that the above code has higher precedence than the environment variables.
#include <omp.h>
#include <stdio.h>
int main () {
int id;
omp_set_num_threads(3);
#pragma omp parallel private(id)
{
id = omp_get_thread_num();
printf("Threads i have set: %d\n", id );
#pragma omp barrier
}
printf("Real cores %d\n", omp_get_num_procs());
getchar();
return 0;
}
Okay but why you still have it classified as Recommended Download when in fact it is not usable at the moment? I'm, really thankful for your work in general but this upset me, because i spent a lot of time installing this new release and trying fruitlessly to get Qt 4.4 to build. :?
A parting shot:
You may have noticed that I haven't posted my typical announcement here concerning the TDM 4.3.0 release. This is because 4.3.0 currently does not successfully build Code::Blocks. I have not yet looked into the source of the problem.
Okay but why you still have it classified as Recommended Download when in fact it is not usable at the moment? I'm, really thankful for your work in general but this upset me, because i spent a lot of time installing this new release and trying fruitlessly to get Qt 4.4 to build. :?
A parting shot:
You may have noticed that I haven't posted my typical announcement here concerning the TDM 4.3.0 release. This is because 4.3.0 currently does not successfully build Code::Blocks. I have not yet looked into the source of the problem.
Question: Has anyone had experience with the new official mingw gcc4.3?
Okay but why you still have it classified as Recommended Download when in fact it is not usable at the moment? I'm, really thankful for your work in general but this upset me, because i spent a lot of time installing this new release and trying fruitlessly to get Qt 4.4 to build. :?Well, maybe it's called "recommended" because TDragon offers like 200 different releases, and this one is the most recent one with the most bugfixes? Besides, why is it automatically "useless" only because it doesn't build Code::Blocks?
Question: Has anyone had experience with the new official mingw gcc4.3?
I know that it's alpha, but what else can you say about it? Have u actually used it?
But since u have no experience with TDMs 4.3 release I consider your topic closed.