Linux Collaboration

#261 @Todd: I've been adding the newlines manually too, just to see how "clean" the compile log can be - it's nice to weed out those warnings... ;-) It'd be nice if we didn't have to "touch" every file to avoid these warnings tho'... which is why I asked Ron if there's anything that can be done. Certainly, the official release of TGE 1.4 for Linux should be cleaned up to avoid this.

#262 @EddieRay:
I'm running SuSE 9.3 here and have installed their libtheora-devel-1.0alpha4-3 and libtheora-1.0alpha4-3 RPMs. I get the message:

./torqueDemo.bin: /usr/lib/libtheora.so.0: no version information available (required by ./torqueDemo.bin)

when I run, but both the dedicated server and client run and the theora vids work in the client.

Are you running the dedicated server with the "-dedicated" command line switch/option ? That's required for the dedicated server to run.

#263 All,

Thanks for the updates! I am running short on time today to look into/comment on your feedback. Please give me some time to do my holiday shopping as well as spend time with the family. I will try and devote soem time to TGE over the next couple of evenings, please do not expect anything from me after 6PM Saturday till posible Monday or Tuesday evening.

-Ron

#264 It's picking up /usr/lib/libtheora.so.0 on your system - it's *supposed* to be using ../lib/xiph/linux/libtheora.so (which used to be called libtheora.so.0). Try renaming /usr/lib/libtheora.so.0 and see if it still works using runtorque.sh.

#265 @Ron: No problem... we don't *expect* anything from you... I think we're all pretty much "volunteers" here... ;-)

#266 Building on "SuSE 9.3" with "gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)" works for RELEASE and DEBUG on "make dedicated", "make" and "make tools" for me. The only changes I have from CVS atm are adding the newlines via the short script I posted above.

As mentioned above, I have SuSE's libtheora packages installed and expect I'm compiling against them. When I run both the client and server, I get:

./torqueDemo.bin: /usr/lib/libtheora.so.0: no version information available (required by ./torqueDemo.bin)

Probably a problem with my environment, but I mention it because EddieRay is having threora related problems also. This issue doesn't appear to be causing me any problems, just a nuisance message.

The client appears to run fine. I ran through the basic demo clicking on most of the buttons and messing around in the starter.fps and starter.racing demos briefly.

The server now runs (before it'd abort), however I'm getting lots of "onNeedRelight: Unknown command." errors in the server window and it sent most of the mission and files to the client when I was able to connect to the server with the client. This was for the starter.fps/data/missions/stronghold.mis mission.

Other issues I noticed here were that I had no health bar on the client, nor could I take damage trying to commit suicide by shooting the crossbow at my feet. When I found Kork, he was standing still and shooting him didn't damage him.

I admit to being a complete newb in running a dedicated server as I've never needed one, so maybe its user errors. I started the server with this command:

./torqueDemod.bin -dedicated -mod starter.fps -mission starter.fps/data/missions/stronghold.mis

I then started the client with "./torqueDemo.bin" in the same directory and clicked on the demo's "Example: FPS Multiplayer" and unclicked the "Create Server" checkbox there so I could connect to my local server.

#267 @Ron:
Bah humbug!!! Where's your dedication man?!?!?

j/k. Have a Merry Christmas and enjoy the holiday and time with your family and friends. I'm only posting the stuff I'm finding here now because I'm working with it. When you have time to deal with the issues, do it.

@EddieRay:

As far as updating the files that aren't terminated by newlines ... yeah, I agree on one hand that it'd be better if something didn't touch all the files. However, you only have to do it once and its a trivial solution, one that's easily scripted and portable to any posix system, i.e. nothing to compile, etc and if you have commit priviledges, you'll only actually commit the files that were modifed. Since you only need to do it once, it should at most cause one recompile of everything and if you're pulling CVS anyway, its likely you're going to be doing a "make clean" prior to a compile since its a safe thing to do.

If you really want to only touch the files that are missing the newlines, then you can do something similar to the following:

make clean
rm make.out
make dedicated >> make.out 2>&1
make clean
make >> make.out 2>&1
make tools >> make.out 2>&1
for i in 'grep newline make.out | cut -f1 -d: | sort -u'
do
echo $i
echo wq | ed $i > /dev/null 2>&1
done

Ok, to be honest, I didn't test the above and just typed it in, so there could easily be syntax, grammar, spelling or other mistakes in it, but if it isn't correct, its close, :-).

As far as libtheora, yeah, I see there's an issue. I haven't nailed it down yet, but at this point I'm thinking that torque is building against my system's vorbis and theora libs and then running against them. If I eliminate my system libs for theora torque doesn't find the libtheora it got from CVS, I assume the same will happen for borbis if I test it. I'll try looking at this a little bit to see if I can save Ron some effort when he gets back on the job.

#268 I think the problem with libtheora.so is that it was just renamed (instead of being rebuilt and relinked). Shared libraries have filenames embedded in them, so you can't just rename them and have other things that link against them work, AFAIK. If create a symlink called "libtheora.so.0" in the same directory (lib/xiph/linux) and pointing to libtheora.so.0, the executables work fine. The run-time loader is looking for libtheora.so.0 even though the file that was link was called libtheora.so.

It'd probably be best to stick with the same naming scheme used by the standard build of libtheora, which I'm guessing is libtheora.so.0. To fix this, we need to change mk/conf.UNIX.mk to use the name "libtheora.so.0" and we need to rename the file libtheora.so back to libtheora.so.0.

#269 @All: Happy Holidays!!! I'll be glad when it's actually here... and I can relax and spend time with my family instead of constantly "getting ready" for it all. ;-)

#270 Ok, I played around a bit with the theora and vorbis libraries and these are my findings.

I moved my vorbis and theora libs out of the way where the build process couldn't find them and then did "make clean; make". However, I didn't remove the packages, thus my header files for them were still available. I'm rebuilding now to insure that torque builds on my system without my system libvorbis-devel and libtheora-devel packages installed.

I did find at least one problem already though. Running ldd on torqueDemo.bin shows that it is expecting to dynamically link with libtheora.so.0 and libvorbis.so.0. In the lib/xiph/linux directory, there are only .so's in place there. If I do a symbolic link for the .0 files, torque runs fine against the libs from CVS, i.e.:

cd lib/xiph/linux
ln -s libtheora.so libtheora.so.0
ln -s libvorbis.so libvorbis.so.0

In looking at this problem, I was checking out the examples/runtorque.sh script and that while the LD_LIBRARY_PATH environment variable is set to include . and $GAME_HOME_PATH/lib (normally examples/lib) at the front of the variable as well as ../lib/xiph/linux at the end, there are currently no libraries in . (examples) and the $GAME_HOME_PATH/lib directory (examples/lib) doesn't even exist, let alone have any libraries.

To me this means two things. First, we're always going to use the user's system libraries, if they exist, for at least vorbis and theora as /usr/lib is the third directory referenced in the LD_LIBRARY_PATH environment variable. This is both good and bad and potentially dependent on issues specific to a game. I think as a whole it might be bad though in the event of incompatible changes to the libraries relative to what a game might be built against.

The second issue I see with this sort of depends on what one thinks the purpose of having the examples directory is. If one thinks that at least one of the reasons for the examples directory to exist is to provide a template for distribution to ease some of the issues with the 3 environments, it would be a better template/example if it included a lib directory and that lib directory was correctly populated. A side effect of this would be that the distrubuted demo from GG should be more stable as by default it'd be running against known versions of the libraries.

Ok, my build completed while I was typing this up. I do build and run ok once I've removed the libvorbis-devel and libtheora-devel packages, i.e. I'm using header files and stuff for sure from the torque CVS. I even reinstalled the -devel packages and added a #error pragma to /usr/include/theora/theora.h and rebuilt the theora .obj files to verify we were using the theora include files from CVS, this was good as well.

So, at this point I'm thinking that we're just dealing with the .so.0 naming issue and whatever someone wants to do to cleanup the LD_LIBRARY_PATH issues I pointed out above.

#271 With LD_LIBRARY_PATH set as it is currently in runtorque.sh:

LD_LIBRARY_PATH=.:${GAME_HOME_PATH}/lib:${LD_LIBRARY_PATH}:../lib/openal/LINUX:../lib/xiph/linux

The user can set LD_LIBRARY_PATH to whatever they want, if they want to override the "xiph" versions... but when LD_LIBRARY_PATH is not set before running runtorque.sh, it will use the "xiph" versions (theoretically, once we get back to a working filenaming scheme). The "." entry in LD_LIBRARY_PATH is not needed (technically), but it provides a way for devs to put copies of the theora, ogg and vorbis libs into the same directory as the executable, and allow (edit:) developers to support a simple "cd gamedir; ./rungame" process for their users. Likewise, the "${GAME_HOME_PATH}/lib" entry provides a similar function for those who want to tell their users to run "/usr/local/coolgame/installdir/runcoolgame" and be done with it (provided they create a lib directory and put the shared libraries there).

The "../lib/xiph/linux" entry is really only there to support devs - they can build the game and run it from the example directory (or their own game directory at the same level) and pick up the libs without having to copy them into each game directory (or gamedir/lib). When it comes time to produce a stand-alone tarball or ZIP of the game folder, they'll need to decide on which method (above) they prefer to use for providing libraries for theora, ogg, vorbis and they won't have to rebuild the game or change LD_LIBRARY_PATH if the use one of the above schemes.

I don't think there's anything inherently wrong with this setup. For me, I don't *want* TGE to pick up system libraries since they are old and don't work very well compared to the ones included in lib/xiph/linux. We plan on including the particular libs we prefer along with our game executable (so end-users don't need to install extra packages to get them in /usr/lib - but "power users" can try if they want, etc.).

As I said, the current linker problems appear to stem from the fact that the shared libraries in lib/xiph/linux have been *renamed* and conf.UNIX.mk (edit typo:) has been changed to use the new name (but without rebuilding the libs from source using the new names at compile time). If you symlink them with the proper names (blah.so.0), or copy them (with the proper names) to one of the valid paths expected by runtorque.sh, everything will work okay. But as it is now, the renamed libs are causing unneeded confusion and making it very easy to NOT get the proper libs running with the game. Running "ldd" on the game executable at the point in runtorque.sh before it actually runs EXENAME can reveal some "suprises" about which libs are actually getting used (unintended libs can be picked up without any warning - maybe the stock runtorque.sh should warn whenever ../lib/xiph/linux versions of the libs are not being used...).

#272 Fedora core 3 dvd - no updates
g++ (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

compiling but seg fault on running...

I cheated on the mandrake9.2 install by installing vorbis/theora/ogg through tar.gzs and then mandrake9.2 works ok.
On fedora core 3, I haven't cheated yet and wanted to see if torque would work without me using the tar.gzs myself.
When I check the install from the dvd, i see
rpm -qa |grep theora
libtheora-1.0alpha3-5

it compiles ok.
So i run it and...

sh r*sh debug
./torqueDemo_DEBUG.bin: /usr/lib/libtheora.so.0: no version information available (required by ./torqueDemo_DEBUG.bin)
Segmentation fault

ldd t*G.bin
./torqueDemo_DEBUG.bin: /usr/lib/libtheora.so.0: no version information available (required by ./torqueDemo_DEBUG.bin)
libogg.so.0 => /usr/lib/libogg.so.0 (0x05564000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x0556b000)
libtheora.so.0 => /usr/lib/libtheora.so.0 (0xf6fca000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x0596a000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d85000)
libdl.so.2 => /lib/libdl.so.2 (0x00d5d000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x0025b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x04268000)
libm.so.6 => /lib/tls/libm.so.6 (0x00d38000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00302000)
libc.so.6 => /lib/tls/libc.so.6 (0x00c0f000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00101000)
libasound.so.2 => /lib/libasound.so.2 (0x05047000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00d75000)
/lib/ld-linux.so.2 (0x003db000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x00dde000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00233000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00dbd000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x001ca000)
libz.so.1 => /usr/lib/libz.so.1 (0x00d63000)

#273 @Charles: Try these commands from the top of your checkout tree to fix the naming problem with the libraries:

ln -s libogg.so lib/xiph/linux/libogg.so.0
ln -s libvorbis.so lib/xiph/linux/libvorbis.so.0
ln -s libtheora.so lib/xiph/linux/libtheora.so.0

Then you should be able to do:

cd example
sh runtorque.sh
sh runtorque.sh -game starter.fps

or

cd example
LD_LIBRARY_PATH=../lib/xiph/linux
export LD_LIBRARY_PATH
./torqueDemo_DEBUG.bin
./torqueDemo_DEBUG.bin -game starter.fps

...etc. Your crash is likely being caused by the fact that you've compiled TGE using it's own copies of the headers for libtheora, etc., but the executable is running with old system versions of these libraries instead of the ones included with TGE in lib/xiph/linux... and they're likely incompatible.

#274 @Charles: Better yet... check to see what "ldd" says before running the executable:

cd example
LD_LIBRARY_PATH=../lib/xiph/linux
export LD_LIBRARY_PATH
ldd ./torqueDemo_DEBUG.bin

It should be picking up the ones in ../lib/xiph/linux - something like this:

% ldd ./torqueDemo.bin
        linux-gate.so.1 =>  (0xffffe000)
        libogg.so.0 => ../lib/xiph/linux/libogg.so.0 (0x40016000)
        libvorbis.so.0 => ../lib/xiph/linux/libvorbis.so.0 (0x4001b000)
        libtheora.so.0 => ../lib/xiph/linux/libtheora.so.0 (0x40042000)
        libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x40075000)
...

#275 @Ron: I think we're on the same page regarding LD_LIBRARY_PATH... ;-)

#276 @EddieRay:
Also, somes distros may set LD_LIBRARY_PATH via /etc/profile or other mechanism. Many users I'd expect have set LD_LIBRARY_PATH already for numerous reasons. If set, there is a very high chance its going to include places like /usr/lib and /usr/local/lib where its likely the vorbis and theora and other libraries are installed, which is then going to cause the current runtorque.sh to not use the libs from CVS. I'm just clarifying this point.

Generally I agree with what you're saying. A developer should build their game against a known set of libraries and in many cases ship those libraries with the game, at least for libs like theora and vorbis, and insure the default way of running uses the libraries shipped with the game.

I don't think that what is currently implemented is wrong beyond reclaimation, only that the entirety of what's there now isn't complete and not as good of an example for someone, especially someone not very familar with linux/unix, to use as their template for releasing a game.

Now, how much effort gets put into resolving this more completely now, by us or GG, is another question.

Good catch on the naming thing, I wasn't thinking about the .so's storing their name, that's indeed probably what happened.

#277

Quote:
Also, somes distros may set LD_LIBRARY_PATH via /etc/profile or other mechanism. Many users I'd expect have set LD_LIBRARY_PATH already for numerous reasons. If set, there is a very high chance its going to include places like /usr/lib and /usr/local/lib where its likely the vorbis and theora and other libraries are installed, which is then going to cause the current runtorque.sh to not use the libs from CVS. I'm just clarifying this point.

This will only affect dev users, the LD_LIBRARY_PATH in the runtorque.sh first checks "." tehn "gamedir/lib"
then whatever is in the systems LD_LIRBRARY_PATH.

-Ron

#278 Quick note on running a dedicated server on linux:

You should include the -nohomedir setting within your command line:

./torqueDemod.bin -dedicated -nohomedir -mod starter.fps -mission starter.fps/data/missions/stronghold.mis

Quite honestly I can't remember the exact logic for this, but it has to do with the fact that homedir operations are different in *nix than Windoze, so we want to make sure we use the proper executable root dir for file ops while running.

Also, the -mod starter.fps is only needed if you don't set the $defaultGame in your scripts.

#279 I agree, Ron. And devs can make a more restrictive "runmygame.sh" (based on runtorque.sh) for the end-users, that only includes entries in LD_LIBRARY_PATH that are desired.

I agree Todd with your point about the TGE runtorque.sh (and "stuff") being a "template".

Game devs who want to release a game on Linux need to be intimately familiar with all this stuff anyway (or their in for a heap of emails). ;-) Better documentation on the operation of runtorque.sh could be added as comments at the top of the file... to mention where the game executable should go, where it will look for the four libraries, etc.

So... now we just need to go back to using the ".so.0" filenames and fix conf.UNIX.mk to reference them...?

Cheers,

Ed

#280 @Stephen: Is it possible that the "-nohomedir" flag tells the dedicated server to NOT use the normal *nix ~/.garagegames/torqueDemo/ storage for .dso files, mission lighting cache files, etc.? That's what it sounds like. I wonder if that means it'll start creating .dso files under example/ in this case, or better yet, not cache things at all... hmmmm...

Thanks for the tip... I'll have to take a look at the code. I must admit... I too am a "dedicated server" noob with TGE... ;-)