Steam linux client ignores system LD_LIBRARY_PATH

[Demige]

Your system information

• Steam client version (build number or date): Jun 8 2017, at 04:34:18
• Distribution (e.g. Ubuntu): Debian Stretch 64 bit
• Opted into Steam client beta?: [Yes/No]
• Have you checked for system updates?: [Yes/No] Yes

After update to steam built "Jun 8 2017, at 04:34:18" it ignores my runtime variable LD_LIBRARY_PATH. I have different GL libraries for my video cards in different dirs (for different seats). Now i need to change system ld.so.conf to launch steam.

[kisak-valve]

Hello @Demige, you should be able to add env > ~/envdump #%command% to any games's launch options to generate the environment being used by games to help you troubleshoot. (Run the game and expect it to almost instantly close.)

It looks like Debian 9 does not have /sbin in the PATH, so STEAM_RUNTIME_PREFER_HOST_LIBRARIES recently started working as intended on your distro. You can disable this env variable with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 and should get the previous behavior back.

[Demige]

Setting STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 did not help:

STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:/usr/lib/i386-linux-gnu/ steam
Traceback (most recent call last):
  File "/usr/bin/steamdeps", line 419, in <module>
    sys.exit(main())
  File "/usr/bin/steamdeps", line 389, in main
    packages[ name ].setInstalled( match.group(2) )
KeyError: u'curl:i386'
Running Steam on debian 9 64-bit
STEAM_RUNTIME is enabled automatically
/bin/bash: /home/mike/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
grep: symbol lookup error: grep: undefined symbol: pcre_jit_stack_alloc
grep: symbol lookup error: grep: undefined symbol: pcre_jit_stack_alloc
grep: symbol lookup error: grep: undefined symbol: pcre_jit_stack_alloc
Installing breakpad exception handler for appid(steam)/version(1496897923)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

output without this:

LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:/usr/lib/i386-linux-gnu/ steam
Traceback (most recent call last):
  File "/usr/bin/steamdeps", line 419, in <module>
    sys.exit(main())
  File "/usr/bin/steamdeps", line 389, in main
    packages[ name ].setInstalled( match.group(2) )
KeyError: u'curl:i386'
Running Steam on debian 9 64-bit
STEAM_RUNTIME is enabled automatically
Installing breakpad exception handler for appid(steam)/version(1496897923)
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

I try to change steam.sh, but it replaces this if CRC or file size changed.

[h1z1]

/sbin should not be in a users path. What in the world is steam needing that for?

[kisak-valve]

@h1z1, steam calls ldconfig when setting up STEAM_RUNTIME_PREFER_HOST_LIBRARIES=1. The workaround mentioned at https://github.com/ValveSoftware/steam-for-linux/issues/4939#issuecomment-298111210 is no longer needed because /sbin/ldconfig is now being called instead of depending on it being found via the PATH variable. Having /sbin in the user's path is not needed in the current steam client, but this is a recent behavior change that might have been related to @Demige's issue.

[h1z1]

Without the source it's hard to tell the usage. Only reference I can find is a rather shocking one in steam.sh.

Besides causing needless IO while the OS walks all of those libs, you're assuming the system libraries are correct though that quite likely will not be the case - VirtualGL overrides for example, or forcing steam to use an IGP while games use GPU.

The method you're using is not the same as the linker would to expand those paths. It for example does not expand macros ($LIB). Line 676 actually explicitly clobbers LD_LIBRARY_PATH.

[Demige]

I try to start with LD_PRELOAD=/usr/lib/i386-linux-gnu/libGL.so.1:/usr/lib/x86_64_linux-gnu/libGL.so.1 steam launches well (generate a lot of warnings ERROR: ld.so: object '/usr/lib/i386-linux-gnu/libGL.so.1' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

Steam is 32bit, but games often 64bit, this is because I need to preload both libraries.

[h1z1]

@Demige - Don't do that, LD_PRELOAD is different from LD_LIBRARY_PATH :) Thing is you shouldn't need to anyway, the OS is quite capable of supporting multiple architectures concurrently. Problem is steam goes through some fairly invasive means to "guess" what libraries to use rather then leaving it to the system or setting rpath.

[Demige]

Ok, but how I can start steam without doing that? Every time, I need to run steam edit /etc/ld.so.conf and edit it back after closing steam? Without that I can't start KODI on other seat (It uses intel graphics and need mesagl renderer, and steam runs on nvidia and need native gl render)

Before changes to steam client not long ago defining LD_LIBRARY_PATH worked well

[h1z1]

That is the irony, you can't officially. Even more hilarious is steam automatically uploads crash dumps to Valve so they are well aware of these problems.

For now I've jailed steam until I can rewrite at least a basic, authentication interface so I can once again play the games I"ve paid for without these shenanigans.

[baryluk]

I have same issue - Steam ignores LD_LIBRARY_PATH preventing me from setting custom path to libdrm and libGL.so , it always reads and links with ones provided in default OS paths. I have no issues with any other apps or OpenGL / Vulkan games, and they respect my LD_LIBRARY_PATH but not Steam.