SpringApp.cpp:273: error: ÔÇÿCPU_COUNTÔÇÖ was not declared

[-=[UN]=-Obscene]

centos 5.5

spring_0.82.7.1 and cvs
devil-1.7.8 from source
boost_1_46_0 from source

Code: Select all

[ 56%] Building CXX object rts/builds/default/CMakeFiles/engine-default.dir/__/__/System/SpringApp.cpp.o
.
.
.
.
/opt/springrts/spring_0.82.7.1/rts/System/SpringApp.cpp: In member function ÔÇÿvoid SpringApp::SetProcessAffinity(int) constÔÇÖ:
/opt/springrts/spring_0.82.7.1/rts/System/SpringApp.cpp:273: error: ÔÇÿCPU_COUNTÔÇÖ was not declared in this scope
make[3]: *** [rts/builds/default/CMakeFiles/engine-default.dir/__/__/System/SpringApp.cpp.o] Error 1
make[2]: *** [rts/builds/default/CMakeFiles/engine-default.dir/all] Error 2
make[1]: *** [rts/builds/default/CMakeFiles/spring.dir/rule] Error 2

not to sound like a moron,, as im sure you guys wouldnt have missed the scope on this variable.
any clue why this wont compile?

[abma]

CPU_COUNT is defined in <sched.h> and is included in https://github.com/spring/spring/blob/0 ... pp.cpp#L72

maybe your header-file is missing? is this the most recent error?

what do you mean with "and cvs"?

[-=[UN]=-Obscene]

cvs? concurrent versions system. im saying i tried both revisions. the last stable (or at least formally released version) and the stuff that was in the repository. no dice.

yeah... i gave up on this after fighting Spring for 3 weeks. i went through patching here and there.. trying to make it work. finally got it to compile. craps out when the 3D rendering really kicks in. cant remember the error message off the top of my head. its a shame too... would have been nice to have a stable engine to play with.

[abma]

most crashes can be solved by changing spring/system-config:

http://springrts.com/wiki/FAQ:trouble

a stacktrace/gdb backtrace/infolog.txt would be useful, too...

what did you, to solve the compile-issues? maybe others can profit from your efforts, too!

[jK]

cvs? concurrent versions system. im saying i tried both revisions. the last stable (or at least formally released version) and the stuff that was in the repository. no dice.

yeah... i gave up on this after fighting Spring for 3 weeks. i went through patching here and there.. trying to make it work. finally got it to compile. craps out when the 3D rendering really kicks in. cant remember the error message off the top of my head. its a shame too... would have been nice to have a stable engine to play with.

Spring is stable, your compile environment & gpu drivers aren't
(not meant in an offending way, just in an informative one)

[-=[UN]=-Obscene]

cvs? concurrent versions system. im saying i tried both revisions. the last stable (or at least formally released version) and the stuff that was in the repository. no dice.

yeah... i gave up on this after fighting Spring for 3 weeks. i went through patching here and there.. trying to make it work. finally got it to compile. craps out when the 3D rendering really kicks in. cant remember the error message off the top of my head. its a shame too... would have been nice to have a stable engine to play with.

Spring is stable, your compile environment & gpu drivers aren't
(not meant in an offending way, just in an informative one)

you are probably right... but the environment compiles for a living and runs several other graphics engines without any trouble. the only difference i can find is spring tries to make use of some of the latest libs out there. between various OS's, not writing on seasoned code tends to introduce problems on platforms different from the development environment. two years from now, when all the distributions catch up debugging and commit the newer libs to their various repositories, odds are Spring will be rock solid for me too.

[jK]

the only difference i can find is spring tries to make use of some of the latest libs out there.

Sure Spring is different than many other linux projects (excessive OpenGL usage, engine flexibility, ...).
Still it's not that we make usage of the most up to date libs, mostly we are even forced to update because some linux distros switched to newer ones (applies to boost & gcc). Still the engine should always compile with 1-2year old libs, everything older is really old and not just `not up to date`.
Not to forget that we are always reminded by debian that there are distros with old packages in their repo (their boost libs sometimes are ... ancient).

[hoijui]

i also agree that it would be very bad to rely on latest lib versions, but as jk said, this is really not the case for spring. as much as i know, it happened only once, and only for a few commits, that the engine was not compatible with common boost versions. as much as i know, it should still be compatible with boost 1.35.0, for example.
if you still care, and give us the right info, we would surely be willing to help you solve the problems still.