When I import a module I built, I get this boost-python related error:
Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: dlopen(./myMod.so, 2): Symbol not found: __ZN5boost6python7objects15function_objectERKNS1_11py_functionERKSt4pairIPKNS0_6detail7keywordES9_E Referenced from: ./myMod.so Expected in: flat namespace in ./myMod.so
What does this actually mean? Why was this error raised?
The problem was caused by mixing objects that compiled with
libc++ and object that compiled with
In our case, the library
myMod.so (compiled with
boost-python that compiled with
boost-python-libstdc++ from now). When
boost-python-libstdc++, it will work fine. Otherwise – on computer that its
boost-python has compiled with
libc++ (or another c++ library), it will have a problem loading and running it.
In our case, it happens because that
libc++ developers intentionally changed the name of all of their symbols to prevent you (and save you) from mixing code from their library and code from a different one:
myMod.so need a function that take an argument from the type. In
libc++, this type’s name is
std::__1::pair. Therefore, this symbol was not found.
To understand why mixing two version of the same API is bad, consider this situation: There are two libraries:
Bar. They both have a function that takes a
std::string and uses it for something but they use a different c++ library. When a
std::string that has been created by
Foo will be passed to
Bar will think that this is an instance of its c++ library’s
std::string and then bad things can happen (they are a completely different objects).
Note: In some cases, there would be no problem with two or more different versions of the same API in a completely different parts of a program. There will be a problem if they will pass this API’s objects between them. However, checking that can be very hard, especially if they pass the API object only as a member of another object. Also, a library’s initialization function can do things that should not happen twice. Another version may do these things again.
How to solve that?
You can always recompile your libraries and make them match each other.
You can link
boost-pythonto your library as a static library. Then, it will work on almost every computer (even one that doesn’t has
boost-pythoninstalled). See more about that here.
myMod.so need another version of
boost-python, one that compiled with a specific c++ library. Therefore, It would not work with any another version.
Symbol not found means the definition of the declared function or variable was not found. When a header file of a shared object is compiled with your program, linker adds symbols of declared functions and objects to your compiled program. When your program is loaded by the OS’s loader, the symbols are resolved so that their definition will be loaded. It is only at this time where if the implementation is missing, loader complains it couldn’t find the definition due to may be failing to resolve the actual path to the library or the library itself wasn’t compiled with the implementation/source file where the definition of the function or object resides. There is a good article on this on the linux journal http://www.linuxjournal.com/article/6463.
I encounter the same problem.
Expected in: flat namespace
Add the linker flag fixes the problem
change the dynamic library name to the one installed on the os.
By the way, my os is macOS High Sierra and I use brew to install
In my case I was just failing to import all the required sources (c++ files) when compiling with Cython.
From the string after “Symbol not found” you can understand which library you are missing.
Here’s what I’ve learned (osx):
If this is supposed to work (i.e. it works on another computer), you may be experiencing clang/gcc issues. To debug this, use
otool -l on the .so file which is raising the error, or a suspect library (in my example it’s a boost-python dylib file) and examine the contents. Anything in the /System/ folder is built with clang, and should be installed somewhere else with the gcc compiler. Never delete anything in the /System folder.
.so files are dynamic libraries (so = shared object). On Windows they are called
.dll (dynamic-link library). They contain compiled code which contains functions available for usage to any executable which links them.
What is important to notice here is that those
.so are not Python files. They were probably compiled from C or C++ code and contain public functions which can be used from Python code (see documentation on Extending Python with C or C++).
On your case, well, you have a corrupt
.so. Try reinstalling the affected libraries, or Python, or both.