Announcement

Collapse
No announcement yet.

Unreal Tournament 3 Linux Server Is Out!

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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.

    Comment


    • #17
      Originally posted by niskel View Post
      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.
      Heh...

      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.

      Comment

      Working...
      X