Fix for Symbol not found error while loading dynamic python extensions

[adnanyaqoobvirk]

While importing subliminal package using lunatic-python, I have received Symbol not found error which is discussed here:

http://stackoverflow.com/questions/29880931/importerror-and-pyexc-systemerror-while-embedding-python-script-within-c-for-pam

I have made changes related to it and it is now working properly on Linux. I haven't tested it on other operating systems but the changes are cross-platform so they should work.

[bastibe]

It seems strange to me that you would have to dlopen the Python library in a Python extension that is supposed to be dlopened from Python. Are you sure this is the right thing to do?

[adnanyaqoobvirk]

Here is what I think is happening:

When we try to import a python package which is dependent on python extensions like datetime so python API tries to dynamically load these dependent extensions, this is where it spits a symbol not found error. Here assumption is that python library is already loaded so it should be able to resolve these symbols but it is not doing that and the guess is that already loaded symbols are not visible inside the python space.

So to work around this problem, we load the python library symbols using RTLD_GLOBAL so that they are visible to everyone.

There is another way and that is to load lunatic library in global space using following command:

package.loadlib('python.so', '*')

But I think it is better to handle it in lunatic code while initializing the python API.

[greatwolf]

Correct me if I'm wrong but on osx, doesn't dlopen with RTLD_GLOBAL by default? Definitely on windows for sure, the exported symbols in a dll is always globally visible with respect to the process it's loaded into.

Seems to me the only case that needs to be handled is when loading in a linux or unix environment. Also the dlopen statement needs to be inside #ifdef otherwise you end up calling this in windows which is obviously not valid. I would also prefer the safer snprintf.