Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
I was getting the following error after a Steam update:
internal error: /steamrt/setup.sh is missing, this runtime is invalid or corrupted
The script is used to put things on PATH but it doesn't seem we need to do that.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
* Update dependencies using steam-native-runtime from Arch Linux as a
reference.
* Remove native-only Steam Runtime, just use installed libraries
instead.
* Mark native-only Steam as broken (due to segfault inside D-Bus). Seems it was
already broken for a long time. Doesn't apply to steam-run.
* Some cleanups for chrootenv.
NixOS: Failing to set hardware.opengl.driSupport32Bit will lead to a
confusing error message about missing libGL.so.1. We include a wrapper
around the steam bin to test for working 32bit opengl with glxinfo. When
failing, we display a proper warning hinting towards the option.
Fixes: #19518
Some games (in my case Stardew Valley) require at least something in
/etc/localtime. The actual file linked there doesn't matter as long as
it's some valid timezone.
Example: instead of
(steamPackages.override { newStdcpp = true; }).steam-chrootenv
(which wasn't working anyway) you now do just:
steam.override { newStdcpp = true; }
