Having the same issue, would love to know how to resolve this
With the last update for SteamRT3, I am facing a similar issue where PATH is replaced, preventing me from running wrappers (in ~/.local/bin) without their absolute paths.
Disabling SteamRT3 fixes the issue.
I can reproduce a similar thing with MangoHud (mangohud steam) and an OpenGL game (in which MangoHud relies on LD_PRELOAD for its code injection). In fact Steam is appending gameoverlayrenderer.so to the LD_PRELOAD path, but unfortunately it's the wrong version of LD_PRELOAD: instead of using the original LD_PRELOAD from outside the container, it's using a version of LD_PRELOAD that has been remapped to be visible in the container's filesystem namespace, but then that doesn't work for a command that needs to run outside Steam's container.
If your scenario is the same as mine, you'd see that LD_PRELOAD is set to something that looks like /tmp/pressure-vessel-libs-3zy1SF/${LIB}/libMangoHud_shim.so:/home/me/.local/share/Steam/steamrt64/gameoverlayrenderer.so:/home/me/.local/share/Steam/steamrt32/gameoverlayrenderer.so (but with your LD_PRELOAD modules, whatever they might be, instead of mangohud).
I would prefer to have these globally set rather than having to do them per-game
Doing this per-game in Launch Options, or disabling the experimental steamrt3c client, is likely to be the best workaround for now.
With the last update for SteamRT3, I am facing a similar issue where
PATHis replaced
Let's use #13389 to represent that. The root cause is quite similar, but the solution might be different.
In my case, the libraries are all in /usr/lib/x86_64-linux-gnu. LD_PRELOAD is set to LD_PRELOAD=/usr/${LIB}/localefix.so.0:libgtk-nocsd.so.0.
In my case, the libraries are all in
/usr/lib/x86_64-linux-gnu.LD_PRELOADis set toLD_PRELOAD=/usr/${LIB}/localefix.so.0:libgtk-nocsd.so.0.
That's what they look like outside Steam, sure. The good scenario (which would make it work) would be that the command from the Launch Options would inherit something like LD_PRELOAD=/usr/${LIB}/localefix.so.0:libgtk-nocsd.so.0:/home/me/.local/share/Steam/steamrt64/gameoverlayrenderer.so:/home/me/.local/share/Steam/steamrt32/gameoverlayrenderer.so.
But if you're seeing the same thing I am, then the command from the Launch Options will actually be inheriting something more like LD_PRELOAD=/tmp/pressure-vessel-libs-3zy1SF/${LIB}/localefix.so.0:/tmp/pressure-vessel-libs-3zy1SF/${LIB}/libgtk-nocsd.so.0:/home/me/.local/share/Steam/steamrt64/gameoverlayrenderer.so:/home/me/.local/share/Steam/steamrt32/gameoverlayrenderer.so. Steam is trying to leave the modules enabled, but not successfully, because of confusion between in-container and outside-container paths in the Steam Client.
probably deliberate behaviour
Actually no - what you're doing is meant to work, it's just going wrong somewhere. Until recently, Steam has not needed to distinguish between in-container and out-of-container environment variables, but with the addition of the steamrt3c/containerized/64-bit client, it now needs to be more careful.
LD_PRELOAD modules are very powerful and can break things in unexpected ways, so they need to be written very carefully and used cautiously, but Steam isn't intentionally disabling them.
(There is one module that it does intentionally disable, libgtk3-nocsd.so.0, which had a history of crashing programs that use GLib-but-not-GTK, and that category includes Steam's container framework and various other important helper programs. But hopefully its replacement libgtk-nocsd.so.0 is considerably less crashy.)
Nothing extracted yet.
This is probably deliberate behaviour, but it stops me from pre-loading libraries to do these things:
zenity(or anything else using GTK >= 3 or adwaita) is used when running a game (this could be local code, and has been);I would prefer to have these globally set rather than having to do them per-game.
Needless to say, all is well with steamrt3 disabled.