Re: [Rdkit-discuss] Python argument types did not match C++ signature

[William G. S. <wg...@uc...>]

On Oct 14, 2014, at 8:41 PM, Greg Landrum <gre...@gm...> wrote:

> Hi Paul,
> 
> On Tue, Oct 14, 2014 at 11:22 PM, Paul Emsley <pe...@mr...> 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