The reproducer in the CentOS tracker seems contrived.  Surely any plugin that embeds Python can simply link against libpython directly, rather than dlopen it?

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

(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.

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.

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?

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.

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");
    init();

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

int plugin_init(void)
{
    Py_Initialize();
    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 
Success


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