Illasera Mar 27 @ 3:21am
Why is SDL2.0 held privately [sandboxed] on Debian
I have downloaded the steam package from Debian Jessie testing repo.

A quick Dependency scan shows this :
/home/my_username/.steam/ubuntu12_32/libSDL2-2.0.so.0
SDL2 loaded in private (as in private memory), Which is a damn shame because i do have other softwares that are using SDL2 (same version), so why loading it more than once?
As well as the other libraries that steam uses being installed/used in my home folder in somewhat of a sandbox mode.

I am aware of the fact that steam for linux started in ubuntu environment, My question is, why is it still the case here? Even if i downloaded the "installer" from the Debian repo?
Last edited by Illasera; Mar 27 @ 12:34pm
Showing 1-6 of 6 comments
< >
Letalis Sonus Mar 27 @ 8:09am 
It's simple: to prevent incompatibilities. There have been several games in the past that had problems with differences in the SDL libraries provided by the system. Additionally it might as well provide a more up-to-date version withouth breaking other things.
Apocryphus Mar 27 @ 11:09am 
This is because of inconsistency issues across Linux distros. In order to ensure that the end-product works it's linked with a localised version of the relevant libraries within the binaries itself. Because there's no single package manager on Linux to manage everything unilaterally something like this has to be done just in case the SDL version held by the distro is incompatible with the one the end-product uses. Just my token here.
Illasera Mar 27 @ 12:31pm 
As mentioned before, I wrote that i downloaded steam from the DEBIAN testing repo
of course there is inconsistency issues across Linux distros, That's why the distro owners usually try to sort them out.

As far as the previous argument, That there are different versions of SDL Library and they may have compatibilities issues, Yes, usually SDL 1.x WITH SDL 2.x (SDL 2.x is not backward compatible with 1.x However, i was talking about SDL2.x on its own, Steam uses the same version it seems as the one in debian-sid(unstable).
Last edited by Illasera; Mar 27 @ 12:41pm
TheJJ Mar 27 @ 1:28pm 
The reason is: non-free software.
The "steam-runtime" environment is managed by Valve, they know what they are linking their programs/games to.
If they used the distro's libraries, Valve would have to react and relink when the distro releases updates.

Normally, package maintainers would update dependent programs, but Valve's binaries are closed-source so nobody else is able to relink against updated libraries.
Illasera Mar 27 @ 3:38pm 
Originally posted by TheJJ:
The reason is: non-free software.
The "steam-runtime" environment is managed by Valve, they know what they are linking their programs/games to.
If they used the distro's libraries, Valve would have to react and relink when the distro releases updates.

Normally, package maintainers would update dependent programs, but Valve's binaries are closed-source so nobody else is able to relink against updated libraries.

THANK YOU, that make sense :) at least now i know
Letalis Sonus Mar 27 @ 5:46pm 
Originally posted by TheJJ:
If they used the distro's libraries, Valve would have to react and relink when the distro releases updates.
Not really. Generally the involved libraries are all developed in a way that makes them upwards compatible, old interfaces are kept until enough obsolete stuff has been collected for a new large major release that will drop them, which will end up in a different file that can be installed side by side with the old version (e.g. like GTK2 and GTK3), the whole library version naming is pretty much standardised and consistent among the different distros, at least concering those core libraries. The libstdc++ is a special case and a lot more touchy about that, but it still follows the same pattern.

The symbols are remaining the same, there's no problem with replacing some libraries with different versions without any need to relink anything at all - you'd rather need to entirely recompile it if you need to take action, anyway. The small changes that every distributor applies to their version are much more problematic, especially if they are using different compile-time options resulting in different feature sets.
Showing 1-6 of 6 comments
< >
Per page: 15 30 50
Date Posted: Mar 27 @ 3:21am
Posts: 6