Repository navigation
Conversation
|
Draft upstream issue title: Relocated Unix runtimes can fail to find the standard library Draft upstream issue body: On Linux, an embedded Python can fail to find the standard library beside its executable if This can be reproduced with a static debug build of CPython at #include <Python.h>
int main(void) {
PyConfig config;
PyConfig_InitPythonConfig(&config);
config.use_environment = 0;
config.site_import = 0;
PyStatus status = PyConfig_SetString(&config, &config.executable, L"/nonexistent/launcher");
if (!PyStatus_Exception(status)) status = Py_InitializeFromConfig(&config);
PyConfig_Clear(&config);
if (PyStatus_Exception(status)) Py_ExitStatusException(status);
int result = PyRun_SimpleString("import sys; print(sys.base_prefix)");
Py_Finalize();
return result;
}The compile-time prefix must not contain another usable standard library. Build the host against the matching static library and run it from outside the installation. It fails to initialize on the unmodified build; locating the mapped executable and searching its parents finds the relocated prefix. There's a related issue with shared libraries: for We carry a patch for this in CPython versions tested on:CPython main branch Operating systems tested on:Linux (Ubuntu 24.04, x86-64) |
Standard-library discovery beside a Unix runtime library misses the usual
prefix/lib/libpythonlayout. Search parent directories for the standard-library landmarks while retaining adjacent framework and Windows layouts. On Linux, use the mapped runtime filename to handle relative loader paths and executables linked with a staticlibpython.Addresses the library-resolution change tracked in astral-sh/python-build-standalone#909.