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).
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).
#2
09/09/2005 (4:33 pm)
I believe that some of those files are actually extraneous. I will confirm soon.
#3
09/09/2005 (4:38 pm)
Infblock.c is not needed. Neither is infutil.h if my project file is correct. CVS will be updated with the next drop.
#4
09/09/2005 (4:39 pm)
(Just to be clear - I won't be updating the Linux makefiles, though - that is Ron's bailiwick, and I haven't a Linux box handy for testing right now.)
#5
Creating library out.GCC3.RELEASE/lungif.a
mkdir: cannot create directory 'out.GCC3.RELEASE/gui/containers': No such file or directory
make[1]: *** [out.GCC3.RELEASE/gui/containers] Error 1
make: *** [default] Error 2
09/09/2005 (4:42 pm)
I removed infblock.c but get this.Creating library out.GCC3.RELEASE/lungif.a
mkdir: cannot create directory 'out.GCC3.RELEASE/gui/containers': No such file or directory
make[1]: *** [out.GCC3.RELEASE/gui/containers] Error 1
make: *** [default] Error 2
#6
Sorry, just posting problems as I find them - in case they need fixing. :)
09/09/2005 (4:55 pm)
./console/consoleObject.h:201: error: ISO C++ forbids declaration of 'ConsoleObject' with no typeSorry, just posting problems as I find them - in case they need fixing. :)
#7
make[1]: *** No rule to make target 'out.GCC3.4+.RELEASE/console/gram.obj', needed by 'out.GCC3.4+.RELEASE/torqueDemo.bin'. Stop.
make[1]: *** No rule to make target 'out.GCC3.4+.RELEASE/console/scan.obj', needed by 'out.GCC3.4+.RELEASE/torqueDemo.bin'. Stop.
09/09/2005 (5:01 pm)
Console/compiler.h:21:29: console/CMDgram.h: No such file or directorymake[1]: *** No rule to make target 'out.GCC3.4+.RELEASE/console/gram.obj', needed by 'out.GCC3.4+.RELEASE/torqueDemo.bin'. Stop.
make[1]: *** No rule to make target 'out.GCC3.4+.RELEASE/console/scan.obj', needed by 'out.GCC3.4+.RELEASE/torqueDemo.bin'. Stop.
#8
make[1]: *** No rule to make target 'out.GCC3.4+.RELEASE/gui/controls/guiOtherTreeViewCtrl.obj', needed by 'out.GCC3.4+.RELEASE/torqueDemo.bin'. Stop.
09/09/2005 (5:04 pm)
Make[1]: *** No rule to make target 'out.GCC3.4+.RELEASE/dgl/rectClipper.obj', needed by 'out.GCC3.4+.RELEASE/torqueDemo.bin'. Stop.make[1]: *** No rule to make target 'out.GCC3.4+.RELEASE/gui/controls/guiOtherTreeViewCtrl.obj', needed by 'out.GCC3.4+.RELEASE/torqueDemo.bin'. Stop.
#9
function)
09/09/2005 (5:09 pm)
PlatformX86UNIX/x86UNIXFileio.cc:336: 'Platorm' undeclared (first use thisfunction)
#10
Also, your makefile is EXTREMELY out of date. So there are a practically infinite number of possible errors to get...
09/09/2005 (7:09 pm)
Those files are gone!Also, your makefile is EXTREMELY out of date. So there are a practically infinite number of possible errors to get...
#11
The linux platform is a dark hole of hell right now ;) time to hop on bens little pony *snicker* and whip this b***h into shape
-Ron
09/10/2005 (5:49 am)
Oh boy!!!The linux platform is a dark hole of hell right now ;) time to hop on bens little pony *snicker* and whip this b***h into shape
-Ron
#12
09/10/2005 (7:55 am)
Don't forget us stubborn Cygwin users. I think we might be in a dark hole of hell right next to the Linux users. :p 
#13
As for any compiler errors, well, they're relatively easy to "fix".
This isn't rocket science. Its pretty darn simple :)
09/10/2005 (9:01 am)
I would recommend reviewing all the files that are in the torque vc7 project file, and adding them to your makefile where neccesary.As for any compiler errors, well, they're relatively easy to "fix".
This isn't rocket science. Its pretty darn simple :)
#14
You are partialy correct. There are loads of other 'new' features that are not even comprehended in the mac/linux platform. From reading Ben's .plan there is multi-threading, unicode etc.. all of which are not even in the mac/linux platform.
So, yes you can add missing files to the .mk file, but that will only get you what 25% of the way to a working TGE under mac/linux
-Ron
09/10/2005 (11:58 am)
James,You are partialy correct. There are loads of other 'new' features that are not even comprehended in the mac/linux platform. From reading Ben's .plan there is multi-threading, unicode etc.. all of which are not even in the mac/linux platform.
So, yes you can add missing files to the .mk file, but that will only get you what 25% of the way to a working TGE under mac/linux
-Ron
#15
09/11/2005 (7:19 pm)
Not true, Mac has all these things - just linux is a bit behind, because our internal Linux guy is currently working on some tight deadlines for an XBox 360 project. Mac will be getting an updated project file soon, and several community members are working on the Linux side. 
#16
10/07/2005 (4:13 pm)
On this note. Does TGE work with MinGW? I am thinking about creating a cross compiler, but I am scared away by Cygwin's license. MinGW's license looks much better. Also, Cygwin looks to be incompatible with the TGE license. Is this just a misconception by me?
#17
TGE 1.4RC2 _should_ compile with no issues using MingW under windows. Changes were pushed to SVN early last week (not sure when they will be pushed to CVS) that fixed several make file issues etc.
-Ron
10/08/2005 (10:06 am)
Frank,TGE 1.4RC2 _should_ compile with no issues using MingW under windows. Changes were pushed to SVN early last week (not sure when they will be pushed to CVS) that fixed several make file issues etc.
-Ron
#18
10/08/2005 (1:44 pm)
Thanks for the heads up. That will definitely keep my wheels from spinning.
#19
10/08/2005 (1:50 pm)
How's the Linux progress?
#20
Linux is coming along ok.. Unicode is kicking me in the a$$ right now, but should be clearing up with the excellent code Paul Scott pushed to SVN late last week.
Once I have the unicode squared away the linux plat of 1.4RC2 should be functional and ready for some serious testing.
I can not speak to when the changes will be pushed from SVN to CVS, that is a decision that far exceeds my capabilities and powers ;)
-Ron
10/08/2005 (4:22 pm)
Mike,Linux is coming along ok.. Unicode is kicking me in the a$$ right now, but should be clearing up with the excellent code Paul Scott pushed to SVN late last week.
Once I have the unicode squared away the linux plat of 1.4RC2 should be functional and ready for some serious testing.
I can not speak to when the changes will be pushed from SVN to CVS, that is a decision that far exceeds my capabilities and powers ;)
-Ron
Associate James Urquhart
I believe this is due to a problem with the configuration headers, as the previous copy of zlib in the CVS compiles fine.
For now, i have reverted my zlib back to the previous version. But the correct solution would be to determine what has changed in the config between revisions.