I am working on embedding some python code into into a kdb database by creating c extensions.  To do this I need to compile my code into a shared library and within my kdb q script load the shared library.  This issue I am having is when I try to import the numpy module.  I get an error saying the PyType_GenericNew is undefined.  This occurs at runtime not compile time.  
The shared library I am building is linked with libpython3.5m.so but I guess this does not export the symbols golbally.  When I made a test executable which imports numpy in the main() it runs fine.   I was able to fix this issue in the shared library by calling dlopen("libpython3.5m.so", RTLD_NOW | RTLD_GLOBAL).  I don't however really like this solution since it is not very robust.  Say for instance I changed my compile options to like against libpython3.4m.  Then I would need to change the source code as well so dlopen opens libpython3.4m.
Is there a way to tell gcc when I link using the -lpython3.5m option to export all the symbols globally?  This way I can skip the dlopen.
Otherwise is there something in the python c api which can tell me the path to the python shared library of which I am currently using?  Ie something like dlopen(Py_GetLibraryPath(), RTLD_NOW | RTLD_GLOBAL)
Your problem has nothing to do with exporting symbols, but with the dynamic linker locating PyType_GenericNew. If libpython3.5m.so is in your library path, and your dynamic linker doesn't find it, running strace ldd ./program will provide a hint as to where it's looking, and a well-placed symbolic link may sort you out.
Get full path to shared object with python c api