On 23/02/2016 15:52, Greg Landrum wrote:
On Tue, Feb 23, 2016 at 3:50 PM, Paul Emsley
<pems...@mrc-lmb.cam.ac.uk <mailto:pems...@mrc-lmb.cam.ac.uk>> wrote:
This seems to be the relevant difference in the cmake output:
<snip>
[ 3%] Linking CXX shared library ../../lib/libRDBoost.dylib
Undefined symbols for architecture x86_64:
"boost::python::throw_error_already_set()", referenced from:
throw_index_error(int) in Wrap.cpp.o
throw_value_error(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >) in
Wrap.cpp.o
translate_index_error(IndexErrorException const&) in Wrap.cpp.o
translate_value_error(ValueErrorException const&) in Wrap.cpp.o
throw_runtime_error(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >) in
Wrap.cpp.o
translate_invariant_error(Invar::Invariant const&) in Wrap.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
make[2]: *** [lib/libRDBoost.2016.03.1.dev1.dylib] Error 1
make[1]: *** [Code/RDBoost/CMakeFiles/RDBoost.dir/all] Error 2
make: *** [all] Error 2
These functions are in libboost_python.dylib, but I don't know how
to tell cmake how to find them there when linking RDBoost.dylib.
Ah, very good. I think I know this one. The problem tends to be due to
a mixture of libraries that were built against the new C++ libraries
(the default with newer versions of clang) and those built using the
older C++ mode. You control this with the -stdlib flag to the C++
compiler. The two options are "-stdlib=libc++" (this is the newer
library and is now the default) or "-stdlib=libstdc++" (this is the
older one). The way you diagnose this is by looking at the output of
otool -L.
Here's a library built using the new one (the default now with homebrew):
~/rdk/RDKit_git/build_java % otool -L /usr/local/lib/libboost_regex.dylib
/usr/local/lib/libboost_regex.dylib:
/usr/local/opt/boost/lib/libboost_regex.dylib (compatibility version
0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)
And here's one built using the older version:
~/rdk/RDKit_git/build_java % otool -L
/usr/local/opt/boost_1_48/lib/libboost_regex.dylib
/usr/local/opt/boost_1_48/lib/libboost_regex.dylib:
libboost_regex.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 104.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)
Thanks.
Hmm... I notice that in the above, the libc++ version has the full path
name to itself but the libstdc++ one does not (is that the "shared
library ID"? (from otool man page)). My boost libraries are between
these examples (no path but using libc++):
[I substitute $install_prefix for the actual directory to make it more
generic]
$ otool -L $install_prefix/lib/libboost_python.dylib
$install_prefix/lib/libboost_python.dylib:
libboost_python.dylib (compatibility version 0.0.0, current version
0.0.0)
$install_prefix/lib/libpython2.7.dylib (compatibility version
2.7.0, current version 2.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)
But the bottom line is:
I installed Boost-1.60 and the boost python problem went away.
Paul.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
