TGE v1.5.2 fails to build with gcc v4.3.2
by Jamin Collins · in Technical Issues · 11/17/2008 (4:02 pm) · 6 replies
After upgrading to Ubuntu's 8.10 (Intrepid) release, it was found that TGE v1.5.2 would not successfully build any longer. The compile would proceed all the way to the final linking, but would then fail with the following output:
--> Linking out.GCC4.RELEASE/torqueDemo.bin
out.GCC4.RELEASE/platformX86UNIX/x86UNIXCPUInfo.obj: In function 'Processor::init()':
x86UNIXCPUInfo.cc:(.text+0x1bc): undefined reference to 'timeHi'
x86UNIXCPUInfo.cc:(.text+0x1c2): undefined reference to 'timeLo'
x86UNIXCPUInfo.cc:(.text+0x1c7): undefined reference to 'clockticks'
collect2: ld returned 1 exit status
make[1]: *** [out.GCC4.RELEASE/torqueDemo.bin] Error 1
make: *** [default] Error 2
From what I've been able to determine, this is due to some change in gcc. The same source compiles fine under gcc v4.2.4 but fails with gcc 4.3.2.
For now, I'm working around the problem by using the gcc-4.2 and g++-4.2 binaries, but thought I'd document the problem here for everyone and see if anyone knew what needs to change for gcc 4.3.2.
For those interested, here's the patch I'm using to work around the issue currently:
diff -Naur Torque1.5.2-Linux.orig/mk/conf.GCC4.mk Torque1.5.2-Linux/mk/conf.GCC4.mk
--- Torque1.5.2-Linux.orig/mk/conf.GCC4.mk 2007-05-11 20:58:32.000000000 +0000
+++ Torque1.5.2-Linux/mk/conf.GCC4.mk 2008-11-17 01:08:31.000000000 +0000
@@ -1,8 +1,8 @@
include ../mk/conf.GCC.mk
-COMPILER.c =gcc
+COMPILER.c =gcc-4.2
# -Wno-invalid-offsetof is only valid for g++ compilation, had to remove it from the CFLAGS variable seeing that we
# pass CFLAGS to both gcc and g++
-COMPILER.cc =g++ -Wno-invalid-offsetof
+COMPILER.cc =g++-4.2 -Wno-invalid-offsetof
CFLAGS += -mtune=i686
--> Linking out.GCC4.RELEASE/torqueDemo.bin
out.GCC4.RELEASE/platformX86UNIX/x86UNIXCPUInfo.obj: In function 'Processor::init()':
x86UNIXCPUInfo.cc:(.text+0x1bc): undefined reference to 'timeHi'
x86UNIXCPUInfo.cc:(.text+0x1c2): undefined reference to 'timeLo'
x86UNIXCPUInfo.cc:(.text+0x1c7): undefined reference to 'clockticks'
collect2: ld returned 1 exit status
make[1]: *** [out.GCC4.RELEASE/torqueDemo.bin] Error 1
make: *** [default] Error 2
From what I've been able to determine, this is due to some change in gcc. The same source compiles fine under gcc v4.2.4 but fails with gcc 4.3.2.
For now, I'm working around the problem by using the gcc-4.2 and g++-4.2 binaries, but thought I'd document the problem here for everyone and see if anyone knew what needs to change for gcc 4.3.2.
For those interested, here's the patch I'm using to work around the issue currently:
diff -Naur Torque1.5.2-Linux.orig/mk/conf.GCC4.mk Torque1.5.2-Linux/mk/conf.GCC4.mk
--- Torque1.5.2-Linux.orig/mk/conf.GCC4.mk 2007-05-11 20:58:32.000000000 +0000
+++ Torque1.5.2-Linux/mk/conf.GCC4.mk 2008-11-17 01:08:31.000000000 +0000
@@ -1,8 +1,8 @@
include ../mk/conf.GCC.mk
-COMPILER.c =gcc
+COMPILER.c =gcc-4.2
# -Wno-invalid-offsetof is only valid for g++ compilation, had to remove it from the CFLAGS variable seeing that we
# pass CFLAGS to both gcc and g++
-COMPILER.cc =g++ -Wno-invalid-offsetof
+COMPILER.cc =g++-4.2 -Wno-invalid-offsetof
CFLAGS += -mtune=i686
About the author
#2
01/13/2009 (10:56 am)
Any likelyhood of this or a more permanent fix getting added to the src tree soon?
#3
04/14/2009 (10:35 pm)
I also wonder about this. Is anyone knowledgeable enough to provide a more permanent patch?
#5
07/15/2009 (1:12 pm)
now i have all compiled, but when i start torqueDemo.bin, engine stay open as process, but don't shows window with startup splash, when is compiled in DEBUG mode works fine, but without OpenAL :(
#6
07/15/2009 (1:19 pm)
I will quote what I said before:Quote:I have not looked into it for months. I just compile on an older version of GCC. The reason you don't see anything is because all script does not work.
I have now noticed a new problem that so far I have not been able to fix and cannot spend too much time on at the moment. It appears that the new version of gcc is more aggressive in its optimization at the cost of backward compatibility. The first bug I have noticed so far is that the release build can not call any script functions. Opcode OP_CALLFUNC_RESOLVE (you can find it in engine/console/compiledEval.cc) seems to optimize into bad code and outputs a lot of "Unable to find function (null)" errors.
Torque Owner Wes Macdonald
--- trunk/engine/platformX86UNIX/x86UNIXCPUInfo.cc 2008/03/06 07:48:15 322 +++ trunk/engine/platformX86UNIX/x86UNIXCPUInfo.cc 2008/12/05 04:50:47 1299 @@ -77,14 +77,16 @@ ms = Platform::getRealMilliseconds()-ms; #if defined(TORQUE_COMPILER_GCC) && ((__GNUC__ >= 3) && (__GNUC_MINOR__ >= 4)) || ((__GNUC__ >= 4) && (__GNUC_MINOR__ >=0)) asm( - "pushl %eax\n" - "pushl %edx\n" + "pushl %%eax\n" + "pushl %%edx\n" "rdtsc\n" - "sub (timeHi), %edx\n" - "sbb (timeLo), %eax\n" - "mov %eax, (clockticks)\n" - "popl %edx\n" - "popl %eax\n" + "sub %1, %%edx\n" + "sbb %2, %%eax\n" + "mov %%eax, %0\n" + "popl %%edx\n" + "popl %%eax\n" + :"=r"(clockticks) + :"r"(timeHi),"r"(timeLo) ); #else asm(Basically the gcc compiler thinks that the symbols are never used because they are in the asm block. I'm not 100% sure what my changes do exactly because I do not write a lot of inline assembly. It seems to work for me but keep an eye on the rough cpu timing just to be sure.I have now noticed a new problem that so far I have not been able to fix and cannot spend too much time on at the moment. It appears that the new version of gcc is more aggressive in its optimization at the cost of backward compatibility. The first bug I have noticed so far is that the release build can not call any script functions. Opcode OP_CALLFUNC_RESOLVE (you can find it in engine/console/compiledEval.cc) seems to optimize into bad code and outputs a lot of "Unable to find function (null)" errors.
Builds from older versions of gcc work fine but the optimizations from the new compiler might give torque a small speed boost on Linux.