Dynamic linking - another idea

Okay, so here's a crazy idea to make dynamic libraries in the same package work. Suppose the linker includes an rpath of '.' (aka os.curdir), and renames each extension module that's using a library such that it's not directly importable by Python. Setuptools already generates a stub .py file loader for extension modules anyway during bdist_egg, so that zipped extensions can be extracted. So, this stub could just change directory to the directory of the extension before doing the import, with setdlopenflags(RTLD_NOW). If I understand correctly, this should force all symbols in the extension to be resolved immediately, so the '.' rpath would let the extension load the nearby library. After this was done, the stub code would restore the original current directory and dlopen flags. Since extensions built this way would not be directly importable, it would ensure that the stub is always used. And since they do not require a hardcoded real path, they would be relocatable and manually extractable from the zipfile. Does any see any holes in this, aside from the sheer craziness of doing it? :) That is, are there any platforms where a '.' rpath is forbidden? Where RTLD_NOW won't let it resolve all the symbols? Where the '.' rpath is interpreted as the executable's startup directory rather than as the load-time current directory?
participants (1)
-
Phillip J. Eby