Backward compatibility hell

[Setlec]

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

[deanjo]

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

[Svartalf]

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...

[Svartalf]

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...

...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.

[Setlec]

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?

[Svartalf]

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.

[Setlec]

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

[Svartalf]

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.

[gforum]

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

linux is better for gaming.

cheers

[yotambien]

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!