Game Development Community

1.4RC2 won't compile on GCC3.3 or GCC4.0.1 under Fedora Core 4

by Mike Stoddart · in Torque Game Engine · 09/09/2005 (4:24 pm) · 47 replies

I'm trying to compile 1.4RC2 on Fedora Core 4 with either GCC 3.3 or GCC 4.0.1.

I always get:

--> Compiling zlib/infblock.c
In file included from zlib/infblock.c:7:
zlib/infblock.h:14: error: syntax error before 'check_func'
In file included from zlib/infblock.c:9:
zlib/infcodes.h:14: error: syntax error before 'inflate_huft'
In file included from zlib/infblock.c:10:
zlib/infutil.h:16: error: redeclaration of enumerator 'LENS'
zlib/inftrees.h:49: error: previous definition of 'LENS' was here
zlib/infutil.h:21: error: redeclaration of enumerator 'CODES'
zlib/inftrees.h:48: error: previous definition of 'CODES' was here
zlib/infutil.h:41: error: syntax error before 'inflate_huft'
zlib/infutil.h:41: warning: no semicolon at end of struct or union
zlib/infutil.h:41: warning: no semicolon at end of struct or union
zlib/infutil.h:41: warning: no semicolon at end of struct or union
zlib/infutil.h:42: warning: data definition has no type or storage class
zlib/infutil.h:47: error: syntax error before '}' token
zlib/infutil.h:47: warning: data definition has no type or storage class
zlib/infutil.h:53: error: syntax error before '*' token
zlib/infutil.h:53: warning: data definition has no type or storage class
zlib/infutil.h:58: error: syntax error before 'checkfn'
zlib/infutil.h:58: warning: data definition has no type or storage class
zlib/infutil.h:61: error: syntax error before '}' token
zlib/infblock.c: In function 'inflate_blocks_reset':
zlib/infblock.c:74: error: dereferencing pointer to incomplete type
zlib/infblock.c:75: error: dereferencing pointer to incomplete type
zlib/infblock.c:75: error: dereferencing pointer to incomplete type
zlib/infblock.c:76: error: dereferencing pointer to incomplete type

I've tried using:

GCC 4.0.1 --> GCC3.4+ (conf.GCC3.4+.LINUX.mk)

GCC 3.3 --> GCC3 (conf.GCC3.LINUX.mk)

Anyone succeeded with this?

Thanks

(I'm assuming RC2 is available through HEAD).
#21
10/09/2005 (4:23 am)
For the unicodeconversion: this does its job pretty well and has no external references:

http://www.unicode.org/Public/PROGRAMS/CVTUTF/ConvertUTF.c
http://www.unicode.org/Public/PROGRAMS/CVTUTF/ConvertUTF.h

Im new to torque and cant compile 1.3 with gcc3.4 so i switched to
cvs, but cant compile it either. A working/compileable version on cvs
would be great ;)

On current cvs several headers have wrong upper/lowercase:

cmdgram.h
aiWheeledVehicle.h
debris.h
theoraplayer.h

Hope this helps,

Stefan
#22
10/25/2005 (10:52 am)
OK, i just did an update from cvs.
Most of the problems have been fixed i think. This are the problems i still have:

x86UNIXFont.h is missing on cvs.

Plattform::hasSubDirectory() and Plattform::dumpDirectories() are not implemented or not on cvs yet.

Stefan
#23
10/25/2005 (11:03 am)
Stefan,

Those changes will be comign shortly, I amd currently rewriting x86UNIXFont.cc to use XFT fonts. Should be in SVN either this evening or Wednesday evening (cant say when it will hit cvs).

hasSubDirectory and dumpDirectories should be in cvs, they were added to svn before IGC IIRC.... will check this evening when I get home

-Ron
#24
10/25/2005 (4:52 pm)
@Ron: I think Greg got bored this last weekend: Using XFT fonts on linux.
#25
10/25/2005 (6:28 pm)
Yeah,

I noticed the resource.. I have been trying to wrap my head around why we cant close the font as Greg indicates in his resource...

-Ron
#26
10/26/2005 (9:38 am)
Is the svn repository accesible for members?
Whats the URL? Cant find any info on this.

Stefan
#27
10/26/2005 (9:44 am)
SVN is closed to the public, it is GG's internal working repository. Once things are stable and functional in SVN GG goes through some process (I am not in the know of..) and pushes SVN to cvs for public consumption.

-Ron
#28
10/26/2005 (6:33 pm)
@Ron
I did some poking around, apparently there is a bug in XFT that is causing that. I suspected as much as I was getting really really odd crashes...

One crash would be a BadMatch, and some nonsense about a invalid polygon ?
Another was BadMatch, invalid operation?

HUH? Something screwy going on deep in X land.
I supose I should come up with a test case and fire it off to KeithP and see what he says.

I _think_ the semaphore stuff is horked up as well. Ive been tinkering with the theora control and been getting lots of asserts and crashing with it so I'm still digging there.

Here is the chunk, stripped from torque and all the ifdef mess cleaned out.
#include <fcntl.h>
#include <semaphore.h>
#include <sys/stat.h>
#include <errno.h>

int main (int argc, char **argv)
{
        sem_t *semaphore;
        semaphore = sem_open ("/tmp/eliteQueue.31337", O_CREAT | O_EXCL, S_IRUSR | S_IWUSR, 1);
        if (semaphore == SEM_FAILED)
        {
                printf ("Bah! sem_open failed. %s\n", strerror(errno));
                exit(-1);
        }
        printf ("Semaphore created.\n");
        exit (0);
}
gcc -o sem sem.c -lpthread

and run it.
I get
Bah! sem_open failed. No such file or directory
go figure..

If it by some miracle works for you, the semaphore should show up with ipcs.
remove it via ipcrm -s
#29
11/03/2005 (7:02 am)
So has anyone successfully compiled any torque under GCC 4.0 yet?
#30
11/03/2005 (8:05 am)
Cant speak officaly, but IIRC changes are being made to enable one to compile TGE using GCC 4.0 as well as GCC 3.4.*

-Ron
#31
11/05/2005 (1:17 am)
Kewl I hope they hurry it up, as is I can't get the dang thing to compile, unless I sacrifice a chicken under a full moon or something. Slowing me down because alot of things I'ld like to just implement in C++ I need to re-think and implement them in script instead, looks quite hackish, to be frank.
#32
11/05/2005 (2:06 am)
There's no "they" i this discussion. :) All linux support is currently run and implemented by the community. (Primarily by awesome folk like Ron who donate time and effort to make it happen.) We here at GG work to help make this happen, but ultimately it comes down to people like you, Ron, and Greg. (Among many others.)
#33
11/05/2005 (7:08 am)
@Dreamer
Try slyvester.gxsnmp.org/torque/patches/torque-cvs-head.patch and see if that gets the cvs head to build for you.

Apply via:

patch -p1

Couple of notes:
The targets.torque.mk hunks re-arranges the blocks to the same order as the vc7 project files (for my sanity mostly so I could do easier compares between the vc stuff and the makefile bits)

the openal hunks is some junk I was messing with and don't impact anything unless you call the functions ;)

The font code is my XFT font rendering stuff.

The semaphore stuff was my attempt at getting that stuff working. It sorta works now.

In any case this builds with gcc 3.4.4 so in theory it should build with 4.0 as well.
#34
11/06/2005 (6:34 am)
Thanks for the patch. It builds and runs nicely on my machine.
#35
11/07/2005 (12:35 am)
Ok, I applied the patch did a make clean && make here is the output.
./console/consoleObject.h:201: error: ISO C++ forbids declaration of 'ConsoleObject' with no type
./console/consoleObject.h:201: error: 'ConsoleObject' declared as a 'virtual' field
./console/consoleObject.h:201: error: expected ';' before '*' token
./console/consoleObject.h:258: error: ISO C++ forbids declaration of 'ConsoleObject' with no type
./console/consoleObject.h:258: error: expected ';' before '*' token
./console/consoleObject.h:259: error: ISO C++ forbids declaration of 'ConsoleObject' with no type
./console/consoleObject.h:259: error: expected ';' before '*' token
./console/consoleObject.h:358: error: ISO C++ forbids declaration of 'ConsoleObject' with no type
./console/consoleObject.h:358: error: expected ';' before '*' token
./console/consoleObject.h:359: error: expected ';' before '}' token
./console/consoleObject.h: In static member function 'static ConsoleObject* ConsoleObject::create(const char*)':
./console/consoleObject.h:628: error: 'create' is not a member of 'AbstractClassRep'
./console/consoleObject.h: In static member function 'static ConsoleObject* ConsoleObject::create(U32, U32, U32)':
./console/consoleObject.h:633: error: 'create' is not a member of 'AbstractClassRep'
./platform/event.h: At global scope:
./platform/event.h:128: warning: invalid access to non-static data member 'PacketReceiveEvent::data' of NULL object
./platform/event.h:128: warning: (perhaps the 'offsetof' macro was used incorrectly)
./platform/event.h:130: warning: invalid access to non-static data member 'ConnectedReceiveEvent::data' of NULL object
./platform/event.h:130: warning: (perhaps the 'offsetof' macro was used incorrectly)
./platform/event.h:132: warning: invalid access to non-static data member 'ConsoleEvent::data' of NULL object
./platform/event.h:132: warning: (perhaps the 'offsetof' macro was used incorrectly)
audio/audio.cc: In function 'int loopingImageSort(const void*, const void*)':
audio/audio.cc:157: warning: converting to 'int' from 'float'
audio/audio.cc: In function 'int streamingSourceSort(const void*, const void*)':
audio/audio.cc:189: warning: converting to 'int' from 'float'
audio/audio.cc: In function 'AUDIOHANDLE alxCreateSource(const Audio::Description*, const char*, const MatrixF*, AudioSampleEnvironment*)':
audio/audio.cc:703: warning: converting to non-pointer type 'ALuint' from NULL
audio/audio.cc: In function 'ALuint alxGetWaveLen(ALuint)':
audio/audio.cc:2091: warning: converting to 'ALuint' from 'F64'
make[1]: *** [out.GCC3.DEBUG/audio/audio.obj] Error 1
make: *** [default] Error 2

It did resolve alot of other errors.
Thoughts on what needs fixed here?

*edit*
Output of gcc -v for those interested
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
#36
11/07/2005 (4:33 am)
@Dreamer,

Search your engine dir for *.rej files, if you have any that would indicte that you need
to manualy patch those files...

cd to the engine dir and run
find . -type f -name '*.rej'

keep your eyes glued to GG's website, TGE 1.4.0 should drop very very soon now!!

-Ron
#37
11/07/2005 (1:55 pm)
@Dreamer,
The errors look like its not finding an include file look a bit higher on the compiler output to find the first error that triggers the rest.


The warnings are triggered by the offset macros and don't affect the build.
#38
11/13/2005 (8:58 am)
Gregory thanks for the patch its the first time since i got my amd64 system that i can compile torque on it. Unfortunately there is a really small typo at line 167 (i beleive) in audioFunctions.cc.

The line reads

Con:;printf("getDevices?\n");

but should be

Con::printf("getDevices?\n");
#39
11/13/2005 (9:36 am)
@Benoit,
Yeah that was my slip up, I was tinkering around with the OpenAL stuff and that function isn't really needed.
#40
11/15/2005 (1:18 pm)
Anyone get the tools to compile. I tried two machines (both mandriva 2006) using gcc 3.4.3 and 4.0.1 with make 3.80 and nothing works.