Skip to content

pv-runtime: Try to mount /usr/${LIB}/gconv into container

Simon McVittie requested to merge wip/task477 into main

  • pv-runtime: Try to mount /usr/${LIB}/gconv into container

    Previously we assumed that the hard-coded directory used to dlopen gconv modules matched the realpath() of the directory containing libc.so.6, disregarding any compatibility symlinks: for example, on Red Hat, 64-bit gconv modules are in /usr/lib64/gconv, and on Debian they're in /usr/lib/x86_64-linux-gnu/gconv.

    However, this turns out not to be true on Void Linux, where /usr/lib64 -> lib is a non-canonical path, but the hard-coded path that will be used to load iconv modules is /usr/lib64/gconv anyway.

    We cannot simply set GCONV_PATH, because apparently setting GCONV_PATH=/usr/lib/gconv:/usr/lib32/gconv will break 32-bit applications: unlike the equivalent with LD_LIBRARY_PATH, a 32-bit application would try and fail to load the 64-bit module from /usr/lib/gconv (it will fail to load because its word size does not match the word size of the process), and then will not fall back to /usr/lib32/gconv as one might expect.

    Luckily, on Void Linux, the libdl dynamic string token ${LIB} has been chosen such that the correct path for each architecture's gconv modules is /usr/${LIB}/gconv. We can use this as an additional guess at the necessary mount point for the gconv modules, mounting /usr/lib/gconv onto both /usr/lib/gconv and /usr/lib64/gconv - that way, it doesn't matter whether the path hard-coded in glibc matches our old heuristic or our new heuristic, because either one will work.

    steamrt/tasks#477, ValveSoftware/steam-runtime#680

/cc @refi64

Edited by Simon McVittie

Merge request reports