Linux 1.4.2 CVS Head issues
by Todd "zaz" Koeckeritz · in Torque Game Engine · 09/30/2006 (6:43 pm) · 11 replies
I did a fresh pull from CVS on 28 Sep 2006 and built on my SuSE 10.0 box. During this exercise I ran into a few problems just building and also am noticing some problems with the code running under linux. I figured I'd start a thread here to notify others of what I've found and potentially collaborate on resolving some of the issues.
At some point, I'm hoping to either produce a patch or perhaps Ron or someone else can get the results of the work in this thread into CVS.
As a reference, here is how I build:
1) make -f mk/configure.mk OS=LINUX BUILD=RELEASE COMPILER=GCC4
2) make clean
3) make dedicated
4) make tools
5) make clean
6) make
Here are the problems I ran into:
1) gui/controls/guiListBoxCtrl.cc isn't included in the SOURCE.GUI definition in engine/targets.torque.mk
2) Stub Init::setCursorPos() is missing from engine/platformX86UNIX/x86UNIXDedicatedStub.cc
3) Because of the addition of Platform::restartInstance() to engine/platformX86UNIX/x86UNIXFileio.cc, the header file platform/gameInterface.h must be included.
NOTE: I tried moving Platform::restartInstance() to a different file to more closely match how its done in the windoze platform directory. This caused other issues though. The patch above resolves the basic sympton, but I'm not convinced its the best way to deal with the problem in the long term.
4) The library files lib/xiph/linux/lib* are apparently corrupt in CVS. I suspect this is because they have keyword substitution enabled on them. Someone with CVS write access could likely fix this with:
Its possible that the lib/xiph/linux/lib* will need to be updated in CVS after this, but specifying them as binary after the fact might resolve this. Its been awhile since I made this mistake myself, :-).
No real patch for this, but there are two work arounds linux developers can do. The easiest is to just delete the bad files:
You'll get some complaining during the build, but if you have all the necessary development libaries installed at your system level, the link should complete. This is likely to be ok, but for long term project management benefits, it would be better to link and build against known versions of these libraries.
A second and better way to resolve this problem is to download TorqueGameEngineSDK-1.4.2-RC1.bin installer from your account page, install it and then copy the good files from that installation into where you're building from CVS.
At some point, I'm hoping to either produce a patch or perhaps Ron or someone else can get the results of the work in this thread into CVS.
As a reference, here is how I build:
1) make -f mk/configure.mk OS=LINUX BUILD=RELEASE COMPILER=GCC4
2) make clean
3) make dedicated
4) make tools
5) make clean
6) make
Here are the problems I ran into:
1) gui/controls/guiListBoxCtrl.cc isn't included in the SOURCE.GUI definition in engine/targets.torque.mk
cvs -z3 diff engine/targets.torque.mk Index: engine/targets.torque.mk =================================================================== RCS file: /cvs/torque/torque/engine/targets.torque.mk,v retrieving revision 2.9 diff -r2.9 targets.torque.mk 159a160 > gui/controls/guiListBoxCtrl.cc \
2) Stub Init::setCursorPos() is missing from engine/platformX86UNIX/x86UNIXDedicatedStub.cc
cvs -z3 diff engine/platformX86UNIX/x86UNIXDedicatedStub.cc
Index: engine/platformX86UNIX/x86UNIXDedicatedStub.cc
===================================================================
RCS file: /cvs/torque/torque/engine/platformX86UNIX/x86UNIXDedicatedStub.cc,v
retrieving revision 2.4
diff -r2.4 x86UNIXDedicatedStub.cc
92a93
> void Input::setCursorPos(S32 x, S32 y) {}3) Because of the addition of Platform::restartInstance() to engine/platformX86UNIX/x86UNIXFileio.cc, the header file platform/gameInterface.h must be included.
cvs -z3 diff engine/platformX86UNIX/x86UNIXFileio.cc Index: engine/platformX86UNIX/x86UNIXFileio.cc =================================================================== RCS file: /cvs/torque/torque/engine/platformX86UNIX/x86UNIXFileio.cc,v retrieving revision 2.8 diff -r2.8 x86UNIXFileio.cc 36a37 > #include "platform/gameInterface.h"
NOTE: I tried moving Platform::restartInstance() to a different file to more closely match how its done in the windoze platform directory. This caused other issues though. The patch above resolves the basic sympton, but I'm not convinced its the best way to deal with the problem in the long term.
4) The library files lib/xiph/linux/lib* are apparently corrupt in CVS. I suspect this is because they have keyword substitution enabled on them. Someone with CVS write access could likely fix this with:
cvs admin -kb lib/xiph/linux/lib*
Its possible that the lib/xiph/linux/lib* will need to be updated in CVS after this, but specifying them as binary after the fact might resolve this. Its been awhile since I made this mistake myself, :-).
No real patch for this, but there are two work arounds linux developers can do. The easiest is to just delete the bad files:
rm lib/xiph/linux/lib*
You'll get some complaining during the build, but if you have all the necessary development libaries installed at your system level, the link should complete. This is likely to be ok, but for long term project management benefits, it would be better to link and build against known versions of these libraries.
A second and better way to resolve this problem is to download TorqueGameEngineSDK-1.4.2-RC1.bin installer from your account page, install it and then copy the good files from that installation into where you're building from CVS.
About the author
#2
I tracked down the problem for 2) above. It appears an edit was missed when some code dealing with directory recursion was changed. The patch below resolves this problem.
09/30/2006 (11:51 pm)
Updates on the above mentioned problems. 1) appears to have been caused by old .dso files. I'll make sure about it, but at this point I think that was the cause.I tracked down the problem for 2) above. It appears an edit was missed when some code dealing with directory recursion was changed. The patch below resolves this problem.
cvs -z3 diff -wc engine/platformX86UNIX/x86UNIXFileio.cc
Index: engine/platformX86UNIX/x86UNIXFileio.cc
===================================================================
RCS file: /cvs/torque/torque/engine/platformX86UNIX/x86UNIXFileio.cc,v
retrieving revision 2.8
diff -w -c -r2.8 x86UNIXFileio.cc
*** engine/platformX86UNIX/x86UNIXFileio.cc 2006/09/06 23:23:12 2.8
--- engine/platformX86UNIX/x86UNIXFileio.cc 2006/10/01 06:57:24
***************
*** 34,39 ****
--- 34,40 ----
#undef Status
#endif
+ #include "platform/gameInterface.h"
#include "platformX86UNIX/platformX86UNIX.h"
#include "core/fileio.h"
#include "core/tVector.h"
***************
*** 1163,1169 ****
bool Platform::dumpDirectories(const char *path, Vector<StringTableEntry> &directoryVector, S32 depth, bool noBasePath)
{
ResourceManager->initExcludedDirectories();
! bool retVal = recurseDumpDirectories(path, "", directoryVector, 0, depth, noBasePath);
clearExcludedDirectories();
return retVal;
}
--- 1164,1170 ----
bool Platform::dumpDirectories(const char *path, Vector<StringTableEntry> &directoryVector, S32 depth, bool noBasePath)
{
ResourceManager->initExcludedDirectories();
! bool retVal = recurseDumpDirectories(path, "", directoryVector, -1, depth, noBasePath);
clearExcludedDirectories();
return retVal;
} 
#3
You're a freakin genius, the x86UNIXFileio.cc stuff was driving me nuts!
Thank You, Thank You, Thank You.
10/06/2006 (4:24 am)
Todd, You're a freakin genius, the x86UNIXFileio.cc stuff was driving me nuts!
Thank You, Thank You, Thank You.
#4
Thanks for posting as it reminded me to file a bug report on that, :-).
10/06/2006 (2:02 pm)
You're welcome.Thanks for posting as it reminded me to file a bug report on that, :-).
#5
That file dialog patch was very helpful. I hadn't gotten around to tracking that down. Thanks!
Now, if you could also figure out why my world editor doesn't actually display any text for the widgets in Linux, I'll just go have a beer in the meanwhile :-)
10/06/2006 (3:15 pm)
I can confirm issues 1, 3 and 4 (I implemented the same fixes myself a week or two ago).That file dialog patch was very helpful. I hadn't gotten around to tracking that down. Thanks!
Now, if you could also figure out why my world editor doesn't actually display any text for the widgets in Linux, I'll just go have a beer in the meanwhile :-)
#6
Still good to get this all in one place though.
10/06/2006 (9:02 pm)
Yeah, I noticed some of the other posts, some of which I'd even posted to recently, that dealt with the same problems I mention. Oh well, I've been distracted with a family member in the hospital most of the summer and was working with my blinders on a bit there, :-).Still good to get this all in one place though.
#7
Sorry, forgot about the text issue problem you mentioned. Can you describe it a bit better, I haven't noticed any problems here on my end that I'd apply your description to.
10/06/2006 (9:27 pm)
@hplus:Sorry, forgot about the text issue problem you mentioned. Can you describe it a bit better, I haven't noticed any problems here on my end that I'd apply your description to.
#8
When entering the world editor inspector, and selecting some item in the tree view, the property grid shows up, but the label and value boxes all contain no text. It's as if it's measuring the text wrong, and deciding not to draw any of it.
I've heard that others don't have this problem, but given the variability of font support on various Linuxen, it just adds to the confusion.
I've seen it both on CentOS 4 and Fedora Core 5, btw.
10/07/2006 (11:22 am)
Quote:Can you describe it a bit better
When entering the world editor inspector, and selecting some item in the tree view, the property grid shows up, but the label and value boxes all contain no text. It's as if it's measuring the text wrong, and deciding not to draw any of it.
I've heard that others don't have this problem, but given the variability of font support on various Linuxen, it just adds to the confusion.
I've seen it both on CentOS 4 and Fedora Core 5, btw.
#9
Try deleting the font files in the common/ui/cache directory. They should be named something like Arial*.utf, etc. This will cause the platform code to rebuild the fonts. It might fix your problem or it might not, but at least you'll know your fonts are good and then need to look elsewhere for the problem.
10/07/2006 (1:30 pm)
I thought that's what you might be talking about.Try deleting the font files in the common/ui/cache directory. They should be named something like Arial*.utf, etc. This will cause the platform code to rebuild the fonts. It might fix your problem or it might not, but at least you'll know your fonts are good and then need to look elsewhere for the problem.
#10
There are also no real clues in the log, except for an error about not being able to find 'darkSlider' -- however, I get this error on Windows too, where the editor works.
Here's a screen shot:
10/07/2006 (4:14 pm)
I deleted the font cache; still no luck.There are also no real clues in the log, except for an error about not being able to find 'darkSlider' -- however, I get this error on Windows too, where the editor works.
Here's a screen shot:
#11
The font stuff under linux seems to be a tad hit and miss. I think I saw a few commits in a changelog somewhere for 1.5, but I'm not sure this issue is going to get resolved for 1.5 even.
10/08/2006 (5:53 pm)
Sorry, not sure what to tell you. I've seen that happen here before too, but I think only during testing just prior to the 1.4 TGE-L release.The font stuff under linux seems to be a tad hit and miss. I think I saw a few commits in a changelog somewhere for 1.5, but I'm not sure this issue is going to get resolved for 1.5 even.
Torque Owner Todd "zaz" Koeckeritz
1) Crashes on changing resolutions on a game of my own, but seems ok with the stuff in the examples directory. What happens is upon resolution change, torque starts consuming all of memory and most of swap and then crashes with a SEGV. No messages written to the console.log. Potentially something I need to change with my game, but it works fine against other recent versions of torque.
2) Using the dialog box used by -show to load shapes or in the mission editor to load terrain textures gives bad results. I think this is a GuiDirectoryTree issue, possibly an issue with how it interacts with stuff in x86UNIXFileio.cc functions/methods. It looks similar to stuff I provided fixes for in earlier releases of TGE, maybe they didn't get into CVS ?
What I see here is instead of directories from the root of where torque was started, I see full directory listings up to my filesystem root. I can't find any shapes to load in the dialog when I use the old -show showtool. I need to see how this works under windoze I think to really know how this should look.
That's as far as I've gotten for the moment. I'll try to add more to this thread when I have something. Feel free to help me flesh this out, :-).