Required changes to the Torque3D to make it Linux-compatible.

[just-bank]

I've got Torque 3D MIT (dedicated build only) running on Linux box (OpenSUSE 12.1 x64).
Also, got successfully connected from Windows 7 build (based on same sources) via LAN.

This doesn't change any functionality, so everything will work the same way as a stock version.

Build instructions (assuming my changes are applied to the code base):

cd Templates/Full
./generateProjects.command
cd buildFiles/Make_Ded
make clean
make debug
cd ../../game
./Full_DEBUG -dedicated -mission levels/myCustomLevel.mis

Keep in mind, that mission files should not contain spaces in its name.
Also, if you make custom/own projects, I would recommend to store it under Torque3D/Projects folder instead of Torque3D/My Projects so it doesn't contain spaces in folder name. It will save you a lot of headaches.

[jamesu]

Compiled this in Ubuntu x64 with the packages build-essential, nasm, git, php5-cli, libsdl-dev and libogg-dev. Seems to work fine, though when compiling it ignored some of the ogg headers in the engine which is why libogg-dev was required.

I was also able to load a mission with spaces in the filename, e.g.:

./Full_DEBUG -dedicated -mission levels/Empty\ Terrain.mis

Also managed to connect with a windows client using this code with TORQUE_APP_NAME set to "Full" using:

Full.exe -connect <ip address>

However I was unable to connect to the server using a stock 1.2 MIT client. It seems the changes made to the ShadowMapParams have broken something in the netcode when reading "cookie" in "ShadowMapParams::unpackUpdate".

Otherwise great work!

[just-bank]

Yeah, unfortunately it doesn't work with stock MIT client :( ... so the changes should be applied on both - the linux server and windows client.

[jamesu]

Judging by the LightMapType stuff, it seems your code is creating an empty light type the first time you initialise the light types with "LightInfoExType ShadowMapParams::Type( "" );" which appears to screw up the netcode which sends empty strings.

If I remove the added module init and change the lines to:

LightInfoExType ShadowMapParams::Type( "ShadowMapParams" );
LightInfoExType LightMapParams::Type( "LightMapParams" );

It allows 1.2 clients to connect and still compiles, at least with GCC 4.6.3.

[just-bank]

So, it does start up on Linux? I was getting a crash until I moved setting the type to the MODULE-stuff.
My thought on why it works without the change for you at the end this message.
I'll go back in time..
That change was intentional and the root of this was much more deeper than it can look.
It was done back in fall-2009 / spring-2010.
I remember a long discussion with Rene Damm when we tried to make T3D to be compatible with Linux and he had to rewrite some core stuff in the engine... Mostly solving the ordering of global constructors (GG can look at the commits r31870, r29526 and r26588).
There is a note in docs about similar issue (added by Rene on March 31, 2010):
http://docs.garagegames.com/torque-3d/official/content/documentation/Scripting/Advanced/EngineInterface.html

Due to the template trickery involved in the engineAPI macro system, default argument values will be constructed once during global startup (except if the compiler is smart enough to optimize the non-side-effecting constructors away). This means that any default argument value must not use a feature of Torque that requires global ctors to have executed. Using String::EmptyString is an example of what would not work.

That comment is not directly about LightInfoExType (it was only about engineAPI macro usage), but without that change I was getting crashes on Linux.
It could be that GCC 4.6.3 works fine because something got changed in GCC, but I was working with 4.3.x and 4.5.x.
I'll revert those and try running T3D on some of my test boxes with different GCC versions.

[DavidWyand-GG]

I'm attempting to compile under RedHat Linux 6.3 64bit on an Amazon micro instance (ami-cc5af9a5). I've installed the following packages: "Development Tools" group, php, SDL-devel, SDL-static, libogg-devel, and nasm. Everything seems to go fine until I hit the following error for Debug/Full/platformX86UNIX/x86UNIXRedbook.cpp.o:

In file included from /usr/include/SDL/SDL_main.h:26,
from /usr/include/SDL/SDL.h:30,
from ../../../../Engine/source/platformX86UNIX/x86UNIXRedbook.cpp:35:
/usr/include/SDL/SDL_stdinc.h:99: error: 'uint8_t' does not name a type

This is using gcc 4.4.6 and the latest of all the packages I would assume (allowed yum to choose). It doesn't look like I'm missing any SDL packages based on my yum search.

Any thoughts from you Linux experts? I may move over to Ubuntu as that is what I usually gravitate to. I just wanted to try out RedHat to be different from what you guys have already tried.

[just-bank]

I've never tried to build it on RedHat.
I'm using OpenSUSE (from 10.2 upto latest 12.2) mostly, and had run some tests on different CentOS and Ubuntu distros, so not sure what can be wrong with that RedHat.
Is there are any free-to-try RedHat distributes, so I can download and install in virtual machine?

[dasper]

@just-bank CentOS would be your best bet.

@DavidWyand-GG I would check the paths to see if it is different than Ubuntu but I doubt it. This error should only relate to the distro if it failed to include a file because it does not know uint8_t exists or how much memory to allocate for it. I am at a loss on it being a different distro would effect this unless there was a conditional for an include file. Like it does not think you have the hardware for this library or two different libraries depending on your version. I wish I could be more help. Only our VOIP servers run CentOS and that has been my exposure to RedHat derivatives and we where migrating those to Ubuntu as well.

[DavidWyand-GG]

I started to set up my Ubuntu server when I realised that I didn't do an update on my RedHat server. That very likely is my issue. Once that update completes I'll try another compile.

[devurandom]

uint8_t is the C99 type for an unsigned 8 bit integer. It is defined in stdint.h.

Looking at /usr/include/SDL/SDL_stdinc.h, it apparently assumes that either stdint.h (GNU/Linux) or inttypes.h (MSVC) are present and does not bail out in case neither is. From the error message you get, it seems your SDL_config.h does not define HAVE_STDINT_H (or is never actually included, etc).

[just-bank]

@DavidWyand-GG I've got it compiled/linked on CentOS 6.3 x86_64 (and I had the same error message).

All I need to do is to manually install 32-bit devel libs if running 64bit OS:

yum install glibc-devel-2.12-1.80.el6_3.5.i686
yum install libstdc++-devel-4.4.6-4.el6.i686
yum install SDL-devel-1.2.14-3.el6.i686

(those are versions I have on my fresh CentOS 6.3 box)
Without those I wasn't able to build and link. Don't forget to run

make clean

before re-building.

Actually, any 64-bit Linux requires you to have installed 32-bit versions of libs.

P.S. Will also push the fix for GCC 4.7.x (which is used in openSUSE 12.2), but after I test it on a couple of other Linux boxes.

[just-bank]

Pushed the fix for newest GCC (4.7.x). Everything seems to be fine.
Got it build and running on old 11.3 opensuse and latest 12.2 (both x86 and 64-bit platforms).

With the CentOS - it compiles fine and the binary is linked.
But... it crashes (I believe it will and on RedHat too) during startup. Investigating.

(gdb) bt
#0  0x0868d9c7 in CPUInfo::CPUCount (TotAvailLogical=@0x941baf0, TotAvailCore=@0x941baf8, PhysicalNum=@0x941baf4) at ../../../../Engine/source/platform/platformCPUCount.cpp:527
#1  0x0868e57a in SetProcessorInfo (pInfo=..., vendor=0x941bb14 "GenuineIntel", processor=67237, properties=535559167, properties2=0) at ../../../../Engine/source/platform/platformCPU.cpp:263

[thecelloman]

Maybe a bit off-topic but I have a question: Bank had commented on a ticket for the CE group that a Bullet physics enabled client could not connect to a linux server built with his changes. Is this still the case? If so, what happens with a PhysX enabled client?

I ask because it seems from general feeling that this will eventually work it's way into the development branch and I wouldn't want our physics changes (if a pull request is sent) to interfere with this.

[just-bank]

@thecelloman You got it a bit wrong:
There is a problem running bullet-enabled server on Linux at all.
So, to sum up, there are two way:

1. To have dedicated builds on Linux, but without bullet support (if this branch gets into official T3D).
2. No Linux dedicated servers at all (if this branch is not applied).

[just-bank]

Another update: installed regular (32-bit) CentOS 6.3 - same crash at the same place.
I wasn't working closely with RedHat-based distros for like.. 6-7 years, so not sure why it crashes and what causing it..
Will try another RedHat-based distro (Fedora) and post update as soon as I have something to share.

Update: Works on Fedora 17.
So, it should be something common between CentOS and RH.

[cweagans]

I <3 Linux and would love to see these changes land.

[intangir]

is this to run dedicated servers? or to run the client on linux?

[just-bank]

@intangir dedicated servers only.

[eugene2k]

I'm waiting for this to land in development so as to have a look at what the client needs to run.

[just-bank]

Pushed fix for RHEL-based distros.
Looks like GCC (4.4.x) on RHEL is built with some special optimization flags (or something else), which caused crash inside assembler code (when using inline-cast: uint->uchar->uint from GetNzbSubID down to find_maskwidth).
Tested this change on 7 different distros, so far - everything seems to be compiling and running.

[DavidWyand-GG]

@just-bank Thanks for pointing out what I still needed to do under 64bit. I believe this is the first time I've tried to compile Toque under 64bit given its 32bit nature.

And thanks for the additional commit to fix the crash. I'll try out all of your changes here again.

[DavidWyand-GG]

Good work @just-bank. I've taken everything as-is, but we may want to revisit the light type code you modified as @jamesu pointed out. We don't want to create an empty light type if we can help it.

[just-bank]

I'll play around with LightType-thingy some time during this week.
If I find something to share, I'll submit another pull request.

Thanks for the merge btw! :)

[DavidWyand-GG]

@just-bank That sounds great. I'll create a ticket just to track the issue. I was holding off on posting my latest blog because I wanted to get your changes in. :)

http://www.garagegames.com/community/blogs/view/21913

[weaponx69]

Hi Just bank. I'm over here from the Torque thread. You referred me here about possibly creating a client for linux. What is missing again that needs to get added to make this work as a client?

[intangir]

I am also interested in assissting with a linux client

[just-bank]

@weaponx69 and all others:
I've started a thread to discuss on what should be done for this on GG forums: http://www.garagegames.com/community/forums/viewthread/132085
Let's move and continue there.

[ChrisCalef]

Sorry for double posting but I put this in a GG forum post, and thought it might be rewarding to ask here as well... I'm trying to do a dedicated server build on 64 bit ubuntu 12.10, and got almost all the way through, except ran into linker errors apparently related to my 64 bit version of gcc? Or else the wrong version of STL / sdl ? Apologies for my ignorance, but here's the error messages:

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++
/usr/bin/ld: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lSDL
collect2: error: ld returned 1 exit status
cannot find -lstdc++
/usr/bin/ld: cannot find -lSDL
collect2: error: ld returned 1 exit status

More details about the libraries I installed to get this far in this post:

http://www.garagegames.com/community/forums/viewthread/132650

Thanks for all the great work you guys!!

Chris Calef