Skip to content
Snippets Groups Projects
Simon McVittie's avatar
Simon McVittie authored
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

Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
744fecda
History
Name Last commit Last update