Skip to content

Don't symlink all of /usr/${gnu_tuple}/lib, but be more selective

Simon McVittie requested to merge wip/exherbo into steamrt/scout

Previously, we made all of /usr/${gnu_tuple}/lib a symbolic link to /usr/lib/${multiarch_tuple}, so that when Exherbo ld.so or libraries look for architecture-specific content (in particular the dynamic linker), they find it in the Debian-style architecture-specific lib directory.

However, this causes problems in the presence of RPATHs. Some Exherbo libraries have a RPATH header pointing to /usr/${gnu_tuple}/lib; because RPATH is higher-precedence than LD_LIBRARY_PATH, this caused the runtime linker to load dependency libraries from the Steam Runtime's /usr/lib/${multiarch_tuple}, even if we had imported a newer version from the Exherbo host system into /overrides/lib/${multiarch_tuple} which we expected to be used instead.

Because Exherbo's glibc expects to load gconv plugins from /usr/${gnu_tuple}/lib/gconv, if Exherbo's glibc is newer than the runtime's (which in practice will often be true), we need to be able to bind-mount the gconv plugin directory from the host system; so we also create a mount point for that.

Thanks to @mawww on Github for testing this arrangement.


To be cherry-picked into all supported branches, but we only need to review this once.

Merge request reports