test_remote_exec_deleted_libpython can fail when DT_RPATH selects libpython #160388

Bug report

On Linux/glibc, test_sys.TestRemoteExec.test_remote_exec_deleted_libpython can fail when the interpreter has a DT_RPATH that finds libpython. The test copies the library into a temporary directory and prepends that directory to LD_LIBRARY_PATH, expecting the child process to load the copy. glibc searches the interpreter's DT_RPATH first when there is no DT_RUNPATH, so the child can load the original library instead. After deleting the temporary copy, the test fails its assertion that the copy appears as a deleted mapping in /proc/<pid>/maps.

e.g.,

mkdir build-rpath
cd build-rpath
../configure --enable-shared --without-ensurepip \
    LDFLAGS="-Wl,--disable-new-dtags,-rpath,$PWD"
make -j8
./python -m test test_sys -m test_remote_exec_deleted_libpython -v

The test should explicitly preload its temporary copy of libpython so that the deleted-mapping assertion refers to the library actually loaded by the child.

Realistically, this is encountered when performing relocatable builds.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-160388: Load the copied library in the deleted-mapping test #160389
• gh-160388: Load the copied library in the deleted-mapping test #160396
• [3.15] gh-160388: Load the copied library in the deleted-mapping test (GH-160396) #160515
• [3.14] gh-160388: Load the copied library in the deleted-mapping test (GH-160396) #160516