Now that's an Open Challenge!!
Indeed. I wish I had the beta and after files... Then I could actually TELL you what went south on 'em without having Ryan, Epic, or anyone else breach NDA's...
Originally Posted by Thetargos
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.
i went over each one and here's what i came up with...
Originally Posted by Svartalf
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.
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.
Originally Posted by niskel
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.