Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 44

Thread: Backward compatibility hell

  1. #21
    Join Date
    Apr 2007
    Posts
    372

    Default

    deanjo, i think that L33F3R meant most of linux users and actually saying that 90% as fact... just a metaphor, you know.

  2. #22
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,532

    Default

    Quote Originally Posted by Setlec View Post
    deanjo, i think that L33F3R meant most of linux users and actually saying that 90% as fact... just a metaphor, you know.
    Ya I just hate it when 28.6% of linux users throw out statistical values 73.1% of the time from 19.2% oxygen content air. 83.6% of the time those comments find a way of being quoted on slashdot of the time as "fact". 43.6% of the time that leads to 67.4% longer threads arguing about the statistics.

    -source- N.A.S.A

  3. #23
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by deanjo View Post
    Ya I just hate it when 28.6% of linux users throw out statistical values 73.1% of the time from 19.2% oxygen content air. 83.6% of the time those comments find a way of being quoted on slashdot of the time as "fact". 43.6% of the time that leads to 67.4% longer threads arguing about the statistics.

    -source- N.A.S.A
    Aaand now you're bringing that 'fun' to Phoronix... Niiice...

  4. #24
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by Setlec View Post
    hmmm, Ubuntu you say. TBH i really displeased by Ubuntu's way of doing things... It's true that Ubuntu is really popular but it's somehow becoming a "windows like" OS based on linux. Please forgive me but it's how i see Ubuntu. Many softwares has been reported broken or buggy. I've installed many closed source games on my linux distro (mandriva in fact) and almost never had issues like non functional libs.
    Ahem... You might want to revisit your thinking there. To quote poofyyoda...

    Quote Originally Posted by poofyyoda
    ...had an old libSDL in my folder which expected older directfb etc.. libraries.
    (Still addressing Setlec here...)

    When you override the libs in the game folder (which use LD_PRELOAD, etc...sigh...) you're going to get issues like he encountered- and it won't matter one WHIT which distribution you do it on. And it won't matter one WHIT of what they do in the libraries they include or their release cycles.

    You reached for something that lends to the image (and an incorrect one at that...) that Linux can't be properly supported by a commercial game or application. You're not helping things any- and it's not really as you made it out to be.

  5. #25
    Join Date
    Apr 2007
    Posts
    372

    Default

    Svartalf, you mean that even if I included a lib within the game directory (i mean packaging within the game it self), I would have those issues after upgrading the lib version?

  6. #26
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by Setlec View Post
    Svartalf, you mean that even if I included a lib within the game directory (i mean packaging within the game it self), I would have those issues after upgrading the lib version?
    If you drop in one that expects older libs and makes explicit reference to them, yes. It also can muck things up in other ways. Allow me to explain...

    If they've placed an LD_LIBRARY_PATH directive in a launcher script, it will look in that directory first. The same goes for a .so with an rpath specification in it- with one of those, you're telling ld to attempt to load your next .so's from that directory first. If you place a .so with an rpath specification, the rpath will override the whole lot and grab it's preferred .so's from where the rpath says- at the point of your loading the .so. This can result in your custom .so overriding the desired behavior (I specify rpaths for everything in my deliverables- Caster3D, for example) or the other rpaths and grabbing a .so that you didn't want- or attempting to get an old, no longer existing one as in this case. With the way Linux' dynamic load system works, you can't just provide a carefully vetted set of .so's that are known to work on the largest range of distributions (and that's what is typically in a game's .so bundle...) without overriding things a bit- and you've got to know precisely what you're doing when you drop one into the game's directory structure or remove one from it to force the game to grab from the system instead.

    While you can certainly do it, you're on your own when you start yanking .so's around like this- and it's not the distro's or the application provider's fault when things break because you're operating in a domain that's not anticipated or envisioned when you do it.
    Last edited by Svartalf; 09-11-2009 at 09:11 AM. Reason: Added a bit to explain further...

  7. #27
    Join Date
    Apr 2007
    Posts
    372

    Default

    i see... well the best way it would be to keep the source game update then...

  8. #28
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by Setlec View Post
    i see... well the best way it would be to keep the source game update then...
    Nahh... If they've done it right, you shouldn't need to dink with the .so's in the package set.

    There's typically been only a few where they had an issue where the .so had issues because of a misuse of the glibc API layer that got "broken" because they'd not pinned the symbol list in time against the known working version. An example of this would be Neverwinter Nights. SDL was built for it, but the version shipped had issues due to things like the aforementioned- so deleting it from the libs dir worked like a champ (and was the vendor recommended fix...). Moreover, in many cases, you can just simply nuke any LGPLed stuff you already have on the system out of the packaging directory- if it works, it works. You'll just have an unsupported configuration unless the vendor tells you to do so. The main reason why they ship with a specific version of things like SDL is there's quite a bit of variance at the edges with each distribution since there's not a consistent version number everyone is on. That means one distro might break things on your distro butw with another it may not- and consistency is king here. It typically works just fine with things like that removed, but you need to do an LDD check, with whatever LD_PRELOAD/LD_LIBRARY_PATH options in front of the ldd call and make sure you're grabbing FULLY from the system unless you want to pick and choose and know what you're doing.

    It's analogous to taking an old, old system DLL from Windows XP and dropping it into Vista somewhere in your search path so that it'll be found first- and breaks everything.

  9. #29
    Join Date
    Aug 2008
    Posts
    32

    Default

    short version:
    in linux there is always a way, in windows no.

    linux is better for gaming.

    cheers

  10. #30
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    short version:
    in linux there is always a way, in windows no.

    linux is better for gaming.

    cheers
    The Free Zealot Foundation is proud to award its monthly prize to our beloved member Gforum.

    The decision, as always, has been very hard to take. I should say that this edition has been particularly tight, as many contenders were short listed for the high quality of their fantasies. We have heard alusions to human rights, the nomination of Sir Richard Stallman for the most influential philosopher of the XXI century, denial of unfavourable benchmarks, and of course the regular flow of Microsoft and Apple bashing.

    However, we finally agreed that Gforum's post, with its impressive simplicity, its complete disregard for any external reality, and its exquisite non sequitur conclusion, fully deserve the award.

    Keep it up and stay tuned!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •