Quantcast
Channel: CentOS Bug Tracker - Issues
Viewing all articles
Browse latest Browse all 19115

0006063: Python libraries are not linked correctly

$
0
0
Some (maybe all) of the Python modules that are included in the python package and which are distributed as .so files are lacking a dependency on libpython2.6.so. For example:<br /> <br /> # ldd -r /usr/lib64/python2.6/lib-dynload/timemodule.so <br /> linux-vdso.so.1 => (0x00007fff203ff000)<br /> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f97aa764000)<br /> libc.so.6 => /lib64/libc.so.6 (0x00007f97aa3d1000)<br /> /lib64/ld-linux-x86-64.so.2 (0x00007f97aab94000)<br /> undefined symbol: PyExc_ValueError (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyExc_IOError (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: _Py_NoneStruct (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyExc_OverflowError (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: Py_IgnoreEnvironmentFlag (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyModule_AddObject (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyArg_UnpackTuple (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyObject_CallMethod (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: Py_InitModule4_64 (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: floor (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyImport_ImportModuleNoBlock (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyErr_NoMemory (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyString_FromStringAndSize (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyModule_AddIntConstant (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyFloat_FromDouble (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyArg_ParseTuple (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyErr_Occurred (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyEval_RestoreThread (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyString_FromString (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyInt_FromLong (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyEval_SaveThread (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyModule_GetDict (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyInt_AsLong (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyFloat_AsDouble (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyStructSequence_InitType (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: Py_BuildValue (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyStructSequence_New (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: fmod (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyDict_GetItemString (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyArg_Parse (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyErr_SetString (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> undefined symbol: PyErr_SetFromErrno (/usr/lib64/python2.6/lib-dynload/timemodule.so)<br /> <br /> Under most common usages libpython2.6.so would be available as a global object at the time these modules are dynamically linked, and therefore these symbols would successfully resolve. However if the main application is also not linked against libpython2.6.so, but loads it (directly or indirectly) via dlopen, then libpython.so is not global and importing any of these modules will fail.<br /> <br /> For example, consider an application that can be extended by plugins in the form of .so files. One of these .so files embeds the Python interpreter to allow further extensions in Python. These Python extensions will fail as soon as they attempt to import any of the improperly linked modules.<br /> <br /> Here's an example program:<br /> <br /> $ cat embed.c <br /> #include <stdlib.h><br /> #include <dlfcn.h><br /> <br /> typedef void (*initialize_t)(void);<br /> typedef void (*finalize_t)(void);<br /> typedef int (*run_string_t)(const char*, void*);<br /> <br /> int main(void)<br /> {<br /> void *lib;<br /> initialize_t initialize;<br /> finalize_t finalize;<br /> run_string_t run_string;<br /> <br /> lib = dlopen("/usr/lib64/libpython2.6.so", RTLD_NOW);<br /> if (lib == NULL)<br /> return 1;<br /> <br /> initialize = dlsym(lib, "Py_Initialize");<br /> finalize = dlsym(lib, "Py_Finalize");<br /> run_string = dlsym(lib, "PyRun_SimpleStringFlags");<br /> <br /> initialize();<br /> run_string("import time; print 'Success'", NULL);<br /> finalize();<br /> <br /> return 0;<br /> }<br /> $ gcc -o embed -ldl embed.c<br /> $ ./embed <br /> Traceback (most recent call last):<br /> File "<string>", line 1, in <module><br /> ImportError: /usr/lib64/python2.6/lib-dynload/timemodule.so: undefined symbol: PyExc_ValueError<br /> <br /> This is slightly contrived, since you would probably not dlopen libpython directly. However, you would have the same problem if you wrote a .so that used libpython2.6.so, then dlopened your .so. I skipped the extra .so to make the example a single file.

Viewing all articles
Browse latest Browse all 19115

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>