Re: [Rdkit-discuss] Atoms with strange positions/bonds when drawer makes PNG

2016-02-23 Thread Brian Kelley 
I have a fix for this in the conda recipes I can submit, it boils down to
something like the following ( setting the CXXFLAGS for c++11 )

if otool -L "$PYROOT/lib/libboost_python.dylib"  | grep libc++ ; then
FLAGS="-std=c++11 -stdlib=libc++"
else
FLAGS="-stdlib=libstdc++"
fi

CXXFLAGS=$FLAGS \
cmake -DPYTHON_EXECUTABLE=$PYROOT/bin/python  \
 ...

On Tue, Feb 23, 2016 at 10:52 AM, Greg Landrum 
wrote:

>
>
> On Tue, Feb 23, 2016 at 3:50 PM, Paul Emsley 
> wrote:
>
>>
>> This seems to be the relevant difference in the cmake output:
>>
>>
> 
>
>
>>
>> [  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> std::__1::char_traits, std::__1::allocator >) 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> std::__1::char_traits, std::__1::allocator >) 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  arguments here> ..
> or:
> CXX="/usr/bin/c++ -stdlib=libc++" cmake  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=/4140
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
--
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=/4140___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net

Re: [Rdkit-discuss] Atoms with strange positions/bonds when drawer makes PNG

2016-02-23 Thread Greg Landrum 
On Tue, Feb 23, 2016 at 3:50 PM, Paul Emsley 
wrote:

>
> This seems to be the relevant difference in the cmake output:
>
>



>
> [  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 std::__1::char_traits, std::__1::allocator >) 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 std::__1::char_traits, std::__1::allocator >) 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  ..
or:
CXX="/usr/bin/c++ -stdlib=libc++" cmake  ..


> 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=/4140___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Atoms with strange positions/bonds when drawer makes PNG

2016-02-18 Thread Paul Emsley 
Hi Greg,

I tried to investigate this further with github rdkit but I am as yet 
unable to configure/cmake it yet on this Mac (something related to boost 
python has changed) :-/ :-) - will keep poking at it and/or abstracting 
it...

Thanks,

Paul.

On 19/02/2016 09:19, Greg Landrum wrote:
>
>
> That is indeed very strange behavior and I can't think of what would 
> cause it. I'm not able to reproduce it with either the current github 
> master, the 2015_09_2, or the 2015_03_1 release. Can you please send 
> me a small test program that reproduces the problem?
>
>


--
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=/4140
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Atoms with strange positions/bonds when drawer makes PNG

2016-02-18 Thread Greg Landrum 
Hi Paul,

That is indeed very strange behavior and I can't think of what would cause
it. I'm not able to reproduce it with either the current github master, the
2015_09_2, or the 2015_03_1 release. Can you please send me a small test
program that reproduces the problem?

-greg


On Wed, Feb 17, 2016 at 1:10 AM, Paul Emsley 
wrote:

>
> Dear RDKitters,
>
> I have the following test code:
>
>std::string smiles="Clc1c1";
>RDKit::ROMol *m_local = RDKit::SmilesToMol(smiles);
>RDDepict::compute2DCoords(*m_local);
>RDKit::Conformer conf = m_local->getConformer();
>WedgeMolBonds(*m_local, );
>bool includeStereo = true;
>bool kekulize = false;
>std::string mol_file_name = "testmol.mol";
>RDKit::MolToMolFile(*m_local, mol_file_name, includeStereo, confId,
> kekulize);
>std::string png_file_name = "image-test.png";
>{
>   RDKit::MolDraw2DCairo drawer(200, 200);
>   drawer.drawMolecule(*m_local);
>   drawer.finishDrawing();
>   drawer.writeDrawingText(png_file_name.c_str());
>}
>
> The mol file seems sane (attached) but the png has strangely positioned
> atoms (the Cl in this case) (attached).
>
> What am I doing wrong?
>
> (Using RDKit-2015-03-01)
>
> Thanks,
>
> 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=/4140
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
--
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=/4140___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss