Game Development Community

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:

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!
#41
11/05/2004 (9:12 am)
We're in the same boat here--32 bit emulation is "good enough" for our current phase.

GG: Would it be possible to get true 64 bit compilation on one of the future release .plans, maybe 1.4 or 1.5? We do realize it's asking a lot (we've tried it and failed, Paul appears the same situation), but it would be a strong selling point IMO for larger projects :)
#42
11/05/2004 (11:00 am)
We might do a 64bit clean version at some point in the future. Right now our plates are pretty loaded, though. :) Maybe in six months or so, we can get to it.
#43
11/05/2004 (12:14 pm)
@Ben, Paul, Stephen:

Thanks guys, you have helped a lot. I'm glad that we have gotten this far!

~Tony
#44
03/26/2005 (12:24 pm)
Paul did you ever get it working in 64bits? I'm also curious about getting it to run in 32bit mode?

I have it compiling and it starts running up to a point but keep getting pointer problems in the console code during init :(
#45
03/26/2005 (1:24 pm)
I haven't made progress on the 64-bit port I'm afraid Benoit - too much work in the past three months! However I still have 32-bit emulated version running fine and can answer any of your build questions (hopefully). Are your pointer problems with the 64-bit or 32-bit emulated?
#46
03/26/2005 (5:38 pm)
64bit, but i was curious to know what changes were needed to get it working 32bit as i can't afford to waste much more time on the 64bit version for now.
#47
03/27/2005 (8:38 am)
Ok, I got it to compile in 32bit but i keep getting an error message saying that it can't initialize GL. If you have a quick idea on how to fix that i would appreciate. Currnetly i have all the 32bit libs in the same directory as the executable and set LD_LIBRARY_PATH to be the same as the directory.
#48
03/27/2005 (9:06 am)
I got it running by setting LD_LIBRARY_PATH and also by setting LD_PRELOAD=/usr/lib/libGL.so.1 using the latest nvidia driver. But now it crashes when connecting to a game using the master server or during init of a local. :(

Edit: Just tried the same trick on the thinktank demo and it seems to work fine, so there is something i am missing or not doing properly.
#49
03/27/2005 (10:53 am)
Shouldn't that be /usr/lib32/libGL.so.1? Some more suggestions:
* ldd thinktanksdemo and see exactly which libraries it links to. Then do the same with example/torqueDemo.bin and compare.
* strace ./example/torqueDemo.bin and see where it breaks
* ddd or gdb ./example/torqueDemo.bin and get a backtrace of the crash. You'll have to use 32-bit versions of these programs. It helps to zoom in on what the problem is in these kinds of scenarios.
#50
03/27/2005 (10:56 am)
Oops - ldd ThinkTanks.bin - not the thinktanksdemo file - it's a script...
#51
03/27/2005 (11:46 am)
Another tip Benoit - install gdb-6.3 instead of messing around with 32-bit gdb. This version will debug 32-bit software running under emulation correctly. You might receive errors like this:
Program received signal SIG32, Real-time event 32.
0x5561afa4 in pthread_create () from /emul/linux/x86/lib/libpthread.so.0

while running your code. Just issue a 'cont' command at the gdb prompt to continue execution. Using this version of gdb should definitely show you where the problem is.
#52
03/27/2005 (12:52 pm)
To clarify i get an assert in interior.cc at line 2078 when using the version i compiled in 32bit (added -m32 to the CFLAGS and added the proper path for the libs to point to the 32bit libs with the LDFLAGS vars).

Already have gdb 6.3, still trying to figure how to get the LD_PRELOAD to work with gdb 6.3 / ddd 3.9 (can't get 3.10 to trace properly).

Btw what distro are you using? I'm on Mandrake. Using Gcc 3.4.3, binutils 2.15.92.0.2, gdb 6.3 and ddd 3.9.

As for the 64bit version, applying the same modifications as for the Mac OSX should work as both the AMD64 and PowerPC are LP64 based only the endianness changes. But so far thats been even more frustrating.

This new machine i got is blazing fast but development using torque has been quite frustrating so far.

Thanks for your input.
#53
03/27/2005 (1:29 pm)
"To clarify i get an assert in interior.cc at line 2078 when using the version i compiled in 32bit (added -m32 to the CFLAGS and added the proper path for the libs to point to the 32bit libs with the LDFLAGS vars)."

The error looks like a GL library is misbehaving - but I think we knew that already :(

"Btw what distro are you using? I'm on Mandrake. Using Gcc 3.4.3, binutils 2.15.92.0.2, gdb 6.3 and ddd 3.9. "

I use Gentoo for amd64. gcc 3.3.4, binutils 2.15.90.0.1.1-r3, gdb-6.3, dd 3.8, and nividia-kernel-1.0.6629-r1.
I'm sure LD_PRELOAD is not doing what it should - or perhaps can be fixed another way. In your mk/conf.UNIX.mk have you set:
LFLAGS.GENERAL = -m32 -L/usr/lib32 as well as the march and -m32 options?

"As for the 64bit version, applying the same modifications as for the Mac OSX should work as both the AMD64 and PowerPC are LP64 based only the endianness changes. But so far thats been even more frustrating."

Good point - when I get to it I will be starting on the 32-bit asm code first and make sure it works. But I'd forgotten about the Mac being 64-bit - thanks :)

"This new machine i got is blazing fast but development using torque has been quite frustrating so far."

Development using _most_ tools and libraries has been frustrating on amd64 for me so far. Some stuff is 64-bit clean, most is not :( The price of the bleeding edge I think.
#54
03/27/2005 (1:46 pm)
www.x86-64.org i believe has a short porting guide for assembly code. I just took that part out for now.

I just recompiled without the -static option and i am getting the same error you mentioned above but now i get other segfaults and it won't continue after the third cont. :(
As for Mandrake there is only lib and lib64 directories no lib32. Normally lib should store the 32bit libs only but as i discovered recently some pieces of software :) store the 64bit version there as well. Now in this case i triple verified that none were 64bit and seem ok from that point but i'm still no closer to resolving this mess.
#55
03/28/2005 (1:58 pm)
:(

Time to get started with the 64-bit version...
#56
03/28/2005 (3:50 pm)
Hello all! I'm glad to see that progress is still being made towards a 64-bit native compile for Torque. I am just curious if someone would be willing to help me work on a wiki, or some sort of documentation for 32-bit computation of Torque on an x86-64 system. Preferably on Gentoo Linux x86-64 if possible.

Tony

-----
Note: I'd be willing to host the wiki while in progress on my domain.

Thanks.
#57
03/29/2005 (4:26 am)
After some tweaking i got a 32bit version that acts like the -static version and asserts at the same place as the original. Oh and i was using gcc 3.3.4 for this to work. When i try with 3.4.3 i get the segfaults as mentioned above.

When i get back from work tonight i will look at it a bit further and try to compare the results to the 64bit version and see where i am going wrong.

Also Paul you will need to fix x86UNIXMemory.cc and x86UNIXStrings.cc to get things started. Some of the functions casted variables are not the same as the prototypes in platform/platform.h. Since i have been editing a lot of files i have created a new platform LINUX64 (added a bunch of ifdefs for it, makes for a huge patch :) ). and created a new directory called platformX86_64UNIX with all the platform specific mods and in platform created a new typesX86_64UNIX.h to handle the types changes (dsize_t only right now). I also took out all the assembler code and change what i could to C code to avoid debugging that and the rest of the mess at the same time.

I also applied the patches from James Urquhart to event.h and resManager.h so i could compile on 3.4.3. See this thread www.garagegames.com/mg/forums/result.thread.php?qt=21521 for more information.
#58
03/30/2005 (12:50 am)
Tony, I can write up the procedure that worked for me and send it to you if you like. It is for Gentoo x86_64 but people on other distributions could also add their experiences on how they got it working.
#59
03/30/2005 (12:54 am)
Benoit, could I have your patch sometime please? Sounds like you've made lots of progress already. Are you working from a specific release or from the latest CVS?
#60
03/31/2005 (9:24 am)
Thanks paul, if you wouldn't mind emailing it to me at antonio_farinetti AT yahoo.com I would appreciate it.

Thanks everyone!