Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
Posted Oct 3, 2013 2:25 UTC (Thu) by hummassa (subscriber, #307)In reply to: Why Steam on Linux matters for non-gamers by khim
Parent article: Why Steam on Linux matters for non-gamers
Ok, let's lay down the pipe.
How come? Hm, khim *must* be right, let's check it, just in case. Get random C program, compile with gcc-4.8 under sid, copy binary to wheezy machine. Works. Ok, copy binary to lenny machine. Still works. Nope. Not right.
Packages.debian.org say that gimp in wheezy is 2.8.
I conclude *I* must be intoxicated, and that I cannot parse you anymore.
Posted Oct 3, 2013 2:48 UTC (Thu)
by dlang (guest, #313)
[Link] (14 responses)
the correct test would be to compile on Wheezy and try to run the resulting binary on Sid
you can't compile a program with the latest Windows 8 APIs and run it on older versions of Windows either.
If you could always run new software on old systems it would mean that you are not using any new features, which would stop all development
Posted Oct 3, 2013 2:59 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
Posted Oct 3, 2013 3:21 UTC (Thu)
by dlang (guest, #313)
[Link] (12 responses)
> Actually, you can do it just fine. As long as you don't use the API in question.
while this is technically true, when you compile on a new system, you pull in new versions of libraries (or at least library headers), and so you are going to end up using new versions of the various APIs unless you go to a lot of effort to avoid it (much more effort than just compiling on an older system)
Posted Oct 3, 2013 3:34 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
>#define WINVER 0x0501
And that's it. Really.
Now, how can I do this with Ubuntu 13.04? I'd really like my programs compiled against the system glibc work on RHEL6.
Posted Oct 3, 2013 3:42 UTC (Thu)
by dlang (guest, #313)
[Link] (9 responses)
On windows you may be able to do that for some microsoft controlled libraries because they control everything.
but if you use any third party libraries, you can't just set WINVER and count on it working, because the library version isn't tied to the windows version.
the way to do the equivalent on Linux is to get a set of the headers for whatever version you want to compile against, and use those for your compile, but Ubuntu doesn't provide RHEL libraries any more thatn RHEL provides Slackware libraries.
remember that most of the APIs for RHEL were frozen well before 6.0 was released in 2010, so what you are asking for is even harder than saying that you want something compiled against the 13.04 libraries to work against Ubuntu 10,10 (or more likely 10.04) libraries.
If you want everything for an ecosystem to be controlled by one entity, go get yourself a Mac.
Posted Oct 3, 2013 4:00 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
> the way to do the equivalent on Linux is to get a set of the headers for whatever version you want to compile against, and use those for your compile, but Ubuntu doesn't provide RHEL libraries any more thatn RHEL provides Slackware libraries.
Compiling stuff on Windows for older versions of OS? Easy, just set WINVER and maybe a couple of compiler switches. And don't forget to package your libraries. On Mac OS X it's the same (__MAC_OS_X_VERSION_MAX_ALLOWED), except that there's also a standard bundle format.
On stock Linux distributions it's basically impossible. You have to install a parallel environment in a some kind of container.
Posted Oct 3, 2013 10:48 UTC (Thu)
by khim (subscriber, #9252)
[Link] (7 responses)
Actually it's possible to do: as I've pointed out earlier LSB solves this problem. What you cannot really do is to use newer version of GCC. Not because of GLibC, but because of libstdc++. Just like GLibC libstdc++ is not designed to be linked into many different modules and it's not forward-compatible. LSB solves tis problem, too - but only up to GCC 4.6 (since libstdc++ is part of GCC you need to modify GCC to solve it, you can not just modify headers and libraries). This is valid approach, too.
Posted Oct 3, 2013 11:08 UTC (Thu)
by hummassa (subscriber, #307)
[Link] (3 responses)
this is incredible BS. LSB 4.1 is supported perfectly by debian, via the installation of the (oooh, surprise) "lsb" package. even packages compiled in Fedora 12 in C++ work if you install the (surprise, again!) "lsb-cxx" package. Just "alien"ate it, install it, voila.
Posted Oct 3, 2013 11:46 UTC (Thu)
by khim (subscriber, #9252)
[Link] (2 responses)
That's not support. That's a joke. It reminds me my first experience with Debian many years ago. I've used RedHat back then with a couple of custom PAM modules and wanted to play with Debian. And shiny new (back then) version of Debian supposedly included PAM support. Ok, fine, I've installed Debian and tried this “support”. Can you guess what happened? Right: it was possible to install PAM and get shiny new Sure, you can use it to run some LSB-compatible software (which does not really exist) but can you develop something for Debian using LSB? How will you know which version of LSB to target to support which version of Debian? Where will you find libraries to access APIs not included in LSB (and there are many APIs not included in LSB)? LSB package, yes, it's supported by Debian. LSB development… nope. LSB was developed as a good basis for the hypothetical “Linux distribution's SDK”, but nobody bothered to actually make one. Because it's more-or-less impossible without help from distribution makers and distribution makers are not interested.
Posted Oct 3, 2013 13:11 UTC (Thu)
by peter-b (guest, #66996)
[Link]
Posted Oct 6, 2013 12:12 UTC (Sun)
by krake (guest, #55996)
[Link]
The problem is not interest of distribution makers, the problem with LSB is that it codifies what RHEL ships at the time of a LSB release.
To be actual useful for both SDK and Application vendors, it would have to specify a situation that distributions would then strive to implement.
I've been to an LSB meeting once. SDK providers asked for a binary compatible update of some libraries for the standard's next(!) version, but the request was turned down because those versions would not be already be available in RHEL at the time of the standard's release.
Posted Oct 3, 2013 14:49 UTC (Thu)
by jwakely (subscriber, #60262)
[Link] (2 responses)
Could you expand on this part please?
What changed after 4.6, and what changes can you make to "fix" it?
Posted Oct 3, 2013 16:36 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Nothing have changed after 4.6, but as I've said it's a lot of work to support newer version of gcc and Linux Foundation have only done said work for GCC 4.6, not for GCC 4.7 or 4.8 The problem with LSB is that it's tries to solve backward compatibility problem by adding some packages “on the side” which obviously does not work: it's very easy to break compatibility if you are not thinking about it and the only way to make sure it's not broken is to use it. Compare situation with Android SDK, e.g.: Google actually builds things using said SDK which means that if it's broken problems are quickly found and fixed. And if some important APIs are needed then they are added to SDK, too. Distributions don't use LSB to build anything which means that problems with LSB are very low-priority (if they have any priority at all).
Posted Oct 4, 2013 14:19 UTC (Fri)
by jwakely (subscriber, #60262)
[Link]
Posted Oct 4, 2013 10:40 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
Actually, you can do it just fine. As long as you don't use the API in question.
Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
Let me quote this incredible effort to limit APIs to the ones supported by WinXP:
>#include <windows.h>
Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
On Windows that works just fine for the core Windows services. Which cover quite a lot of ground - from loading images and UI to network protocols support.
I can package most of the third-party libraries with my application - but I can't package glibc and _everything_ depends on it. And there's no way to say "use symbols that existed in glibc x.y.z".
Why Steam on Linux matters for non-gamers
I can package most of the third-party libraries with my application - but I can't package glibc and _everything_ depends on it. And there's no way to say "use symbols that existed in glibc x.y.z".
On stock Linux distributions it's basically impossible. You have to install a parallel environment in a some kind of container.
-mmacosx-version-min=XXX on MacOS does something like this. Problem lies not with the fact that it's impossible to do in principle, but in the fact that nobody bothers to do that in timely manner: LSB is not supported by Debian, it's totally separate thing and new version of GCC is supported by LSB not when it's released, but years later.Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
LSB is not supported by Debian
this is incredible BS. LSB 4.1 is supported perfectly by debian, via the installation of the (oooh, surprise) "lsb" package.
/lib/libpam.so.0 library… and that's it. You could not use it for the logon authentication, it's not used by the xlock, etc.even packages compiled in Fedora 12 in C++ work if you install the (surprise, again!) "lsb-cxx" package.
Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers
What changed after 4.6, and what changes can you make to "fix" it?
Why Steam on Linux matters for non-gamers
Why Steam on Linux matters for non-gamers