-
Simon McVittie authored
An entry in LD_PRELOAD may be a bare SONAME like "libMangoHud.so", or a path containing special tokens like "/usr/$LIB/libMangoHud.so", or a literal path. Only literal paths are going to physically exist on disk. For a path containing special tokens, we can still try to remap it, for example /usr/$LIB/libMangoHud.so to /run/host/usr/$LIB/libMangoHud.so. This is imperfect (if the host and container glibc disagree on the meaning of $LIB, then we won't load it correctly), but it's better than nothing. A subsequent commit will improve the handling of paths that contain special tokens. For a bare SONAME, we just pass it through as-is for now, as though it was a relative path. This is also imperfect, but better than nothing. Another reason to want to make this change is that it allows us to unit-test this function: it's difficult to make assertions about the behaviour of a function that touches areas of the filesystem that are not under the control of the unit tests. Signed-off-by:
Simon McVittie <smcv@collabora.com>
Simon McVittie authoredAn entry in LD_PRELOAD may be a bare SONAME like "libMangoHud.so", or a path containing special tokens like "/usr/$LIB/libMangoHud.so", or a literal path. Only literal paths are going to physically exist on disk. For a path containing special tokens, we can still try to remap it, for example /usr/$LIB/libMangoHud.so to /run/host/usr/$LIB/libMangoHud.so. This is imperfect (if the host and container glibc disagree on the meaning of $LIB, then we won't load it correctly), but it's better than nothing. A subsequent commit will improve the handling of paths that contain special tokens. For a bare SONAME, we just pass it through as-is for now, as though it was a relative path. This is also imperfect, but better than nothing. Another reason to want to make this change is that it allows us to unit-test this function: it's difficult to make assertions about the behaviour of a function that touches areas of the filesystem that are not under the control of the unit tests. Signed-off-by:
Simon McVittie <smcv@collabora.com>