nickpy said:
1. Developing for wide-distribution across different linux distributions is a complete pain in the butt - I know, I've done it - because by their very nature, different linux distros have different things in them. Yes, you could only support certain distros or go for a lowest common denominator, but then you're not really seeing the full benefits of trying to "go linux", methinks. Thus, I think many developers simply wouldn't bother - especially imagine the support calls! Most technical support departments don't even understand how windows works, so good luck getting any help when the game crashes with a random error on your linux box! Evidence: All Introversion games are released with Linux versions, and I have never once managed to get them to run on any of my Linux boxes, and I wasn't even using obscure distros.
I'm not claiming to be an expert, but this shouldn't be a problem. I've never played Introversion, so I don't know much about that, but I have installed UT2004, Doom 3, Quake 4, and other games on my Gentoo box and they worked fine.
Developers should take one of two paths:
1. Dynamically link everything, and let the distributions handle the dependencies.
Let's say Valve were to port Team Fortress 2 to Linux, and lets say the TF2 binary depends on libCEGUICore.so, libAL.so, libOgre.so, and libOIS.so. If Valve were to dynamically link the executables, they should let the distributions handle the odd's and end's of the shared libraries.
For example, Debian might have named their OpenAL library libAL.so.0.1, and Red Hat might have named it libAL.so.0.1.0. If TF2 depends on libAL.so.0.1.0, that's great for Red Hat and its forks, but Debian will have to add some additional symbolic links in their packages to have TF2 point to the right OpenAL version.
And that's not all. Red Hat might be a couple versions behind on their Ogre implementation, and Debian might have removed the old CEGUI library TF2 depends on. So they would have to bring back that old version just to get TF2 running.
However, the good news is that Valve doesn't have to do that. That's exactly what distributions are here for. Bundling together all these shared libraries and getting them to work correctly with each other. Developers for an application shouldn't worry about these things, let the distributions worry about it.
Or you could...
2. Statically link everything right up until the GCC runtime library.
This is the approach I would personally take. You don't have to worry about any quirky shared library misnaming schemes, broken shared library API's/ABI's because of a new version, or any of that other stuff. All the libraries your binary depends on are all inside your executable. No need to load any shared libraries besides the GCC runtime.