Compiling torque on x86-64 (amd64) non functional?
by Antonio "Tony" Farinetti · in Torque Game Engine · 05/15/2004 (1:57 pm) · 109 replies
After getting the CVS like usual and executing this command:
and getting this back:
And then issuing make, the compile stops fast with:
Any ideas on how to fix this?
Thanks!
make -f mk/configure.mk OS=LINUX COMPILER=GCC2 BUILD=DEBUG
and getting this back:
Current Configuration: this config is VALID
OS: LINUX
COMPILER: GCC2
BUILD: DEBUG
DIR.OBJ: out
To change the current configuration type:
make -f mk/configure.mk {arguments, ...}
required arguments:
OS={WIN32 BEOS LINUX OpenBSD FreeBSD Solaris}
COMPILER={CW6 VC6 GCC2 GCC3}
BUILD={DEBUG RELEASE}
optional arguments:
DIR.OBJ={path to store intermediate obj files}
Note: all arguments are case sensitive.And then issuing make, the compile stops fast with:
tony@tantalus torque $ make --> Compiling lpng/png.c cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set make[1]: *** [out.GCC2.DEBUG/lpng/png.obj] Error 1 make: *** [default] Error 2
Any ideas on how to fix this?
Thanks!
About the author
#82
04/09/2005 (5:40 am)
I got the DEBUG_GUARD working, there were two instance (the first two that the compiler complains about)of VECTOR_SET_ASSOCIATION(mPaths) causing problems so #ifdef'ing them out of existance fixed that part, but now that its up its wierder than before because the DataChunker constructor is never called and it alloc asserts when it is called because chunkSize has a value of 0 since it was never set. :(
#83
04/09/2005 (8:39 am)
Ouch. What does DEBUG_GUARD actually do? Disabling the built-in memory manager seemed to eliminate a number of problems because at least the system libraries know they're running in 64-bit but I doubt that DEBUG_GUARD will magically eliminate the above pointer problem. I'm struggling to even understand the above construct - it seems to be saying return a pointer to the address of u cast into type pointer to StringTable. Next stop: run the 32-bit version in the debugger and make a note of the values of various pointers in the compiler to see what they *should* be. I'm not doing so well though - kids bouncing on the bed when I'd only had 3 hours of sleep this morning!
#84
As far as 32bit goes i am fubared when compiling with -static. Will try again without it and see. Seems like Mandrake 64bit edition is much less stable than its 32bit counterpart. I am thinking of switching distro's after having used them for that last couple of years i guess i'm due for a change but i can't find one that seems to fit me well :)
Guess you need a break :)
I'll be taking the rest of the day off. I can see a brilliant shining orb through the curtains and i am intrigued, must go to it .....
04/09/2005 (9:42 am)
No its supposed to help track allocation/deallocation issues from what i read on the forums. Ben could probably enlighten us more. What really bugs me after looking at the OSX code is that it works there fine from what i can tell. As far as i can tell its to return a pointer to a string type casted to StringTableEntry its actual effect i am still looking into. As far as 32bit goes i am fubared when compiling with -static. Will try again without it and see. Seems like Mandrake 64bit edition is much less stable than its 32bit counterpart. I am thinking of switching distro's after having used them for that last couple of years i guess i'm due for a change but i can't find one that seems to fit me well :)
Guess you need a break :)
I'll be taking the rest of the day off. I can see a brilliant shining orb through the curtains and i am intrigued, must go to it .....
#85
The fix'll be to convert the DSOs to be an array of U64s, I guess, or to make the string pointers store as double their current length. Or find some other way of storing things that works better. I suspect a future rewrite of Torque will make STE's simply store an index into the string table, rather than a raw pointer as they currently do. This will be 64bit safe.
DEBUG_GUARD stores sentinel values before and after every allocated memory chunk so that you can check for buffer over/underruns. I would rate this feature as a must-have. ;) It has saved many a shipping game from heinous bugs. But it may have to be updated to be 64bit sane, as it does some trickery to try and be friendly for 32bit. Nothing that would crash, I don't think, but some things that might be better as 64bit values.
04/09/2005 (2:38 pm)
As I recall, the script compiler compiles string references as indices in a table. When the DSO is loaded, it resolves all the indices to STE's and stores the pointers into the memory buffer. So then when you want to access the string you just snarf the value from the buffer and cast.The fix'll be to convert the DSOs to be an array of U64s, I guess, or to make the string pointers store as double their current length. Or find some other way of storing things that works better. I suspect a future rewrite of Torque will make STE's simply store an index into the string table, rather than a raw pointer as they currently do. This will be 64bit safe.
DEBUG_GUARD stores sentinel values before and after every allocated memory chunk so that you can check for buffer over/underruns. I would rate this feature as a must-have. ;) It has saved many a shipping game from heinous bugs. But it may have to be updated to be 64bit sane, as it does some trickery to try and be friendly for 32bit. Nothing that would crash, I don't think, but some things that might be better as 64bit values.
#86
@Benoit: I run 64-bit Gentoo and it is a royal pain to set up but once it's done, it's brilliant. My wife runs Ubuntu which is the distro I recommend to just about everyone these days - also an excellent 64-bit port available. Have a look at the new version - Hoary Hedgehog - and see if you like it.
@Ben: rewriting the compiler looks like a very large job indeed. Would it be simpler to rip it out and replace it with something like Lua or Python?
04/09/2005 (3:43 pm)
@Benoit & Ben: thanks for the tips on DEBUG_GUARD - looks like a Very Good Thing (tm). @Benoit: I run 64-bit Gentoo and it is a royal pain to set up but once it's done, it's brilliant. My wife runs Ubuntu which is the distro I recommend to just about everyone these days - also an excellent 64-bit port available. Have a look at the new version - Hoary Hedgehog - and see if you like it.
@Ben: rewriting the compiler looks like a very large job indeed. Would it be simpler to rip it out and replace it with something like Lua or Python?
#87
04/09/2005 (4:55 pm)
@Paul: Not really. Lua and Python don't do the same things that TorqueScript does. And... we're not talking about a rewrite. Just getting it to use slightly different datatypes and occasionally changing how much space it gives things. This is normal 64bit port stuff - you may as well argue it would be better to replace Torque with another engine! :)
#88
04/09/2005 (6:49 pm)
@Ben: Fair enough. I just got a bit daunted by the potential knock-on effects of changing the size of the string table but on reflection it's just unfamiliarity with the codebase rather than anything technical. I do like the idea of an alternative language binding though - something like Josh Ritter did with PyTorque but much more radical really. I certainly don't want to replace the Torque engine - it rules :)
#89
04/09/2005 (9:04 pm)
@Paul: It's not actually the string table, just that the size of a pointer is different on 64bit systems... It's just storing a pointer in a U32, which works great on 32bit but not 64bit systems.
#90
04/11/2005 (8:17 am)
Hmmm - I've just been jumped with a couple of deadlines for various commercial projects that I'm working on. I'm going to have to put this port on the back-burner for now, maybe for the next couple of months or so :( I will keep in touch though and will have notify on this thread on.
#91
Ben: Has anyone gotten torque to run on a G5? If so did they do it in 32bit or 64bit?
04/11/2005 (10:53 am)
Paul: No problem i understand, there seems to be a huge taks list left to get this running :( I will probably be taken a break from this an try to get the 32bit version running for now so i can back to working on more importatn things.Ben: Has anyone gotten torque to run on a G5? If so did they do it in 32bit or 64bit?
#92
04/12/2005 (8:38 am)
@Benoit: BTW, you might be interested in the Insight deugger. I've been using it with much more success than ddd which doesn't terminate gdb processes properly and often gets confused by the 64-bit thing. It also has a nice built-in source browser where you can set breakpoints if you need to.
#93
04/12/2005 (11:25 pm)
AFAIK, we pretty much stick to 32 bit compilation. Several of us at the office run on G5s, with no problems.
#94
If anyone else wants Paul's x86_64 HOWTO & PATCH visit my wiki.
wiki.farinetti.net/index.php?title=Paul_Furber%27s_Torque_x86_64_Guide
04/12/2005 (11:52 pm)
Thanks ben.If anyone else wants Paul's x86_64 HOWTO & PATCH visit my wiki.
wiki.farinetti.net/index.php?title=Paul_Furber%27s_Torque_x86_64_Guide
#95
04/13/2005 (3:40 am)
@Tony: mind if I submit this as a Torque resource? Some people not following this thread might find it useful.
#96
04/13/2005 (7:43 am)
When i try it (tutorial) i get the same assert as i had mentioned above previous and the same goes with the the TGE demo seems to segfault the same way. But thinktanks demo works. The only difference in all three is that thinktanks was compiled ont RH7.3 with GCC 2.96 and GLIBC 2.2.1 i beleive. I am using Mandrake 10.2 for x86_64. I think i will try it on CentOS 4.0 for x86_64.
#97
04/14/2005 (6:03 pm)
@Paul: Go right ahead, its your article. :)
#98
Fedora Core 3 x86_64 -- fairly vanilla install.
04/23/2005 (9:49 pm)
In file included from ./audio/audioBuffer.h:16,
from ./audio/audioDataBlock.h:13,
from ./audio/audio.h:13,
from audio/audio.cc:6:
./core/resManager.h: In member function 'void Resource<T>::unlock()':
./core/resManager.h:255: error: invalid use of undefined type 'struct ResManager '
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
./core/resManager.h: In member function 'void Resource<T>::purge()':
./core/resManager.h:263: error: invalid use of undefined type 'struct ResManager '
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
./core/resManager.h:265: error: invalid use of undefined type 'struct ResManager '
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
./core/resManager.h: In member function 'void Resource<T>::_unlock()':
./core/resManager.h:278: error: invalid use of undefined type 'struct ResManager '
./core/resManager.h:38: error: forward declaration of 'struct ResManager'
In file included from ./sim/netConnection.h:19,
from ./game/gameConnection.h:16,
from audio/audio.cc:11:
./platform/event.h: At global scope:
./platform/event.h:137: error: a casts to a type other than an integral or enume ration type cannot appear in a constant-expression
./platform/event.h:137: error: '->' cannot appear in a constant-expression
./platform/event.h:137: error: '&' cannot appear in a constant-expression
./platform/event.h:137: error: enumerator value for 'PacketReceiveEventHeaderSiz e' not integer constant
./platform/event.h:140: error: a casts to a type other than an integral or enume ration type cannot appear in a constant-expression
./platform/event.h:140: error: '->' cannot appear in a constant-expression
./platform/event.h:140: error: '&' cannot appear in a constant-expression
./platform/event.h:140: error: enumerator value for 'ConnectedReceiveEventHeader Size' not integer constant
./platform/event.h:143: error: a casts to a type other than an integral or enume ration type cannot appear in a constant-expression
./platform/event.h:143: error: '->' cannot appear in a constant-expression
./platform/event.h:143: error: '&' cannot appear in a constant-expression
./platform/event.h:145: error: enumerator value for 'ConsoleEventHeaderSize' not integer constant
audio/audio.cc: In function 'int loopingImageSort(const void*, const void*)':
audio/audio.cc:161: warning: converting to 'int' from 'float'
audio/audio.cc: In function 'int streamingSourceSort(const void*, const void*)':
audio/audio.cc:193: warning: converting to 'int' from 'float'
audio/audio.cc: In function 'AUDIOHANDLE alxCreateSource(const Audio::Descriptio n*, const char*, const MatrixF*, AudioSampleEnvironment*)':
audio/audio.cc:707: warning: converting to non-pointer type 'ALuint' from NULL
audio/audio.cc: In function 'ALuint alxGetWaveLen(ALuint)':
audio/audio.cc:2092: warning: converting to 'ALuint' from 'F64'
make[1]: *** [out.GCC3.DEBUG/audio/audio.obj] Error 1
make: *** [default] Error 2Fedora Core 3 x86_64 -- fairly vanilla install.
#99
04/24/2005 (4:06 am)
Ian - which version of gcc? Have you applied the patch from the wiki site?
Torque Owner Paul Furber
For instance:
inline StringTableEntry U32toSTE(U32 u)
{
return *((StringTableEntry *) &u);
}
This segfaults the compiler when it starts compiling starter.fps because it returns an out-of-bounds pointer.