Installing RDKit on Mac OSX 10.10.2 with java and inchi about homebrew-rdkit HOT 15 CLOSED

Just to be sure that this isn't something that has "accidentally" been fixed, can you please try installing the dev version of the rdkit with "brew install --HEAD rdkit"?

from homebrew-rdkit.

Hi Greg. Thanks for the quick reply. I have tried both --HEAD and without when compiling rdkit --with-java and I got the same error both times.

Does this mean that the --with-java
functionality is indeed not working right now?

Best,
Chris

On Apr 28, 2015, at 12:04 AM, Greg Landrum [email protected] wrote:

Just to be sure that this isn't something that has "accidentally" been fixed, can you please try installing the dev version of the rdkit with "brew install --HEAD rdkit"?

—
Reply to this email directly or view it on GitHub.

from homebrew-rdkit.

Oh and one other thing. We will need Java working for Mac OSX 10.8.5 to current (I'm on 10.10.2 currently). Some of our machines aren't allowed to be upgraded here yet for security purposes.

In general, we really need the Java bindings for windows 7, 8, RHEL 5, 6, and the aforementioned Mac versions. There may be other architectures in the future but we know of these for now.

If all you can do for the moment is the Mac versions that's enough for a start.

Just to give you a heads up, my group is at the National Center for Computational Toxicology at the EPA in Research Triangle Park, NC. We are working on developing a public web application that extensively used rdkit which is why we are needing these architectures.

The cheminformatics community is small, so I figured I would introduce myself and let you know where our group is.

Best,
Chris Fowler

On Apr 28, 2015, at 12:04 AM, Greg Landrum [email protected] wrote:

Just to be sure that this isn't something that has "accidentally" been fixed, can you please try installing the dev version of the rdkit with "brew install --HEAD rdkit"?

—
Reply to this email directly or view it on GitHub.

from homebrew-rdkit.

@GreNIX apologies that this has taken me so long to track down/reproduce, but I finally managed to reproduce the problem (accidentally, of course), and then, after some struggling, reproduce it.

The problem seems to be a bad interaction between SWIG, boost, and recent versions of clang on the Mac.
I was able to solve the problem by reverting to an older version of boost. I was able to get the rdkit java wrappers to build with an up-to-date XCode by using boost 1.48. I can confirm that neither 1.55 nor 1.56 work.

Is it possible to install boost 1.48 using homebrew?

-greg

from homebrew-rdkit.

hmm, looks like I spoke too soon.

The wrappers build, but the tests are failing to build for me. It looks like there may be an incompatibility with Java8 that is causing problems. <sigh>

from homebrew-rdkit.

Can you try it on Java 7 and 6 just to see if you get the same result?

On Nov 18, 2015, at 9:41 AM, Greg Landrum [email protected] wrote:

hmm, looks like I spoke too soon.

The wrappers build, but the tests are failing to build for me. It looks like there may be an incompatibility with Java8 that is causing problems.

—
Reply to this email directly or view it on GitHub.

from homebrew-rdkit.

Easier said that done. I found a way to patch it so that the docs build under java8, but I will need to spend a bit more time to confirm that this also works back to java 6.

diff --git a/Code/JavaWrappers/gmwrapper/CMakeLists.txt b/Code/JavaWrappers/gmwrapper/CMakeLists.txt
index 461bce4..d099215 100644
--- a/Code/JavaWrappers/gmwrapper/CMakeLists.txt
+++ b/Code/JavaWrappers/gmwrapper/CMakeLists.txt
@@ -140,7 +140,7 @@ endif()
ADD_CUSTOM_COMMAND(
   OUTPUT ${CMAKE_JAVA_TEST_OUTDIR}/org/RDKit/WrapperTests.class
-  COMMAND ${JAVA_COMPILE} -d ${CMAKE_JAVA_TEST_OUTDIR} -cp "${CMAKE_CURRENT_SOURCE_DIR}/org.RDKit.jar${PATH_SEP}${JUNIT_JAR}" ${JAVA_TEST_FILES}
+  COMMAND ${JAVA_COMPILE} -Xdoclint:none -d ${CMAKE_JAVA_TEST_OUTDIR} -cp "${CMAKE_CURRENT_SOURCE_DIR}/org.RDKit.jar${PATH_SEP}${JUNIT_JAR}" ${JAVA_TEST_FILES}
   WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/org.RDKit.jar ${JAVA_TEST_FILES}
)

from homebrew-rdkit.

Thanks for looking into this. I appreciate it.

Chris Fowler

On Wed, Nov 18, 2015 at 9:57 AM, Greg Landrum [email protected]
wrote:

Easier said that done. I found a way to patch it so that the docs build
under java8, but I will need to spend a bit more time to confirm that this
also works back to java 6.

diff --git a/Code/JavaWrappers/gmwrapper/CMakeLists.txt b/Code/JavaWrappers/gmwrapper/CMakeLists.txt
index 461bce4..d099215 100644
--- a/Code/JavaWrappers/gmwrapper/CMakeLists.txt
+++ b/Code/JavaWrappers/gmwrapper/CMakeLists.txt
@@ -140,7 +140,7 @@ endif()
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_JAVA_TEST_OUTDIR}/org/RDKit/WrapperTests.class

• COMMAND ${JAVA_COMPILE} -d ${CMAKE_JAVA_TEST_OUTDIR} -cp "${CMAKE_CURRENT_SOURCE_DIR}/org.RDKit.jar${PATH_SEP}${JUNIT_JAR}" ${JAVA_TEST_FILES}
• COMMAND ${JAVA_COMPILE} -Xdoclint:none -d ${CMAKE_JAVA_TEST_OUTDIR} -cp "${CMAKE_CURRENT_SOURCE_DIR}/org.RDKit.jar${PATH_SEP}${JUNIT_JAR}" ${JAVA_TEST_FILES}
  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/org.RDKit.jar ${JAVA_TEST_FILES}
  )

—
Reply to this email directly or view it on GitHub
#25 (comment)
.

from homebrew-rdkit.

I've been looking into this. I have compile working with boost 1.60 and Java 1.8.0_77, but still no javadoc. I got this far via:

diff --git a/Code/JavaWrappers/gmwrapper/CMakeLists.txt b/Code/JavaWrappers/gmwrapper/CMakeLists.txt
index 2095d8e..ab55cce 100644
--- a/Code/JavaWrappers/gmwrapper/CMakeLists.txt
+++ b/Code/JavaWrappers/gmwrapper/CMakeLists.txt
@@ -48,6 +48,9 @@ endif()
 # Coax SWIG into playing nicely with Apple environments
 if(APPLE)
   SET(CMAKE_SIZEOF_VOID_P 4)
+  # Invocation of the compiler on swig-generated files somehow 'forgets' that
+  # we use a modern dialect of C++
+  ADD_COMPILE_OPTIONS(-std=c++14)
 endif(APPLE)

 if(CMAKE_SIZEOF_VOID_P MATCHES 4)

*** Edit:
After updating RDKit to HEAD, I can now build all the way through. W00t!

from homebrew-rdkit.

The problem that Nik is fixing with the --std=c++14 flag is a tricky one.
Recent versions of the OS X include at least two different versions of the C++ libraries: one for older flavors of C++ and one for modern C++ (=C++11/14). You pick which one to use at compile/link time with the -std and/or -stdlib arguments.
For the RDKit it doesn't matter (yet) which standard you pick, but I believe you can only use one at a time. So you cannot, for example, combine libraries that have been linked against stdc++ and libc++.

@bp-kelley posted some code to test for library versions on OS X here: http://www.mail-archive.com/[email protected]/msg05322.html

Here's the test:

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

from homebrew-rdkit.

I just make a pull request for CMake to pick the right version of libc++ on
OSX. You may want to try it out and see if it works for you:

rdkit/rdkit#845

This was hair-pulling for a while until we figured it out. The problem
isn't really that libc++ and stdlibc++ can't work together, they were
designed not to collide (except on osx 10.8), the problem is that boost was
compiled with libc++ and the symbols can't be found.

Cheers,
Brian

On Tue, Apr 5, 2016 at 12:16 AM, Greg Landrum [email protected]
wrote:

The problem that Nik is fixing with the --std=c++14 flag is a tricky one.
Recent versions of the OS X include at least two different versions of the
C++ libraries: one for older flavors of C++ and one for modern C++
(=C++11/14). You pick which one to use at compile/link time with the -std
and/or -stdlib arguments.
For the RDKit it doesn't matter (yet) which standard you pick, but I
believe you can only use one at a time. So you cannot, for example, combine
libraries that have been linked against stdc++ and libc++.

@bp-kelley https://github.com/bp-kelley posted some code to test for
library versions on OS X here:
http://www.mail-archive.com/[email protected]/msg05322.html

Here's the test:

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

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#25 (comment)

from homebrew-rdkit.

I just tried that fix instead of mine, and can confirm that it works! Thanks!

from homebrew-rdkit.

Great! Thanks for trying the build.

from homebrew-rdkit.

RDKit folks,

So I really appreciate your diligence on this. I've actually left the EPA
for graduate school so I won't be needing any more correspondence. Thank
you guys very much for all of your hard work!

Best,
Chris Fowler

On Tue, Apr 5, 2016 at 12:24 PM, Brian Kelley [email protected]
wrote:

I just make a pull request for CMake to pick the right version of libc++ on
OSX. You may want to try it out and see if it works for you:

rdkit/rdkit#845

This was hair-pulling for a while until we figured it out. The problem
isn't really that libc++ and stdlibc++ can't work together, they were
designed not to collide (except on osx 10.8), the problem is that boost was
compiled with libc++ and the symbols can't be found.

Cheers,
Brian

On Tue, Apr 5, 2016 at 12:16 AM, Greg Landrum [email protected]
wrote:

The problem that Nik is fixing with the --std=c++14 flag is a tricky one.
Recent versions of the OS X include at least two different versions of
the
C++ libraries: one for older flavors of C++ and one for modern C++
(=C++11/14). You pick which one to use at compile/link time with the -std
and/or -stdlib arguments.
For the RDKit it doesn't matter (yet) which standard you pick, but I
believe you can only use one at a time. So you cannot, for example,
combine
libraries that have been linked against stdc++ and libc++.

@bp-kelley https://github.com/bp-kelley posted some code to test for
library versions on OS X here:

http://www.mail-archive.com/[email protected]/msg05322.html

Here's the test:

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

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<
https://github.com/rdkit/homebrew-rdkit/issues/25#issuecomment-205635577>

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#25 (comment)

from homebrew-rdkit.

this is so old, I guess it can be closed

from homebrew-rdkit.