On Tue, Feb 23, 2016 at 3:50 PM, Paul Emsley <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)


You cannot mix these, but you can control which gets used by cmake as
follows:
CXX="/usr/bin/c++ -stdlib=libstdc++" cmake <insert your usual cmake
arguments here> ..
or:
CXX="/usr/bin/c++ -stdlib=libc++" cmake <insert your usual cmake arguments
here> ..


> p.s.  Sorry for the delay, now back from my travels.
>

No worries, it gave me a chance to figure out how to at least diagnose
these problems.


> p.p.s. Is this a list where top-posting is preferred? (I'm an in-line
> quoter by preference)
>

I personally prefer in-line, but sometimes will use top-posting if I'm lazy
or if I'm using gmail on a mobile device (where the in-line quoting doesn't
always work as well as one might hope).

-greg
------------------------------------------------------------------------------
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

Reply via email to