00001 00002 /* 00003 00004 This little beats is only needed on Unix platforms. The problem that 00005 we are facing here is that Python (shared) modules are compiled with 00006 unresolved symbols on Unix and are resolved at runtime from global 00007 symbols namespace. This is usually OK because Python interpreter or 00008 apps that embed Python link against libpython. In UPF, however, only 00009 python-loader.so needs libpython and because python-loader.so is loaded 00010 using dlopen() with RTLD_LOCAL flag, its symbols and symbols from all 00011 libraries it links against are *not* imported into global namespace. 00012 Consequently, Python is unable to load its modules because of unresolved 00013 symbols. 00014 00015 In order to solve this, we use python-loader-helper.so, which is a small 00016 shared library that is loaded at runtime by python-loader.so with 00017 RTLD_GLOBAL flag. This way all symbols from python-loader-helper.so are 00018 imported into global namespace and because the helper links against 00019 libpython, all Python symbols are available, and C++ symbols from 00020 python-loader.so are not globally visible. 00021 00022 */ 00023 00024 #include "config.h" 00025 #include PYTHON_INCLUDE 00026 00027 #ifdef __cplusplus 00028 extern "C" { 00029 #endif 00030 00031 typedef struct 00032 { 00033 DL_IMPORT(void) (*Py_Initialize)(void); 00034 DL_IMPORT(void) (*Py_Finalize)(void); 00035 DL_IMPORT(int) (*Py_IsInitialized)(void); 00036 DL_IMPORT(int) (*PyRun_SimpleString)(char *); 00037 DL_IMPORT(int) (*PyRun_SimpleFile)(FILE *, char *); 00038 } upf_python_api; 00039 00040 extern upf_python_api *__upf_getPythonAPI(void); 00041 typedef upf_python_api* (*__upf_getPythonAPI_Func)(void); 00042 #define __upf_getPythonAPI_Name "__upf_getPythonAPI" 00043 00044 #ifdef __cplusplus 00045 } 00046 #endif