FS#51990 - [steam] enable the dynamic linker trick by default

Attached to Project: Community Packages
Opened by Emil (xexaxo) - Monday, 28 November 2016, 17:10 GMT
Last edited by Levente Polyak (anthraxx) - Friday, 09 December 2016, 02:03 GMT
Task Type Bug Report
Category Packages: Multilib
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Atm, one needs to apply the dynamic linker trick [1] or disable the steam runtime to get things working.
In the former case one can get issues even if they are using the binary drivers (which don't use newer's than steam's libstdc++) [2] [3]

We can mitigate most of the issues, by renaming the original steam script (to say steam-original ?) and having the default steam to something like the following:

#!/bin/sh
export LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so'
exec /usr/bin/steam "$@"


[1] https://wiki.archlinux.org/index.php/Steam/Troubleshooting#Dynamic_linker
[2] https://wiki.archlinux.org/index.php/Steam/Troubleshooting#The_game_crashes_immediately_after_start
[3] https://wiki.archlinux.org/index.php/Steam/Troubleshooting#.27GLBCXX_3.X.XX.27_not_found_when_using_Bumblebee
This task depends upon

Closed by  Levente Polyak (anthraxx)
Friday, 09 December 2016, 02:03 GMT
Reason for closing:  Fixed
Additional comments about closing:  1.0.0.54-1
Comment by Levente Polyak (anthraxx) - Monday, 28 November 2016, 17:36 GMT
This is pretty much the reason why steam-native exists, please use that instead. it will be the default soon
Comment by Emil (xexaxo) - Monday, 28 November 2016, 18:44 GMT
Since we do want something sane here (right?), whether steam-native is/becomes the default package is orthogonal.

If the reluctance is about writing the code, maintainership and alike I'll gladly help.
Thanks
Comment by Levente Polyak (anthraxx) - Monday, 28 November 2016, 18:49 GMT
The only sane thing with the steam runtime (under arch) is to not use it. You will encounter lot of such problems and i don't see much point in firefighting steam's runtime forever
Comment by Emil (xexaxo) - Monday, 28 November 2016, 18:55 GMT
If you/others don't have the time not invest - sure thing.

I'll gladly help, unless my proposal for assistance is declined already :'-(
Comment by Levente Polyak (anthraxx) - Monday, 28 November 2016, 19:43 GMT
Very kind from you, but thats unfortunately not the point. From our view the steam runtime's approach is simply flawed and I'm not a fan of supporting something that clearly does not work out. Depending on each setup you may end up bypassing more and more of the runtime, including nvidia, alsa, pulse and possibly even more. Not to mention that using and udev client library deviating from the server's version is plain madness.
To sum it up: its an infinite sisyphos work and the more time passes by the more stuff you will possibly need to bypass.... so at the end the native runtime is the only sane approach here.
If someone wants to use the steam's own runtime, they are free to fix whatever is required for their particular case/setup.
Comment by Emil (xexaxo) - Monday, 28 November 2016, 20:11 GMT
Thank you for trying to spare me the pain and yes I realise it's a loosing battle.
Regardless (call me naive/stupid/other) it's one I'm willing to take.

What I'm aiming it to have Steam and some games sort of working, since anything else is close to impossible.
Comment by Levente Polyak (anthraxx) - Tuesday, 06 December 2016, 15:14 GMT
After lot of thinking and considerations I believe i gonna include the overrides above, they are clearly the major problem breaking steams runtime, however for anything else the user is responsible to make this wonky stuff working for the used environment and steam-native is still the way to go :P

Loading...