Linux Collaboration
by Ben Garney · in Torque Game Engine · 11/24/2005 (1:18 am) · 490 replies
Hey guys,
Based on the discussion happening at Jeff's .plan, I'm starting a thread here in the private forums so that Linux Torque developers who are interested in seeing stronger Linux support can get more involved in the development process.
This is also a chance to help get more Torque projects onto Linux. There's a bit of a shortage of reliable Linux-enabled developers that are willing to do builds, help port, etc.
So if you want to see across-the-board Linux support happen, you're a good dev, and you're willing to donate a little time to the cause, consider volunteering. :)
(And don't think this is a thankless job, either - of the four Linux guys I've worked with, one now works at GG doing XBox 360 development, one does builds for many games, one is able to make money doing contract work, and another is working on a kick ass RTS with a now-GG-employee... This is a great opportunity to get more involved in professional game dev, get some nice perks, or just earn the respect & adulation of your peers.)
Having a list of people who are interested in this sort of thing will be a big boost to anyone trying to get their product on Linux, including things like GG getting future Torque releases out. :) Instead of scouring the web, people can just check here. Fast, quick, easy.
Thanks for taking the time to get involved!
Ben
Based on the discussion happening at Jeff's .plan, I'm starting a thread here in the private forums so that Linux Torque developers who are interested in seeing stronger Linux support can get more involved in the development process.
This is also a chance to help get more Torque projects onto Linux. There's a bit of a shortage of reliable Linux-enabled developers that are willing to do builds, help port, etc.
So if you want to see across-the-board Linux support happen, you're a good dev, and you're willing to donate a little time to the cause, consider volunteering. :)
(And don't think this is a thankless job, either - of the four Linux guys I've worked with, one now works at GG doing XBox 360 development, one does builds for many games, one is able to make money doing contract work, and another is working on a kick ass RTS with a now-GG-employee... This is a great opportunity to get more involved in professional game dev, get some nice perks, or just earn the respect & adulation of your peers.)
Having a list of people who are interested in this sort of thing will be a big boost to anyone trying to get their product on Linux, including things like GG getting future Torque releases out. :) Instead of scouring the web, people can just check here. Fast, quick, easy.
Thanks for taking the time to get involved!
Ben
#222
basicly just need to for loop over the entire source tree and add a new line to the end of every .cc and .h file.
GCC 2.95 needs an addition to the conf.GCC2.mk file to bring in the proper pthread defines, this fix has been made and will be checked in shortly.
The following options are now available for the COMPILER= argument
-Ron
12/16/2005 (4:59 am)
Could someone pull the latest CVS and send me a patch that resolves the 'warning: no newline at end of file' messages?basicly just need to for loop over the entire source tree and add a new line to the end of every .cc and .h file.
GCC 2.95 needs an addition to the conf.GCC2.mk file to bring in the proper pthread defines, this fix has been made and will be checked in shortly.
The following options are now available for the COMPILER= argument
GCC2 - builds all release/debug versions of tools, game, client and dedicated GCC3 - builds all release/debug versions of tools, game, client and dedicated GCC3.4 - builds all release/debug versions of tools, game, client and dedicated GCC4 - comming soon, need to test dedicated build and tools
-Ron
#223
Has anyone done this yet ? If not, I'm looking at it right now ... since this is sort of one of my pet peeves, :-).
12/16/2005 (10:25 am)
Quote:Could someone pull the latest CVS and send me a patch that resolves the 'warning: no newline at end of file' messages?
Has anyone done this yet ? If not, I'm looking at it right now ... since this is sort of one of my pet peeves, :-).
#224
I've sent the file directly to Ron as well.
I had to add -L/usr/X11R6/lib to LINK.LIBS.SERVER in mk/conf.UNIX.mk to get the dedicated to compile, but other than that everything compiled here. I'll be playing with it a bit to see if I notice any problems.
12/16/2005 (11:12 am)
I pulled the latest CVS about 12:15 Central time today and compiled everything, then checked the output for "no newline" errors. I fixed those files and did a "cvs -z3 diff -u" and saved that output. The output is available at: www.visi.com/~zaz/no-newlines.patch.txtI've sent the file directly to Ron as well.
I had to add -L/usr/X11R6/lib to LINK.LIBS.SERVER in mk/conf.UNIX.mk to get the dedicated to compile, but other than that everything compiled here. I'll be playing with it a bit to see if I notice any problems.
#225
The '-L/usr/X11R6/lib' fix is in SVN just needs to be synced to CVS
-Ron
12/16/2005 (11:27 am)
@Todd,The '-L/usr/X11R6/lib' fix is in SVN just needs to be synced to CVS
-Ron
#226
12/16/2005 (11:36 am)
Question - for the offset warnings, is there a pragma we could use to turn just those warnings off? It's ridiculously annoying & confusing, and a selective disable might be better than lowering the warning level overall.
#227
I am unsure, spent a few hours last night diffing through GCC info sites tracking down which versions support the -Wno-invalid-offsetof param. I'll do some searchign around for a progma
-Ron
12/16/2005 (11:58 am)
Ben,I am unsure, spent a few hours last night diffing through GCC info sites tracking down which versions support the -Wno-invalid-offsetof param. I'll do some searchign around for a progma
-Ron
#228
12/16/2005 (12:41 pm)
Wouldn't it be best and easiest to just export it as a CFLAG?
#229
Yes and No, not ever version of GCC supports the flag. It would be best to find a solution that is usable by all supported versions of GCC
-Ron
12/16/2005 (1:39 pm)
@Dreamer:Yes and No, not ever version of GCC supports the flag. It would be best to find a solution that is usable by all supported versions of GCC
-Ron
#230
12/16/2005 (1:41 pm)
Wouldn't it be better to fix the warning messages instead of turning them off? They do show up for a reason and for the long term would be a better solution.
#231
12/16/2005 (2:15 pm)
Fixes are welcome - I suspect it's mostly that GCC wants to discourage people from accessing data directly via pointer offsets. :)
#232
might prove to be a daunting task, though I have not looked at it myself. Most of the classes that we are trying to offsetof are non-POD (more than likely because of illegal C data members)
-Ron
12/16/2005 (3:01 pm)
I think changing the code to be POD compliantQuote:
POD - "Plain Old Data" - (roughly) a class that doesn't contain data members that would be illegal in C. A POD can therefore be used for data that needs to be share with C functions. A POD can have non-virtual member functions.
might prove to be a daunting task, though I have not looked at it myself. Most of the classes that we are trying to offsetof are non-POD (more than likely because of illegal C data members)
-Ron
#233
12/16/2005 (4:39 pm)
To be fair, GCC is right in warning us - it's kind of a dangerous thing to blithely do. But we do actually know what we're doing, and we've been doing it for a long while, so in this case it's safe to just tell it to shut up. :)
#234
12/16/2005 (6:59 pm)
To add to the list of distros it works on... it compiles & runs fine on Slackware 10.2 with GCC 3.3.6.
#235
You can read more here in case you missed it. For all others invlolved in the TGE Linux community support, keep up the good work!
12/17/2005 (1:51 am)
This thread has become mostly about compiling TGE, but I'd like to announce my small contribution to Linux. I'm making a map2dif GUI for both Linux and Windows.You can read more here in case you missed it. For all others invlolved in the TGE Linux community support, keep up the good work!
#236
Regarding the missing -Wno-invalid-offsetof feature in gcc 3.3.x or previous, we shouldn't *need* the flag - the previous version of the "Offset()" macro should still work correctly with pre-gcc-3.4.x compilers (unless some ooopse has been made).
It's late and I'm babbling at this point, so I hope this makes some sense to someone... ;-)
12/17/2005 (11:17 pm)
Regarding the -Wno-invalid-offsetof, we're already including it in CFLAGS for gcc 3.4.X, aren't we? I'm not sure why this is not stopping the warnings... it used to work in TGE 1.3. At that point, with gcc 3.4.x, we had to change the "Offset()" macro for gcc 3.4.X (in console/consoleTypes.h, platform/event.h) just to get TGE to compile - see the #ifdef's that exist there now.Regarding the missing -Wno-invalid-offsetof feature in gcc 3.3.x or previous, we shouldn't *need* the flag - the previous version of the "Offset()" macro should still work correctly with pre-gcc-3.4.x compilers (unless some ooopse has been made).
It's late and I'm babbling at this point, so I hope this makes some sense to someone... ;-)
#237
@$(COMPILER.cc) $(CFLAGS) $(CCFLAGS) -I. $(PATH.H.SYS) -c -o $(@) $(<)
and the switch took affect.
FYI,
I am compiling this on FC4 (gcc 4.0.1, glibc 2.3.5). It compiles but has problems with fonts (not unexpected, I have not added Arial yet)
1) segfaults trying to lowercase helvetica. This is because "helvetica" is coded as a string literal and gets placed in read only protected memory (there is probably a switch for this one, but I just changed the code to use an initialized static char [])
2) After changing (1), it fails because of too many connections to the X server. This one is because FC4 does not have helvetica at a size of 30 so the font load fails and returns without closing its connection to the display (x86UNIXFont::create).
3) I changed (2) and adjusted to a font that I do have (luxi sans, luxi mono) and Torque comes up. However the graphics are 'smeared' across the screen. Torque does seem to respond to mouse clicks etc, it just looks like a single vertical line of each graphics element is scaled to the width of the element. (artistic, but not useful :) This is where I am at the moment. I hope to have time over the next week to work this out.
...scott
12/18/2005 (8:23 am)
In the code I have (CVS on 2005-12-15) the switch -Wno-invalid-offsetof is set in the CCFLAGS in conf.GCC.3.4.mk (not CFLAGS) and the compile line for C++ files in conf.GCC.mk does not reference CCFLAGS. I changed the compile line to:@$(COMPILER.cc) $(CFLAGS) $(CCFLAGS) -I. $(PATH.H.SYS) -c -o $(@) $(<)
and the switch took affect.
FYI,
I am compiling this on FC4 (gcc 4.0.1, glibc 2.3.5). It compiles but has problems with fonts (not unexpected, I have not added Arial yet)
1) segfaults trying to lowercase helvetica. This is because "helvetica" is coded as a string literal and gets placed in read only protected memory (there is probably a switch for this one, but I just changed the code to use an initialized static char [])
2) After changing (1), it fails because of too many connections to the X server. This one is because FC4 does not have helvetica at a size of 30 so the font load fails and returns without closing its connection to the display (x86UNIXFont::create).
3) I changed (2) and adjusted to a font that I do have (luxi sans, luxi mono) and Torque comes up. However the graphics are 'smeared' across the screen. Torque does seem to respond to mouse clicks etc, it just looks like a single vertical line of each graphics element is scaled to the width of the element. (artistic, but not useful :) This is where I am at the moment. I hope to have time over the next week to work this out.
...scott
#238
That has been resolved and is in SVN awaiting CVS sync. I made several other changes to the mk/*.mk files as well.
If you do resolve your FC4 issues please send them to me in way of a unified diff patch
@EddieRay:
I have not touched the offset code, will have to compare what is in CVS/SVN to an earlier (possibly 1.3 tag) to see if anything as changed
-Ron
12/18/2005 (8:29 am)
@Scott:That has been resolved and is in SVN awaiting CVS sync. I made several other changes to the mk/*.mk files as well.
If you do resolve your FC4 issues please send them to me in way of a unified diff patch
@EddieRay:
I have not touched the offset code, will have to compare what is in CVS/SVN to an earlier (possibly 1.3 tag) to see if anything as changed
-Ron
#239
The above log has been sent to GG for CVS sync'ing
-Ron
12/18/2005 (1:52 pm)
SVN check-in log sense 12/15Revision: 1196 Author: ryacketta Date: 10:08:23 PM, Thursday, December 15, 2005 Message: RJY: removed the loading of creator mod for dedicated builds ---- Modified : /trunk/example/main.cs Modified : /trunk/example/main.demo.cs Modified : /trunk/example/main.sdk.cs Revision: 1197 Author: ryacketta Date: 10:09:18 PM, Thursday, December 15, 2005 Message: RJY Updated build/compile scripts to properly handle the example/lib directory also updated project.xml so that the lib dir is built into the installer ---- Modified : /trunk/install_build/build.sh Modified : /trunk/install_build/compile.sh Modified : /trunk/install_build/demo/linux/project.xml Revision: 1198 Author: ryacketta Date: 10:13:07 PM, Thursday, December 15, 2005 Message: RJY Updated the lib paths for vorbis ---- Modified : /trunk/example/runtorque.sh Revision: 1199 Author: ryacketta Date: 10:14:37 PM, Thursday, December 15, 2005 Message: RJY renamed lib files to there standard usage format ---- Added : /trunk/lib/xiph/linux/libogg.so Deleted : /trunk/lib/xiph/linux/libogg.so.0 Added : /trunk/lib/xiph/linux/libtheora.so Deleted : /trunk/lib/xiph/linux/libtheora.so.0 Added : /trunk/lib/xiph/linux/libvorbis.so Deleted : /trunk/lib/xiph/linux/libvorbis.so.0 Revision: 1200 Author: ryacketta Date: 10:16:26 PM, Thursday, December 15, 2005 Message: RJY updated conf.UNIX.mk to use the new ogg, vorbis and theora lib names ---- Modified : /trunk/mk/conf.UNIX.mk Revision: 1201 Author: ryacketta Date: 12:28:19 AM, Friday, December 16, 2005 Message: RJY Had to move around the -Wno-invalid-offsetof compiler option, it is only valid for c++ compiles ---- Modified : /trunk/mk/conf.GCC3.4.mk Revision: 1202 Author: ryacketta Date: 12:33:18 AM, Friday, December 16, 2005 Message: RJY First pass at adding gcc-4.*.* compiler settings ---- Added : /trunk/mk/conf.GCC4.LINUX.mk Added : /trunk/mk/conf.GCC4.WIN32.mk Added : /trunk/mk/conf.GCC4.mk Modified : /trunk/mk/configure.mk Revision: 1203 Author: ryacketta Date: 8:48:26 AM, Friday, December 16, 2005 Message: RJY Added -D_GNU_SOURCE for pthreads ---- Modified : /trunk/mk/conf.GCC2.mk
The above log has been sent to GG for CVS sync'ing
-Ron
#240
I'm not sure what the deal is with the log "box" in your previous post, but I can't see anything inside it (Firefox 1.06)...
@Scott: Good catch!
Now that the CCFLAGS issue has been found, I starting to remember how the "-Wno-invalid-offsetof" is not a C compiler switch, but a C++ compiler switch, so it does make sense to have it listed with the C++ flags and not the C flags.
Cheers,
Ed
12/18/2005 (9:25 pm)
@Ron: Sorry... didn't mean to imply that you had changed the "-Wno-invalid-offsetof" setting - I meant that between TGE1.3 and TGE 1.4 (before RC1) there were some changes to help with the gcc 3.4.x problem and that was when the #ifdef's were added to "fix" this problem.I'm not sure what the deal is with the log "box" in your previous post, but I can't see anything inside it (Firefox 1.06)...
@Scott: Good catch!
Now that the CCFLAGS issue has been found, I starting to remember how the "-Wno-invalid-offsetof" is not a C compiler switch, but a C++ compiler switch, so it does make sense to have it listed with the C++ flags and not the C flags.
Cheers,
Ed
Torque Owner Dreamer
Default Studio Name