Now that's an Open Challenge!!
Now that's an Open Challenge!!
Heh... Nojoy on finding out that way... Only ONE .so- Ageia's SDK is present. Past that, there is only one binary, the server. It, unfortunately, is done much the same way an LGP binary has been done for stability reasons.
Licenses for middleware stated in the EULA:
Fonix VoiceIn and DecTalk
Odd combo of things, really. Don't have a clue (yet) as to what the hold up was. Apparently it wasn't Bink or GameSpy any more than it was PhysX.
Speedtree - no issue, linux already supported.
Fonix VoiceIn and DecTalk - might pose problems...
Libxml2 - no issues, open source.
ConvexDecomposition - which library is this?
PhysX - closed source, and says support for linux is comming.
GameSpy - closed source, but shows support for linux, at least with prior titles (look at quake 4 and doom 3?)
Lua - no issues, open source.
SDL 1.2 - no issues, open source.
just by a quick look, it's easy to say that fonix voicein, and dectalk might be the hold up.
You didn't do much digging:
"DECtalk 4.6.4 and 5.0 are still available as downloadable run-time (RT) only products, formatted specifically for Linux-based applications. Click here for more information."
VoiceIn, on the other hand, doesn't seem to officially state that there's a Linux version, but considering that the thing targets PS3, etc. it's not likely that this is actually the problem either as it's liable to be C++ or C code with little fancy stuff in it. You couldn't target all those platforms that they claim to with the VoiceIn Game SDK if you did stupid stuff.
Furthermore, VoiceIn and DecTalk would be client side apps- there's little use for a speech recog and text to speech system on the server side of things.
By licensing statements alone, you won't find what had to be worked out or re-worked. You're going to have to think through what might/might not exist on both sides that might need to be re-worked simultaneously to get rid of a licensing problem. Also don't think for one moment that the OpenSource stuff can't be a problem- one still has to abide by the licensing terms of the license used by the software that you're using (As the in recent times violators of the GPL on BusyBox have been finding out...). The LGPL has to be abided by- which means you need to provide an option to dynamically link a binary to a new version of the library. If you don't provide SOME way of doing it, you're in violation of the terms of the license if you're not abiding by the terms given you by the regular GPL. That's just one example of a gotcha. Ryan stated we all wouldn't believe our eyes or ears if we were told what'd been the problem- I'm of the opinion that this is the truth and it's a damned silly thing that held it up.
Is it just me or is it strange that the UT3 Demo Beta Server links against both libstdc++.so.6 and libgcc_s.so.1 whereas the final server does not.
I have seen plenty of games link against (and distribute) these two libraries. I just thought it strange that they were distributed and linked against for the demo beta server and have not been distributed with or linked against in the final server.
It's a maintenance/game reliabilty issue.
LD_PRELOAD's really kind of a bad thing- it causes all kinds of issues with security, stability, etc. and should be used as a band-aid for problems or for debugging one's code. At least one of those two libraries represents an issue for older systems being able to run the server (libstdc++.so.6 is a relatively new thing from within the last couple of years.) on things as old as Debian Woody. If you statically link key runtimes, you can get away with a broad range of support. I'm not sure about it being 100% kosher for them though without a dynamic linkable version- it's not in keeping with the LGPL terms, which require you to provide a means to substitute .so's to LD_PRELOAD if there's a problem to be addressed by the library in question. LGP statically links most of the stuff in the titles they provide (For robustness reasons- you can be assured of reliable operation on a large range of distributions that way... If done right, you can expect the code to run against distributions about 5 or so years old, even...) but provides a dynamic link version for such instances. libstdc++ is one of the ones, if you're not going to go the LD_PRELOAD route, that you WANT to statically link- it sidesteps the fact that we've had, over the last 5-6 years, three different C++ application binary interfaces. The current one, hopefully, will be the one we end up with for a while so this will become less of an issue over the next couple of years. As it stands, if you want reliable operation, you will statically link against the libstdc++ of your choice, dynamically link against glibc with the 2.1 ABI edge either by using very specific .so's for it or by using Autobuild from Autopackage to force things to the right way.