Build -system-info and -check-locale with relative DT_RPATH
This ensures that they can find the non-ubiquitous json-glib library, and the steam-runtime-tools library, even if relocated into a non-standard prefix like the LD_LIBRARY_PATH Steam Runtime.
We can't just use a relative version of the standard library directory as our RPATH, because if we did that, we would load glibc from the same place. This causes crashes in pressure-vessel, where ld.so and the rest of glibc are often taken from the host system via /overrides/lib, and the glibc in /lib and /usr/lib is incompatible with ld.so. Instead, use a private library directory and populate it with relative symlinks to our non-glibc dependencies; we assume the host version of glibc is new enough that this is OK.
Using DT_RPATH in preference to DT_RUNPATH means we take all our direct and indirect dependencies from the same place. This is important when libjson-glib (which won't ordinarily have a RUNPATH or RPATH) pulls in GIO as an indirect dependency of check-locale, which doesn't directly depend on GIO. The GIO library we get must match the versions of GLib and GObject we're using.
This also bypasses LD_LIBRARY_PATH.
This is a redo of !78 (merged), fixing the regression that it caused (I reverted the commit rather than leave it broken).
Latest test-build: https://images.internal.steamos.cloud/playground/steamrt-scout/t17169/
This regression suggests that in addition to https://phabricator.collabora.com/T17426 we need to have an automated test that is run from (/playground)/scout/build
and exercises pressure-vessel-wrap
wrapped around steam-runtime-system-info
. This would probably need to be done in a qemu virtual machine via autopkgtest, because bwrap inside Docker will be a pain to achieve, but the first step towards that would be to make a mostly-automated test that can be run on a developer's system with a documented setup.
/cc @denittis @jpwhiting