Forums

Full Version: Vdrift do not compile anymore ( rev 2465 )
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I just destroyed my svn tree I checked out vdrift and vdrift-data again.

When trying to compile I get this error :
Code:
cbo@cbobox:~/subversion/vdrift$ scons arch=a64 force_feedback=1
scons: Reading SConscript files ...

scons: warning: The Options class is deprecated; use the Variables class instead.
File "/home/cbo/subversion/vdrift/SConstruct", line 9, in <module>

scons: warning: The BoolOption() function is deprecated; use the BoolVariable() function instead.
File "/home/cbo/subversion/vdrift/SConstruct", line 13, in <module>
Checking for C++ header file boost/asio.hpp... (cached) yes
Checking for C++ header file GL/gl.h... (cached) yes
Checking for C++ header file GL/glu.h... (cached) yes
Checking for C++ header file SDL/SDL.h... (cached) yes
Checking for C++ header file SDL/SDL_image.h... (cached) yes
Checking for C++ header file SDL/SDL_rotozoom.h... (cached) yes
Checking for C++ header file vorbis/vorbisfile.h... (cached) yes
Checking for C++ header file GL/glew.h... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
g++ -o build/car.o -c -Wall -Wextra -Wno-unused-parameter -pthread -g3 -march=athlon64 -D_GNU_SOURCE=1 -D_REENTRANT -Iinclude -Isrc/bullet -I/usr/include/SDL src/car.cpp
src/car.cpp: In member function ‘bool CAR::LoadInto(SCENENODE*, SCENENODE*&, DRAWABLE*&, const std::string&, MODEL_JOE03&, const std::string&, TEXTURE_GL&, const std::string&, TEXTURE_GL&, int, const std::string&, std::ostream&)’:
src/car.cpp:450: erreur: no matching function for call to ‘max(unsigned int, long unsigned int)’
scons: *** [build/car.o] Error 1
scons: building terminated because of errors.
cbo@cbobox:~/subversion/vdrift$ svn up
À la révision 2465.
tof8pool Wrote:When trying to compile I get this error :
Try an update now. 2466 has that error fixed, the first unsigned int should have been a long unsigned int. It should compile properly now.
That's ok now.
TY
Now with 2466 under windows:

src\car.cpp:450: error: no matching function for call to `max(long unsigned int, unsigned int)'
Perhaps is there the beginning of an explaination here ?

http://forums.devx.com/archive/index.php/t-92352.html
http://www.devx.com/tips/Tip/14540
i'm using mingw, not vcpp
In 2467 I've tried to redefine std::max() to _cpp_max() to see if that helps. I'm kind of flying blind here though, as I have no windows box to test anything out on! :?

The other suggestion I found (for Developer Studio on Windows) was to set a preprocessor symbol to NOMINMAX. Is there something similar for mingw?
same problem for me :

Quote:g++ -o build/car.o -c -Wall -Wextra -Wno-unused-parameter -pthread -O1 -pipe -D_GNU_SOURCE=1 -D_REENTRANT -Iinclude -Isrc/bullet -I/usr/include/SDL src/car.cpp
src/car.cpp: In member function ‘bool CAR::LoadInto(SCENENODE*, SCENENODE*&, DRAWABLE*&, const std:Confusedtring&, MODEL_JOE03&, const std:Confusedtring&, TEXTURE_GL&, const std:Confusedtring&, TEXTURE_GL&, int, const std:Confusedtring&, std::ostream&)’:
src/car.cpp:451: erreur: no matching function for call to ‘max(long unsigned int, unsigned int)’
scons: *** [build/car.o] Error 1
scons: building terminated because of errors.

ubuntu 9.04 svn rev 2467.
I just update my tree with rev 2467.
I'm also running Ubuntu 9.04 but my kernel is 64 bits na dI'm compiling a 64 bits release.

Perhaps is it 32/64 bits compatibility problem
The std::max function is a template function defined something like:
Code:
template <typename T>
max(T value1, T value2);

The two arguments MUST have the same type, and C++ won't do type auto-casting even with similar numeric types. In R2468 I added an explicit cast and it seems to work fine, so I removed the #define thing (don't think it's needed anymore).
Well. it's rev.2485.

"build\nedmalloc.o:nedmalloc.cSad.text+0x98): undefined reference to `_InterlockedExchange'"
something with boost library?
Huh, I don't have this problem. What linux distribution are you using? nedmalloc is a high-performance malloc implementation that I added because the windows malloc is incredibly slow. There's not much difference in performance between the recent linux malloc implementations, so if we can't figure this out I could just disable nedmalloc unless the user is building on windows.
Oops, I just remembered you build on Windows. Let me boot up my windows box and see if I can reproduce.
Okay, should be fixed in R2487. I think that upgrading mingw would have fixed it too, but I just edited the malloc.c.h file to call the non-intrinsic functions instead of trying to be fancy. The track load times seem to be faster with nedmalloc.