Hi, just letting you know that we have added support for building windows 64-bit builds with MinGW-w64. The build instructions are here:
support is still experimental, meaning you may experience bugs/crashes not present on MSVC. Or you may not it’s still fresh out of the oven as a build system. There are a few features not supported yet: OpenCollada, FFMPEG will not work. Also, there are many MinGW-w64 builds available. We can’t possibly maintain all of them but this one is known to work:
possibly others too, gcc 4.7 based. You should only report build failures for this system though.
For benchmark enthusiasts:
I have put up a build here:
Dobz has also uploaded a build
whoa this build doesn’t crash when adding empties.
This is excellent news! I’ve been using the build that was posted the other day, and am still blown away just how much faster it is.
Cool, i have tried both Builds,
on preliminary tests, i would recommend people use the Psy-Fi build
(it doesn’t have a “black mesh” viewport errors i was experiencing with the Dobz build)
I have by machine overclocked a little right now but render times between the two builds look comparable.
well… Psy-Fi build is a little faster
AMD 8120(3.1GHZ Default)
3.6GHZ(OC No Turbo)
3.6GHZ(OC No Turbo)
@holyenigma: could please make another test on a “standard” (Visual Studio-compiled) build?
Bat3a 45820(-Built with Scons & MSVisualC++ SP1 & CUDA 4.0)
Psy-Fi build is about 43% Faster than Standard MSVisual
Tomato Branch with Optimized BVH Build 45946
A little faster than the Bat3A without the BVH optimizations,
still nowhere near as fast as MinGW-64.
Its Not The OS! Its All About the COMPILER! :rolleyes:
hmmm… Psy-Fi does your build have all the BVH optimizations in it?
I just tested tomato 45946 and it builds my pretty complex kitchen scene in about 1/2 the time that yours does,
But it renders slower(overall time),
If we can get the BVH build time seen in Tomato branch into yours then it would be really optimized.
this isnt anything to shake a stick at… check it out…
32seconds build bvh
9.9Seconds build bvh
Hi, as far as I know tomato branch still hasn’t merged the changes required to build from MinGW-w64. This is a trunk build so the BVH build optimizations are not in yet. Patience, in a week we’ll have both
test tungerz Tomato build out it builds the BVH fast!
Just tried another scene a classroom.
14sec build bvh
tungerz Tomato build
(…) got frustrated trying to build in MinGW64. Cant even run CMAKE 'cause libgmp-10, lib-intl8 is missing. Again sth messed up with MinGW ((
bluecd - you need to checkout the lib/mingw64 (and mingw users need to check out lib/mingw32).
Edit: in case you did checkout the correct lib folder I am interested in seeing your configuration options if any - note that default settings should compile fine
Thanks for the MingW-64 support.
I tried building with scons. Compiled successfully, everything was ok but when I opened …\install\win64-mingw\blender.exe “pthreadGC2.dll wasn’t found” warning appeared. What does this mean? Any idea?
Edit: OS: Windows 7 Pro 64 bit.
What about a tomato branch compile with this?
Much thanks for working on this!
So I tried to compile with scons and Cmake, but kept getting this error (this is scons, getting a similar one using cmake):
Here’s where it seems to go wrong:
error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
In file included from C:\blendersvn\lib\mingw64\boost\include/boost/smart_ptr/shared_ptr.hpp:30:0,
scons: *** [C:\blendersvn\build\blender25-win64-mingw\intern\cycles\bvh\bvh.o] Error 1
scons: building terminated because of errors.
Win 7 64 Pro, using command line from MSVC express. I usually build scons with no issues. Any ideas?
Hi demohero, the thing is, MinGW-w64 uses its own pthreads so you will either have to add MinGW/bin that includes pthreadGC2-w64.dll to your PATH or, for redistributable builds you will have to copy the dll next to the blender executable. I am a bit mystified though because you should get problems with pthreadGC2-w64.dll rather than pthreadGC2.dll which makes me think you may have been victim to one of the cases below.
My guess is, and advice to others here is:
You may have mixed up your MinGW installations. Try gcc -v to make sure you have the right one (MinGW-w64 version is currently 4.7.0, MinGW is 4.6.1 or 4.6.2). Also, make sure the right one is in your PATH. Rename the other MinGW folder to something else like “hippopotaMinGW” to make sure no clashes happen. Also when extracting the MinGW systems do not put them in the same folder! They are separate compiler systems.
You may have mixed up your lib folders. For MinGW64 use lib/mingw64. If you build with both MinGW and MinGW-w64, alter the name of the other lib folder when building with one MinGW as a safeguard to make sure you don’t reference the wrong libraries.
You have mixed MinGW generated code with MinGW-w64 generated code as I have found out that a new compiler version is not always detected by the build system. For scons this is especially a ‘hidden’ trap because when we added support for MinGW-w64, 64bit python versions would build on build/win64-mingw even with MinGW without warning if lib/mingw64 existed on the system. If you do a build with a new MinGW make sure to build on a fresh directory. Otherwise on link time the compiled with one compiler modules will try to reference the other compiler’s libraries or dlls. Even if it does compile, which I don’t think so, it will be hurtful later for sure
For those building with scons:
- IMPORTANT! You may have the wrong python version (32-bit will build with MinGW, 64-bit with MinGW-w64). Also, for those of you having problems, please try a clean build (delete the build/win64-mingw and install/win64-mingw folders) to make sure problem 3) above is eliminated
For those building with cmake:
- Make sure you enable -DWITH_MINGW64=ON. If you use cmake-GUI this is available in the advanced options. Also build on a clean directory. 3) is a confirmed problem for cmake.
If problems persist do nag me again :). Oh, important detail! Only trunk is supporting minGW-w64 currently. Tomato does not yet, until trunk is merged.
Will do a clean scons build here and notify again if any problems arise here.
[Edit:] Also! Don’t put both MinGW versions in your path. I haven’t actually tested this but my intuition tells me: trouble!