http://rattle.from-hell.net/spring/mingwlibs_glew-1.5.0_boost-1.35.0.zip
Updated the libs for boost and glew (gcc 4.3.0)... just in case

I think we really need some official version info about everything used in the auto build so everyone to build the same. I think the cool thing would be to provide dynamically generated autobuild info regarding version info.

Also I would like to see the following info added:

The build must occur under MSYS command prompt.

SCONS installation is buggy as hell so I would like to see a little extra info here.

Warning about getting two different gcc/g++ libs in path collision and/or remove Dev-cpp from the info.

Also,

Is there a reason the auto build is not using MinGW 5.1.4 latest?

It almost builds all the way with VC9. What will get rid of the #include <complex> issue?

That's not true. I can build fine from the windows shell.

Mine won't because it would clash with other libraries outside of MinGW.

So, maybe correct my statement it as, "may not build out side of the MSYS command shell if you have other unix tools installed."

Also, I can't seem to find 4.2.1 MinGW exe. I use the latest instead, but I would like to use what is used by the autobuild. It does not seem to be available anywhere.

Alright.

There is no mingw 4.2.1 but there is gcc 4.2.1 for mingw.
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304&release_id=532062

I've had to remove the -sjlj bit from the binaries btw.

Well if auto build isn't using MinGW 4.2.1 what is it using?

Was hoijui wrong is saying autobuild was using MinGW 4.2.1?

viewtopic.php?f=15&t=12308&st=0&sk=t&sd=a&start=140

Well I guess that reinforces what I said about the info being public about library versions used by auto build.

Samples of mingw buildbot output:

tberthel
remember that buildbot runs on linux. it cross compiles. the current stable MinGW on linux is 4.2.1 (at least i think so). It is not really practical that we have 4.2.1 on linux and 4.3.0 on windows though, i agree. (Maybe we should use the 4.2.1 that rattle mentioned? SjLj)

again, can please someone post a description here, of how to setup ones system to be able to compile spring on windows with MinGW 4? (directly actualizing hte Wiki would be ok too).

Should we have a description for 4.2.1 and for 4.3.0 on windows?

Rattle was specifying a gcc version instead of MinGW version since he didn't find a matching version for MinGW, but you were using MinGW versioning.

MinGW version is not always = gcc version

The URL u gave does not work.

I wouldn't recommend different versions on different systems.

bibim's URL that is does not work.

bibim,

Thanks for getting the correct version info so I know what software they are relating to 4.2.1 in discussions now. I suspected it was gcc for mingw and not mingw itself. Maybe the sync error will go away now.

Indeed, buildbot html pages just went down. But they worked at the time I posted, and I guess they will be back up soon...
Between which binaries do you have sync errors ?

JAI and Spring.

I was using autobuild 5956 with JAI. JAI was built against my build of Spring of the same autobuild version. I copied the libs and exe from the build, but I may have missed one. It could just be the way the JAI currently works. I will wait for further developments before I try making changes to fix the sync error..

There doesn't seem to be any r5956 available in buildbot binary output page, so I guess you used BuildServ binaries. Here are the mingw packages used to build these binaries:

great

Why is it the the other autobuild doesn't have that version?

Thanks

is it possible to compile spring with visual studio 6 ?

VC++ 6 lacks the necessary meta template support for luabind. VC++ 6 is not supported by the developers and if you want to compile it youll have to work it out on your own. There are no VC6 project files either.

The VC8 libraries have gone again. That or the wiki is out of date yet again =/

there is a problem with building streflop:
am compiling spring on linux, sometimes with scons sometimes with CMake. CMake overwrites the 'native' Makefile for streflop (rts/lib/streflop/Makefile). so when switching from cmake to scons, one has to revert the Makefile from SVN every time. inconvienient! after a while using only CMake, i will forget it, and i will have to find out again why i get undefined symbols when linking. it is also bad cause i or someone else may accidentially ubload the CMake generated Makefile to SVN, and then everyone would have the problem.

maybe we should alternate one of the two build systems to use an other filename (not Makefile). we could have Makefile.scons eg, which is copied to Makefile on scons configure.