Hello @sylware, what's the exact scenario (with library versions and paths) where LD_LIBRARY_PATH must be handled for pinning?
Using libxcb-dri3 as an example sounds like you're trying to refer to the bootstrapper runtime issue that is being tracked at #4816 and does not apply because the bootstrapper currently does not pin libraries.
On Sun, Apr 22, 2018 at 05:36:38AM -0700, kisak-valve wrote:
Hello @sylware, what's the exact scenario (with library versions and paths)
where LD_LIBRARY_PATH must be handled for pinning?
I mean the current 64bits and 32bits x11/GL (and why not alsa and more) libs are not
visible from the main /etc/ld.so.conf (/sbin/ldconfig) and are visible only in
LD_LIBRARY_PATH.
Additionnaly, you could have a different location of ld.so.conf and ld cache for
the 32 bits libs than the main 64 bits system libs (/sbin/ldconfig won't find
the 32 bits libs).
The source of the system libs would be first the system LD_LIBRARY_PATH, then
ld cache.
The mainstream distros usually dump everything is one ld.so.conf, so it's fine if
you only support this, but the thing is the pinning is reset all the time the
steamruntime is re-installed/re-extracted and we cannot hook into the main bash
script without forcing that.
Then I dare to ask for a way to do the pinning ourself, a kind of a hook or
something else, we know the pinning will happen in
$HOME/.steam/bin/steam-runtime/pinned* directories.
Using libxcb-dri3 as an example sounds like you're trying to refer to the
bootstrapper runtime issue that is being tracked at #4816 and does not apply
because the bootstrapper currently does not pin libraries.
Actually it's how I did notice that pinning was not done on my system (coze I
don't use the ld cache on my system). The real news is a new libxcb-dri3 symbol
in libGL (mesa amdgpu), not the one related to the installer:
libxcb-dri3 installer missing symbol is xcb_send_request_with_fds
new libxcb-dri3 runtime missing symbol is xcb_dri3_get_supported_modifiers
(used in recent libGL but it's benign because dynamically dealed with as it
seems).
On Sun, Apr 22, 2018 at 02:16:59PM +0000, [email protected] wrote:
Then I dare to ask for a way to do the pinning ourself, a kind of a hook or
something else, we know the pinning will happen in
$HOME/.steam/bin/steam-runtime/pinned* directories.
I gave some thoughs about it: what about 2 env variables:
STEAM_PIN_OVERRIDE_32
STEAM_PIN_OVERRIDE_64
Colon separated absolute path names to "soname" files/symbolic links.
Links to those would be installed in pin directories whatever happens (quite
less clumsy than a brutal LD_PRELOAD), and that each time steam is started.
That would give the tools to troubleshoot those pesky steam/system runtime libs
with fine granularity.
--
Sylvain
What are you setting LD_PRELOAD to? The OS should have no problem finding libs based on architecture (32 vs 64 bit for example). The way library pinning is done in steam makes a giant assumption that ABI/API is always compatible which is narcissistic at best.
coze I don't use the ld cache on my system
What on Earth would you disable that for?
For the moment, since the client runs ok and I don't have steam runtime re-install or
update, I do pin the 64 bits libs manually before starting the client.
OK.. but that doesn't answer the questions though. At the very least, what are you setting preload to?
lib pinning almost useless, with current steam-runtime: only the 64 bits steam-runtime libdbus is enable to run google libcef.
With dbus or not, cannot reproduce any breaking pinning.
Seems fixed for now.
Nothing extracted yet.
If the gfx system libs are provided in a system LD_LIBRARY_PATH, it will be ignored by the bash ( :'( ) script which creates pinned links because it requires the use of /sbin/ldconfig and ld cache.
More over some systems split 32 bits ld cache location with 64 bits ld cache location which means /sbin/ldconfig will miss the 32 bits libs pinning.
(I would recommend to code a real binary program to manage the pinned libs, called from the main script with a behavior overridable with some user set env var(s) )
I could see that 64 bits steam runtime libxcb-dri3 is missing a symbol for a recent mesa libGL (showed by the vulkan tester).