Bug 874874 - undefined symbols in timemodule.so
undefined symbols in timemodule.so
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python (Show other bugs)
All Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Dave Malcolm
BaseOS QE - Apps
Depends On:
  Show dependency treegraph
Reported: 2012-11-08 19:04 EST by Johnny Hughes
Modified: 2012-11-13 21:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-09 11:26:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Possible patch (550 bytes, patch)
2012-11-12 15:19 EST, Kevin Goodsell
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
CentOS 6063 None None None 2012-11-08 19:04:26 EST

  None (edit)
Description Johnny Hughes 2012-11-08 19:04:26 EST
Description of problem:
# ldd -r /usr/lib64/python2.6/lib-dynload/timemodule.so
        linux-vdso.so.1 => (0x00007fff203ff000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f97aa764000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f97aa3d1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f97aab94000)
undefined symbol: PyExc_ValueError (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyExc_IOError (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: _Py_NoneStruct (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyExc_OverflowError (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: Py_IgnoreEnvironmentFlag (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyModule_AddObject (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyArg_UnpackTuple (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyObject_CallMethod (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: Py_InitModule4_64 (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: floor (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyImport_ImportModuleNoBlock (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyErr_NoMemory (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyString_FromStringAndSize (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyModule_AddIntConstant (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyFloat_FromDouble (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyArg_ParseTuple (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyErr_Occurred (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyEval_RestoreThread (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyString_FromString (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyInt_FromLong (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyEval_SaveThread (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyModule_GetDict (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyInt_AsLong (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyFloat_AsDouble (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyStructSequence_InitType (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: Py_BuildValue (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyStructSequence_New (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: fmod (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyDict_GetItemString (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyArg_Parse (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyErr_SetString (/usr/lib64/python2.6/lib-dynload/timemodule.so)
undefined symbol: PyErr_SetFromErrno (/usr/lib64/python2.6/lib-dynload/timemodule.so)

This was reported on the CentOS bug tracker and I verified the same issue in RHEL 6.3.

This is with python-2.6.6-29.el6_3.3.x86_64
Comment 2 Dave Malcolm 2012-11-09 11:20:02 EST
The reproducer in the CentOS tracker seems contrived.  Surely any plugin that embeds Python can simply link against libpython directly, rather than dlopen it?
Comment 3 RHEL Product and Program Management 2012-11-09 11:26:26 EST
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 4 Kevin Goodsell 2012-11-09 13:41:34 EST
(In reply to comment #2)
> The reproducer in the CentOS tracker seems contrived.  Surely any plugin
> that embeds Python can simply link against libpython directly, rather than
> dlopen it?

As I said in the CentOS bug, I wrote the example that way to make it a single program. It doesn't matter if the plugin links libpython directly, it still won't be able to import the broken modules. Since the plugin is dlopened, libpython will be available to resolve symbols used by the plugin. However, it won't be available to resolve symbols used by any other dlopened object, such as the python modules.

If it will help I can write a longer example that demonstrates the fact that you cannot write a plugin which embeds Python and actually uses these Python modules.
Comment 5 Kevin Goodsell 2012-11-09 13:55:38 EST
The underlying problem here seems to stem from the patch python-2.6.2-config.patch. This patch causes the Python build to use an older system for building modules, and that system appears to be broken. By default the Python build uses the newer setup.py program to build modules.

However, using the new module building system would solve this problem while introducing another. It adds additional checks for the modules, so some (such as dl) won't get built on 64-bit platforms. That is relatively easy to fix, but there may be other problems as well. The upside is that this is a presumably a better-maintained system and should make things smoother going forward.
Comment 6 Johnny Hughes 2012-11-12 13:26:11 EST
So, it is perfectly acceptable for "ldd -r" to show undefined symbols when run against libraries?

Is it acceptable only in this case for some special reason or is it acceptable in other cases too?
Comment 7 Kevin Goodsell 2012-11-12 15:19:10 EST
Created attachment 643738 [details]
Possible patch

Here's a one-line patch that appears to fix the problem. It still seems like moving away from the old method of building modules would be less problematic in the long-run, but this introduces the proper link directive for the old method.
Comment 8 Kevin Goodsell 2012-11-13 21:06:40 EST
Here's an example using a plugin that links libpython.so directly.

[1044][xbvt@xbvt-staging-vm python-centos-modules]$ cat application.c 
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

typedef int (*plugin_init_t)(void);

int main(int argc, char *argv[])
    void *plugin;
    plugin_init_t init;

    if (argc != 2)
        fprintf(stderr, "No plugin argument given\n");
        return EXIT_FAILURE;

    plugin = dlopen(argv[1], RTLD_NOW);
    if (plugin == NULL)
        fprintf(stderr, "Failed to load plugin\n");
        return EXIT_FAILURE;

    init = dlsym(plugin, "plugin_init");

    return EXIT_SUCCESS;
[1045][xbvt@xbvt-staging-vm python-centos-modules]$ cat python_plugin.c 
#include <Python.h>

int plugin_init(void)
    PyRun_SimpleString("import time; print 'Success'");

    return 0;
[1046][xbvt@xbvt-staging-vm python-centos-modules]$ gcc -o application -ldl application.c 
[1047][xbvt@xbvt-staging-vm python-centos-modules]$ gcc -c `python-config --cflags` python_plugin.c 
[1049][xbvt@xbvt-staging-vm python-centos-modules]$ gcc -o python_plugin.so -shared `python-config --ldflags` python_plugin.o
[1050][xbvt@xbvt-staging-vm python-centos-modules]$ ./application ./python_plugin.so 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /usr/lib64/python2.6/lib-dynload/timemodule.so: undefined symbol: PyExc_ValueError

After installing an RPM built with my patch:

[1054][xbvt@xbvt-staging-vm python-centos-modules]$ ./application ./python_plugin.so 

I don't seem to have permission to reopen this bug, but I definitely think it should be reopened.

Note You need to log in before you can comment on or make changes to this bug.