On Oct 14, 2014, at 8:41 PM, Greg Landrum <greg.land...@gmail.com> wrote:
> Hi Paul,
>
> On Tue, Oct 14, 2014 at 11:22 PM, Paul Emsley <pems...@mrc-lmb.cam.ac.uk>
> wrote:
>
> I'm a bit lost with boost::python/RDKit/MacOSX.
>
> I have a boost::python function:
>
> RDKit::ROMol *hydrogen_transformations(const RDKit::ROMol &r);
>
>
> which is exposed like this:
>
> BOOST_PYTHON_MODULE(pyrogen) {
>
> def("hydrogen_transformations", hydrogen_transformations,
> return_value_policy<manage_new_object>());
>
> }
>
>
> That all looks fine.
>
> When I run this on my computers (RHEL6, Ubuntu, Fedora), it compiles and runs
> fine fine. When Bill Scott tries on his Mac, at run-time he gets:
>
> File "/sw/lib/python2.7/site-packages/coot/pyrogen.py", line 607, in
> make_restraints
> sane_H_mol = pyrogen_boost.hydrogen_transformations(m_H)
> Boost.Python.ArgumentError: Python argument types in
> pyrogen_boost.hydrogen_transformations(Mol)
> did not match C++ signature:
> hydrogen_transformations(RDKit::ROMol)
>
>
> Where m_H is created like this:
>
> m_H = AllChem.AddHs(m)
>
> and has type:
>
> <class 'rdkit.Chem.rdchem.Mol'>
>
> I'm not following why a Mol is not an RDKit::ROMol.
>
> Don't get hung up on that bit; it's the usual way that those error messages
> are worded. The first bit tells you the python type name, the second the C++
> type name. The problem here is that it seems to not recognize that it should
> be able to translate the Mol into the ROMol.
>
> I'd appreciate any insight.
>
> ooof... insight's going to be tough... how about guesses? ;-)
>
> The first thing that comes to mind, and I'm not sure that this has any
> relevance at all, is that it could be an import order thing. Does Bill import
> Chem before he imports your code?
>
> The next possibility that I can come up with is that there was something
> different in the build of your code and the RDKit on Bill's machine. Either
> different compiler versions were used or different RDKit versions or
> different boost versions. This somehow ends up being enough to screw up the
> type recognition between the two extension modules. A check here is to be
> sure that they were built using the same environment, that Python is using
> the one you think it is, and that $DYLD_LIBRARY_PATHis set such that the
> correct RDKit libs are being found.
>
> -greg
Hi Greg:
Thanks for the feedback.
The main likely differences are
1. I am using Apple’s clang++
2. I am using (fink’s) boost1.53.python27 to build (fink’s) RDkit (vers
2014.03.1). It was kind of an ordeal to get it working, so there is a distinct
possibility I f-ed something up.
$DYLD_LIBRARY_PATH is by fink policy unset, but the library paths are all
correctly hard-coded, and (in my case at least) I don’t have any other set of
libs for it to find.
Thanks.
Bill
William G. Scott
http://scottlab.ucsc.edu/~wgscott
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
