Game Development Community

Compiling on 64-bit linux

by stonefish · in Torque Game Builder · 05/18/2006 (1:25 pm) · 6 replies

Hello,

I'm trying to compile Torque2D on ubuntu 64-bit. It's the version which was archived in the following file: Torque2DSDK_1_0_2.zip

Underneath you can see which commands I executed and which output they generated. I executed them in the SDK subfolder (containing the Makefile).

If anyone has a clue how I could make it to compile...

[b]# make -f mk/configure.mk OS=LINUX COMPILER=GCC3[/b]
 BUILD=DEBUG

Current Configuration: this config is VALID 
         OS: LINUX
   COMPILER: GCC3
      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.

[b]# make[/b]
--> Compiling lpng/png.c
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
lpng/png.c:1: error: CPU you selected does not support x86-64 instruction set
lpng/png.c:1: error: CPU you selected does not support x86-64 instruction set
make[1]: *** [out.GCC3.DEBUG/lpng/png.obj] Error 1
make: *** [default] Error 2

About the author

Recent Threads


#1
05/18/2006 (2:46 pm)
I tried compiling it on the 32-bit ubuntu, and it succeeded. I could run the T2D.bin program.

After moving the whole Torque2D directory to the 64-ubuntu environment, it didn't work any more:

[b]# ./T2D.bin[/b]
./T2D.bin: error while loading shared libraries: libogg.so.0: cannot open shared object file: No such file or directory

I do have libogg (version 1.1.2-1) installed.

Maybe there is a way to compile a statical executable? The best way though would still be to compile a native 64-bit version...
#2
05/18/2006 (3:51 pm)
I managed to fix the 'processor-bug':

In mk/conf.UNIK.mk: replace the following code
CFLAGS.GENERAL    = -DUSE_FILE_REDIRECT -I/usr/X11R6/include/ -MD -march=i586 \
		    -mcpu=i686 -ffast-math -pipe
by this:
CFLAGS.GENERAL    = -DUSE_FILE_REDIRECT -I/usr/X11R6/include/ -MD \
		    -ffast-math -pipe

And in engine/platform/types.gcc.h, the following code has to be replaced:
// Identify the CPU

#if defined(i386)
by
// Identify the CPU
#define i386
#if defined(i386)

The last replacement makes the program think I'm using a i386 processor, so this might lead to other problems.

When I try to compile now, I get some errors (of which I already resolved some), but I think I'll have to find a way to compile with another version of gcc (I do have different versions of gcc, but I guess the newest version is used by default).

[b]# gcc --version[/b]
gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)

[b]# gcc-3.3 --version[/b]
gcc-3.3 (GCC) 3.3.6 (Ubuntu 1:3.3.6-8ubuntu1)

[b]# gcc-3.4 --version[/b]
gcc-3.4 (GCC) 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8.1)
#3
05/19/2006 (1:10 pm)
After installing gcc-3.3 and g++-3.3 and creating symbolic links 'gcc' and 'g++', I managed to compile a bit more (well, a little more than one bit :) ) .

Now, I again have a CPU-related issue: There seems to be something wrong with the following pushl and popl instructions in engine/platformX86UNIX/x86UNIXCPUInfo.cc:

__asm__(
         "pushl  eax\n"
         "pushl  edx\n"
         "rdtsc\n"
         "movl   eax, (time)\n"
         "movl   edx, (time+4)\n"
         "popl   edx\n"
         "popl   eax\n"
         );
asm(
         "pushl  eax\n"
         "pushl  edx\n"
         "rdtsc\n"
         "sub    (time+4), %edx\n"
         "sbb    (time), %eax\n"
         "mov    eax, (clockticks)\n"
         "popl   edx\n"
         "popl   eax\n"
         );

These are the errors I get before make quits:
{standard input}: Assembler messages:
{standard input}:149: Error: suffix or operands invalid for `push'
{standard input}:150: Error: suffix or operands invalid for `push'
{standard input}:152: Error: too many memory references for `mov'
{standard input}:153: Error: too many memory references for `mov'
{standard input}:154: Error: suffix or operands invalid for `pop'
{standard input}:155: Error: suffix or operands invalid for `pop'
{standard input}:175: Error: suffix or operands invalid for `push'
{standard input}:176: Error: suffix or operands invalid for `push'
{standard input}:180: Error: too many memory references for `mov'
{standard input}:181: Error: suffix or operands invalid for `pop'
{standard input}:182: Error: suffix or operands invalid for `pop'
make[1]: *** [out.GCC3.DEBUG/platformX86UNIX/x86UNIXCPUInfo.obj] Error 1

This time, I really don't have a clue on how to solve this (I'm not familiar this assembly language). Am I the first person who tried to compile Torque2D on 64-bit Linux?
What about Torque2D on other linuxes (for other processor types)? Maybe there's a way to disable the assembler code?
#4
05/21/2006 (12:48 pm)
Unfortunately, as of my last research, there are no publically available 64 bit nasm (assembly) compilers that can handle the issues here. The assembly language needs to be re-written for the new registers and number of params as you've noticed, but until a nasm compiler is available (and we aren't going to be writing one!), we're pretty stuck as well.
#5
05/23/2006 (10:02 am)
Thanks for the reply!

Isn't it possible to temporary replace the assembler code with equivalent C++ code?
#6
06/02/2006 (2:36 am)
I'm not sure about the relevancy, but I've tried to compile the Torque TGE with OpenSuSE 64-bit edition some months ago, and I failed miserably. Instead of using NASM, one could use YASM (a rebuilt-from-the-ground-up version of NASM) which is able to create 64-bit code. However, the ASM code you identified isn't written for 64-bit processors, so I'm not sure if it will work. Rewriting in C/C++ seems the most portable solution.

It sadly doesn't end there. It seems the engine design wasn't done with other processors in mind than 32-bit ones. That means that lots of code is written under the assumption that the integers are all 32-bit ones, which isn't correct under a 64-bit environment. The problem is most visible in the file/datablock loading part of the engine.

I can't seem to find the post atm, but somebody told me he was trying to get it to work for ages, and he hadn't yet succeeded. If you need this fast, you might want to consider installing the 32-bit building tools and building it like that...