Unable to build with boost 1.71 on Debian #3030

shirishag75 · 2020-03-23T20:56:45Z

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954351

During compilation it bugs out at -


> -- Configuring done
> CMake Error at Code/cmake/Modules/RDKitUtils.cmake:153 (add_executable):
>   Target "testCoordGen" links to target "Boost::system" but the target was
>   not found.  Perhaps a find_package() call is missing for an IMPORTED
>   target, or an ALIAS target is missing?
> Call Stack (most recent call first):
>   External/CoordGen/CMakeLists.txt:110 (rdkit_test)

This would be in a Debian sid/unstable chroot or shroot . Python used would be python 3.8.2-2 . Boost being used is

I did have a brief look at https://github.com/rdkit/rdkit/blob/master/Code/cmake/Modules/RDKitUtils.cmake

and saw that at line 153 this shows up -

if(RDK_BUILD_CPP_TESTS)
    add_executable(${RDKTEST_NAME} ${RDKTEST_SOURCES})
    target_link_libraries(${RDKTEST_NAME} ${RDKTEST_LINK_LIBRARIES})
    add_test(${RDKTEST_NAME} ${EXECUTABLE_OUTPUT_PATH}/${RDKTEST_NAME})
  endif(RDK_BUILD_CPP_TESTS)

line 153 starts from add_executable

and the other one -

https://github.com/rdkit/rdkit/blob/master/External/CoordGen/CMakeLists.txt

line 110 starts from -

${RDK_COORDGEN_LIBS} Depictor

Also sharing the compile log in case if that gives you any more clues.
rdkit.log.gz

The text was updated successfully, but these errors were encountered:

e-kwsm · 2020-03-24T00:55:18Z

I've also encountered a similar issue and supplying -DBoost_NO_BOOST_CMAKE=ON solves it.

1733  dh_auto_configure -- -DCMAKE_BUILD_TYPE=None -DCMAKE_SKIP_RPATH=ON -DRDK_INSTALL_INTREE=OFF -DRDK_INSTALL_STATIC_LIBS=OFF -DRDK_BUILD_THREADSAFE_SSS=ON -DRDK_BUILD_PYTHON_WRAPPERS=ON -DRDK_OPTIMIZE_NATIVE=OFF -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_EXECUTABLE=/usr/bin/python3.7 ../
1734     cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_BUILD_TYPE=None -DCMAKE_SKIP_RPATH=ON -DRDK_INSTALL_INTREE=OFF -DRDK_INSTALL_STATIC_LIBS=OFF -DRDK_BUILD_THREADSAFE_SSS=ON -DRDK_BUILD_PYTHON_WRAPPERS=ON -DRDK_OPTIMIZE_NATIVE=OFF -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_EXECUTABLE=/usr/bin/python3.7 ../ ..
1779  -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.56.0") found components:  serialization 
1781  -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.56.0") found components:  system iostreams

That fixes the issue?

adalke · 2020-03-30T15:24:44Z

I have essentially the same problem. I'm compiling RDKit 2020_3 using Python 3.9a1, and Boost 1.72, all built today. cmake is version 3.15.5 . I configured the RDKit cmake step as:

cmake .. -DRDK_INSTALL_INTREE=OFF -DCMAKE_INSTALL_PREFIX=/Users/dalke/venvs/py39-2020-3 \
  -DCMAKE_INSTALL_RPATH=/Users/dalke/venvs/py39-2020-3/lib/:/Users/dalke/local/lib/  \
  -DPYTHON_INCLUDE_DIR=/Users/dalke/local/include/python3.9/ \
  -DRDK_BUILD_AVALON_SUPPORT=ON \
  -DRDK_BUILD_CAIRO_SUPPORT=ON \
  -DRDK_BUILD_INCHI_SUPPORT=ON

I get the same messages when cmake finishes:

CMake Error at Code/cmake/Modules/RDKitUtils.cmake:153 (add_executable):
  Target "testCoordGen" links to target "Boost::system" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

It's possible to build, but then I get an error part way through when it tries to link to -lBoost::system -lBoost::iostreams. From "make VERBOSE=1" I see (with newlines added):

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-mpopcnt -Wall -Wextra -Wno-deprecated -Wno-unused-function
-fno-strict-aliasing -Wno-format -Wno-logical-op-parentheses -fPIC
-stdlib=libc++ -O3 -DNDEBUG -dynamiclib
-Wl,-headerpad_max_install_names -compatibility_version 1.0.0
-current_version 2020.3.1 -o
../../../lib/libRDKitDepictor.2020.03.1.dylib -install_name
@rpath/libRDKitDepictor.1.dylib
CMakeFiles/Depictor.dir/RDDepictor.cpp.o
CMakeFiles/Depictor.dir/EmbeddedFrag.cpp.o
CMakeFiles/Depictor.dir/DepictUtils.cpp.o
-Wl,-rpath,/Users/dalke/ftps/rdkit-Release_2020_03_1/build_py39-2020-3/lib
-Wl,-rpath,/Users/dalke/local/lib
../../../lib/libRDKitMolAlign.2020.03.1.dylib
../../../lib/libRDKitcoordgen.2020.03.1.dylib
../../../lib/libRDKitmaeparser.2020.03.1.dylib -lBoost::system
-lBoost::iostreams ../../../lib/libRDKitMolTransforms.2020.03.1.dylib
../../../lib/libRDKitEigenSolvers.2020.03.1.dylib
../../../lib/libRDKitAlignment.2020.03.1.dylib
../../../lib/libRDKitForceFieldHelpers.2020.03.1.dylib
../../../lib/libRDKitSubstructMatch.2020.03.1.dylib
../../../lib/libRDKitSmilesParse.2020.03.1.dylib
../../../lib/libRDKitForceField.2020.03.1.dylib
../../../lib/libRDKitOptimizer.2020.03.1.dylib
../../../lib/libRDKitTrajectory.2020.03.1.dylib
../../../lib/libRDKitGraphMol.2020.03.1.dylib
../../../lib/libRDKitRingDecomposerLib.2020.03.1.dylib
../../../lib/libRDKitRDGeometryLib.2020.03.1.dylib
../../../lib/libRDKitDataStructs.2020.03.1.dylib
../../../lib/libRDKitRDGeneral.2020.03.1.dylib
/Users/dalke/local/lib/libboost_system.dylib
/Users/dalke/local/lib/libboost_iostreams.dylib

In particular, note the two lines:

../../../lib/libRDKitmaeparser.2020.03.1.dylib -lBoost::system
-lBoost::iostreams ../../../lib/libRDKitMolTransforms.2020.03.1.dylib

greglandrum · 2020-03-31T06:50:49Z

@adalke can you please try adding -DBoost_NO_BOOST_CMAKE=ON to your cmake line?

shirishag75 · 2020-03-31T07:28:54Z

@adalke can you please try adding -DBoost_NO_BOOST_CMAKE=ON to your cmake line?

but isn't that a workaround then trying to fix the issue as it is ? If I'm understanding that flag correctly, you are telling that try to build without the boost shared libraries which are on the system of the user.

greglandrum · 2020-03-31T07:52:36Z

It is a workaround, but it has the chance to get Andrew a working build until the RDKit build system is updated (assuming that happens).

If I'm understanding that flag correctly, you are telling that try to build without the boost shared libraries which are on the system of the user.

Actually I believe this particular flag is to allow cmake configurations that work with older boost distributions to continue to work with new boost distributions, which is exactly the situation here.

Hopefully someone will have the time and inclination to look into how to change the RDKit's build configuration to simultaneously support both styles without the user needing to provide the cmake flag, but in the meantime we're using the system the way it was meant to be used.

adalke · 2020-03-31T08:00:12Z

Adding -DBoost_NO_BOOST_CMAKE=ON makes things worse. Here's the modified cmake:

cmake .. -DRDK_INSTALL_INTREE=OFF 
 -DCMAKE_INSTALL_PREFIX=/Users/dalke/venvs/py39-2020-3
 -DCMAKE_INSTALL_RPATH=/Users/dalke/venvs/py39-2020-3/lib/:/Users/dalke/local/lib/ 
 -DPYTHON_INCLUDE_DIR=/Users/dalke/local/include/python3.9/
 -DRDK_BUILD_AVALON_SUPPORT=ON
 -DRDK_BUILD_CAIRO_SUPPORT=ON
 -DRDK_BUILD_INCHI_SUPPORT=ON
 -DBoost_NO_BOOST_CMAKE=ON

The output has a number of cmake warnings starting with:

-- Found PythonLibs: /Library/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7m.dylib (found version "3.9.0a1")
CMake Warning at /usr/local/Cellar/cmake/3.15.5/share/cmake/Modules/FindBoost.cmake:1144 (message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.15.5/share/cmake/Modules/FindBoost.cmake:1266 (_Boost_COMPONENT_DEPENDENCIES)
  /usr/local/Cellar/cmake/3.15.5/share/cmake/Modules/FindBoost.cmake:1904 (_Boost_MISSING_DEPENDENCIES)
  CMakeLists.txt:255 (find_package)

The output ends with an error; the end of the cmake output is:

CMake Error at /usr/local/Cellar/cmake/3.15.5/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find Boost (missing: python) (found suitable version "1.72.0",
  minimum required is "1.56.0")
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.15.5/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/Cellar/cmake/3.15.5/share/cmake/Modules/FindBoost.cmake:2161 (find_package_handle_standard_args)
  CMakeLists.txt:263 (find_package)


-- Configuring incomplete, errors occurred!
See also "/Users/dalke/ftps/rdkit-Release_2020_03_1/build_py39-2020-3/CMakeFiles/CMakeOutput.log".

If I try to make:

% make
make: *** No targets specified and no makefile found.  Stop.

e-kwsm · 2020-03-31T08:06:33Z

Note: I build boost 1.72.0 from tarball on Debian Buster. I use CMake, GCC, and Python provided by apt.

Could NOT find Boost (missing: python) (found suitable version "1.72.0",
minimum required is "1.56.0")

Do you build boost.python?

ptosco · 2020-03-31T08:28:39Z

@adalke Hi Andrew, try adding -DBoost_DEBUG=ON to your cmake command.
That switch triggers more verbose output by cmake which often helps figuring out what the actual problem is.

adalke · 2020-03-31T09:12:14Z

Well, yes, I built boost.python. That's why the earlier builds (before I specified -DBoost_NO_BOOST_CMAKE=ON) got as far as they did, and why you can see -- Found PythonLibs: /Library/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7m.dylib (found version "3.9.0a1") in one of my earlier comments.

I modified CMakeLists.txt to force the system and iostreams components to be included:

*** CMakeLists.txt	2020-03-31 10:02:40.000000000 +0200
--- CMakeLists.txt.orig	2020-03-30 15:54:28.000000000 +0200
***************
*** 264,270 ****
    endif()


-   find_package(Boost 1.56.0 COMPONENTS system iostreams REQUIRED)
    if(RDK_INSTALL_INTREE)
      set(RDKit_PythonDir "${CMAKE_SOURCE_DIR}/rdkit")
    else(RDK_INSTALL_INTREE)
--- 264,269 ----

That issues no warnings during 'cmake' and compilation goes to completion. However, I cannot import rdkit after installing:

% env DYLD_LIBRARY_PATH=/Users/dalke/venvs/py39-2020-3/lib python -c 'import rdkit'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/dalke/venvs/py39-2020-3/lib/python3.9/site-packages/rdkit/__init__.py", line 2, in <module>
    from .rdBase import rdkitVersion as __version__
ImportError: dlopen(/Users/dalke/venvs/py39-2020-3/lib/python3.9/site-packages/rdkit/rdBase.so, 2): Symbol not found: __ZN5boost6python23throw_error_already_setEv
  Referenced from: /Users/dalke/venvs/py39-2020-3/lib/libRDKitRDBoost.1.dylib
  Expected in: flat namespace
 in /Users/dalke/venvs/py39-2020-3/lib/libRDKitRDBoost.1.dylib

That's missing the dynamic link to libboost_python, which are in:

% ls ~/local/lib/libboost_python*
/Users/dalke/local/lib/libboost_python.a	/Users/dalke/local/lib/libboost_python3.a	/Users/dalke/local/lib/libboost_python39.a
/Users/dalke/local/lib/libboost_python.dylib	/Users/dalke/local/lib/libboost_python3.dylib	/Users/dalke/local/lib/libboost_python39.dylib

However, including that doesn't help:

% env DYLD_LIBRARY_PATH=/Users/dalke/venvs/py39-2020-3/lib:/Users/dalke/local/lib python -c 'import rdkit'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/dalke/venvs/py39-2020-3/lib/python3.9/site-packages/rdkit/__init__.py", line 2, in <module>
    from .rdBase import rdkitVersion as __version__
ImportError: dlopen(/Users/dalke/venvs/py39-2020-3/lib/python3.9/site-packages/rdkit/rdBase.so, 2): Symbol not found: __ZN5boost6python23throw_error_already_setEv
  Referenced from: /Users/dalke/venvs/py39-2020-3/lib/libRDKitRDBoost.1.dylib
  Expected in: flat namespace
 in /Users/dalke/venvs/py39-2020-3/lib/libRDKitRDBoost.1.dylib

Checking libRDKitRDBoost.1.dylib directly, I see it doesn't have a shared library dependency on libboost_python:

% otool -L '/Users/dalke/venvs/py39-2020-3/lib/libRDKitRDBoost.1.dylib'
/Users/dalke/venvs/py39-2020-3/lib/libRDKitRDBoost.1.dylib:
	@rpath/libRDKitRDBoost.1.dylib (compatibility version 1.0.0, current version 2020.3.1)
	@rpath/libRDKitRDGeneral.1.dylib (compatibility version 1.0.0, current version 2020.3.1)
	@rpath/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libboost_iostreams.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libboost_serialization.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)

My guess is the brute-force addition of find_package(Boost 1.56.0 COMPONENTS system iostreams REQUIRED) broke something.

I don't know cmake, and don't know what to try next. I think I'll add "python" to that and rebuild, while others add ideas.

adalke · 2020-03-31T10:01:18Z

I changed CMakeLists.txt to include "system iostreams" as part of the Python find_package(Boost) rather than on their own. That seems to have done the trick.

Here's the unified diff:

--- CMakeLists.txt	2020-03-31 11:13:18.000000000 +0200
+++ CMakeLists.txt.orig	2020-03-30 15:54:28.000000000 +0200
@@ -252,7 +252,7 @@

   # Try each potential boost-python name until one works
   foreach(Boost_Python_Lib ${Boost_Python_Names})
-    find_package(Boost 1.56.0 COMPONENTS "${Boost_Python_Lib}" system iostreams QUIET)
+    find_package(Boost 1.56.0 COMPONENTS "${Boost_Python_Lib}" QUIET)
     if(Boost_FOUND)
       break()
     endif()
@@ -260,7 +260,7 @@

   # Finally just try "python" and hope it is a compatible version
   if(NOT Boost_FOUND)
-    find_package(Boost 1.56.0 COMPONENTS python system iostreams REQUIRED)
+    find_package(Boost 1.56.0 COMPONENTS python REQUIRED)
   endif()

Rebuild (wait, wait, wait), install, and it works!

Here's the latest RDKit release working under a venv for Python 3.9a1:

(py39-2020-3) [xebulon:~] dalke% env DYLD_LIBRARY_PATH=/Users/dalke/venvs/py39-2020-3/lib:/Users/dalke/local/lib python
Python 3.9.0a1 (default, Mar 30 2020, 13:21:05)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import rdkit
>>> rdkit.__version__
'2020.03.1'
>>> from rdkit import Chem
>>> Chem.MolToSmiles(Chem.MolFromSmiles("c1ccccc1O"))
'Oc1ccccc1'

shirishag75 · 2020-03-31T12:55:43Z

I changed CMakeLists.txt to include "system iostreams" as part of the Python find_package(Boost) rather than on their own. That seems to have done the trick.

Here's the unified diff:

--- CMakeLists.txt	2020-03-31 11:13:18.000000000 +0200
+++ CMakeLists.txt.orig	2020-03-30 15:54:28.000000000 +0200
@@ -252,7 +252,7 @@

   # Try each potential boost-python name until one works
   foreach(Boost_Python_Lib ${Boost_Python_Names})
-    find_package(Boost 1.56.0 COMPONENTS "${Boost_Python_Lib}" system iostreams QUIET)
+    find_package(Boost 1.56.0 COMPONENTS "${Boost_Python_Lib}" QUIET)
     if(Boost_FOUND)
       break()
     endif()
@@ -260,7 +260,7 @@

   # Finally just try "python" and hope it is a compatible version
   if(NOT Boost_FOUND)
-    find_package(Boost 1.56.0 COMPONENTS python system iostreams REQUIRED)
+    find_package(Boost 1.56.0 COMPONENTS python REQUIRED)
   endif()

Rebuild (wait, wait, wait), install, and it works!

Here's the latest RDKit release working under a venv for Python 3.9a1:

(py39-2020-3) [xebulon:~] dalke% env DYLD_LIBRARY_PATH=/Users/dalke/venvs/py39-2020-3/lib:/Users/dalke/local/lib python
Python 3.9.0a1 (default, Mar 30 2020, 13:21:05)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import rdkit
>>> rdkit.__version__
'2020.03.1'
>>> from rdkit import Chem
>>> Chem.MolToSmiles(Chem.MolFromSmiles("c1ccccc1O"))
'Oc1ccccc1'

My question to you is why are you using python3.9 when both in bullseye and in buster-backports you have python 3.8.2 . (edit - in buster we have 3.7.3.1) according to the tracker.

https://tracker.debian.org/pkg/python3-defaults

Is there something interesting/ground-breaking in python3.9 that we should know about ?

FWIW, there is move to remove python2 entirely from the archive, although buster python2 builds should still work till their EOL .

https://release.debian.org/transitions/html/python2-rm.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931659

The DD's are trying get this done without disrupting much but for that to happen, everybody has to play their part, especially upstreams.

adalke · 2020-03-31T19:26:34Z

My question to you is why are you using python3.9 when both in bullseye and in buster-backports you have python 3.8.2

Because I want to see if my code uses anything which will be deprecated/removed in the future. (I use PyObject_AsCharBuffer which is deprecated, but not yet removed in 3.9.)

Because someone needs to do an early check for any problems with upcoming Python releases.

Because I'm not a Debian user - I'm commenting on this thread because I have identical RDKit errors, not because I'm specifically trying to reproduce under Debian.

Have you tried my patch to see if it fixes your problem?

The DD's are trying get this done without disrupting much but for that to happen, everybody has to play their part, especially upstreams.

I don't understand what this means. Who are the DD's? What part am I supposed to play? Why? How am I supposed to know this? Who are you to make any statements about my role in this?

shirishag75 · 2020-03-31T20:27:55Z

My question to you is why are you using python3.9 when both in bullseye and in buster-backports you have python 3.8.2

Because I want to see if my code uses anything which will be deprecated/removed in the future. (I use PyObject_AsCharBuffer which is deprecated, but not yet removed in 3.9.)

Because someone needs to do an early check for any problems with upcoming Python releases.

Ah check.

Because I'm not a Debian user - I'm commenting on this thread because I have identical RDKit errors, not because I'm specifically trying to reproduce under Debian.

Have you tried my patch to see if it fixes your problem?

Not yet, but will pass on the message that there is a fix to the relevant people.

The DD's are trying get this done without disrupting much but for that to happen, everybody has to play their part, especially upstreams.

I don't understand what this means. Who are the DD's? What part am I supposed to play? Why? How am I supposed to know this? Who are you to make any statements about my role in this?

DD's are Debian Developers, by upstream I meant the rdkit developers, as shared by @greglandrum any potential fix needs to be upstreamed. The statement I shared was not directed at you but upstream i.e. upstream developers.

https://wiki.debian.org/UpstreamGuide . What Debian likes to do is have a close relationship with upstream so that the delta between what upstream develops and what is within Debian is minimal to the fault, so people try as much to take from upstream the fixes rather than fixing something which may again need a patch because upstream went another way. I hope you understood what I meant.

greglandrum · 2020-04-01T09:29:15Z

Ok, it seems like the temperature here is getting a bit high, which isn't particularly helpful and is certainly incompatible with the atmosphere of collegiality and helpfulness that is a general part of the RDKit community and that I think almost all of us really appreciate.

I'm all for having the main RDKit repo as easily buildable as possible for downstream systems. That could help increase adoption, which is certainly not a bad thing. However, before we think about making any changes in the build system on the RDKit side, it would be nice to know whether or not the changes @adalke suggests, which seem to work for him on the Mac, also help on the debian side @shirishag75.

greglandrum · 2020-04-01T11:31:19Z

FWIW, there is move to remove python2 entirely from the archive, although buster python2 builds should still work till their EOL .

https://release.debian.org/transitions/html/python2-rm.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931659

The DD's are trying get this done without disrupting much but for that to happen, everybody has to play their part, especially upstreams.

A quick comment here: I think it's awesome that the debian folks are removing the unsupported python2 from their distribution, but I'm not sure what that has to do with the RDKit. The last RDKit release that supported Python2 was more than a year ago (the 2018.09 release series), so I don't think there's anything more for us to do on that front. Did I miss something?

shirishag75 · 2020-04-01T22:57:39Z

snipped -

A quick comment here: I think it's awesome that the debian folks are removing the unsupported python2 from their distribution, but I'm not sure what that has to do with the RDKit. The last RDKit release that supported Python2 was more than a year ago (the 2018.09 release series), so I don't think there's anything more for us to do on that front. Did I miss something?

This bit of info. was not known to me, otherwise perhaps I would not have commented on that part. Makes everybody life easier. My intention is and was never to hurt anybody intentionally or otherwise, and sorry if I caused any hurt during understanding things as they are.

UnixJunkie · 2020-06-02T07:51:15Z

Same problem with boost 1.72 on Mac with brew.
I'll try the suggested fix.

UnixJunkie · 2020-06-02T08:09:16Z

For the brew recipe, we already have '-DBoost_NO_BOOST_CMAKE=ON'; that doesn't fix the issue.

UnixJunkie · 2020-06-02T08:30:59Z

cmake -DPYTHON_EXECUTABLE=/usr/local/bin/python3 -DRDK_INSTALL_INTREE=OFF     -DRDK_BUILD_INCHI_SUPPORT=ON -DRDK_BUILD_AVALON_SUPPORT=ON -DRDK_BUILD_PYTHON_WRAPPERS=ON -DCMAKE_INSTALL_PREFIX=/usr -DBoost_NO_BOOST_CMAKE=ON -DBoost_DEBUG=ON ../
[...]
  Could NOT find Boost (missing: python) (found suitable version "1.72.0",
  minimum required is "1.58.0")
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.17.3/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:445 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/Cellar/cmake/3.17.3/share/cmake/Modules/FindBoost.cmake:2166 (find_package_handle_standard_args)
  CMakeLists.txt:289 (find_package)

UnixJunkie · 2020-06-02T08:53:01Z

@adalke did you try your fix on a mac?

adalke · 2020-06-02T09:21:49Z

Yes, on a Mac.

ryszard314159 · 2020-09-03T16:51:44Z

'-DBoost_NO_BOOST_CMAKE=ON' apparently fixes the build issue for:
(0) rdkit downloaded on 2020-09-02 (git clone https://github.com/rdkit/rdkit.git)
(1) Ubuntu 20.04.1 LTS (Linux 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
(2) Boost-1.74.0

however,

there are many "deprecated" messages:
/usr/include/boost/detail/iterator.hpp:13:1: note: #pragma message: This header is deprecated. Use instead.

and many test failures from ctest:

66% tests passed, 61 tests failed out of 182
The following tests FAILED:
2 - pyCoordGen (Failed)
8 - pyBV (Failed)
[...]
181 - pythonTestDirChem (Failed)
182 - pythonTestSping (Failed)
Errors while running CTest

bp-kelley · 2020-09-03T22:17:02Z

@ryszard314159 I can get an ubuntu 20 image and do a build, could you send me the explicit commands you used to build rdkit?

ryszard314159 · 2020-09-03T23:37:55Z

I basically followed instructions from https://www.rdkit.org/docs/Install.html [How to build from source with Conda | Linux x86_64: Python 3 environment]. I had to add '-DBoost_NO_BOOST_CMAKE=ON' to make cmake work.
Here are the explicit commands I used:

bash Anaconda3-2020.07-Linux-x86_64.sh
conda install -y cmake cairo pillow eigen pkg-config
conda install -y boost-cpp boost py-boost # this gave me some problems (failed with initial frozen solve. Retrying with flexible solve. etc. so I just installed boost (1_74_0) from source
conda install -y gxx_linux-64
git clone https://github.com/rdkit/rdkit.git
cd rdkit
mkdir build && cd build
cmake -DPy_ENABLE_SHARED=1
-DRDK_INSTALL_INTREE=ON
-DRDK_INSTALL_STATIC_LIBS=OFF
-DRDK_BUILD_CPP_TESTS=ON
-DPYTHON_NUMPY_INCLUDE_PATH="$(python -c 'import numpy ; print(numpy.get_include())')"
-DBOOST_ROOT="$CONDA_PREFIX"
-DBoost_NO_BOOST_CMAKE=ON
..
make
make install
ctest

--
I tried also [How to install RDKit with Conda], but it gave me problems as well (: probably related to #3062)

After
(1) $ conda create -c rdkit -n my-rdkit-env rdkit
(2) $ conda activate my-rdkit-env

I am getting this error:

Python 3.6.10 |Anaconda, Inc.| (default, May 8 2020, 02:54:21)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import rdkit
Traceback (most recent call last):
File "", line 1, in
File "/home/ryszard/anaconda3/envs/my-rdkit-env/lib/python3.6/site-packages/rdkit/init.py", line 2, in
from .rdBase import rdkitVersion as version
ImportError: libboost_python3.so.1.65.1: cannot open shared object file: No such file or directory

find /home/ryszard/anaconda3/envs/my-rdkit-env -name libboost_python* gives me:
[...]
home/ryszard/anaconda3/envs/my-rdkit-env/lib/libboost_python36.so.1.71.0
[...]
but not libboost_python3.so.1.65.1

UnixJunkie · 2020-09-04T00:51:08Z

If there were up to date binary rdkit packages for Ubuntu and Debian, less people would open such issues...
I don't even know a PPA where there are some.

UnixJunkie mentioned this issue Jun 2, 2020

Could NOT find Boost (missing: python) (found suitable version "1.72.0", minimum required is "1.56.0") rdkit/homebrew-rdkit#89

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to build with boost 1.71 on Debian #3030

Unable to build with boost 1.71 on Debian #3030

shirishag75 commented Mar 23, 2020

e-kwsm commented Mar 24, 2020

adalke commented Mar 30, 2020

greglandrum commented Mar 31, 2020

shirishag75 commented Mar 31, 2020 •

edited

Loading

greglandrum commented Mar 31, 2020

adalke commented Mar 31, 2020

e-kwsm commented Mar 31, 2020

ptosco commented Mar 31, 2020

adalke commented Mar 31, 2020

adalke commented Mar 31, 2020

shirishag75 commented Mar 31, 2020 •

edited

Loading

adalke commented Mar 31, 2020

shirishag75 commented Mar 31, 2020

greglandrum commented Apr 1, 2020

greglandrum commented Apr 1, 2020

shirishag75 commented Apr 1, 2020

UnixJunkie commented Jun 2, 2020

UnixJunkie commented Jun 2, 2020

UnixJunkie commented Jun 2, 2020

UnixJunkie commented Jun 2, 2020

adalke commented Jun 2, 2020

ryszard314159 commented Sep 3, 2020 •

edited

Loading

bp-kelley commented Sep 3, 2020

ryszard314159 commented Sep 3, 2020 •

edited

Loading

UnixJunkie commented Sep 4, 2020

Unable to build with boost 1.71 on Debian #3030

Unable to build with boost 1.71 on Debian #3030

Comments

shirishag75 commented Mar 23, 2020

e-kwsm commented Mar 24, 2020

adalke commented Mar 30, 2020

greglandrum commented Mar 31, 2020

shirishag75 commented Mar 31, 2020 • edited Loading

greglandrum commented Mar 31, 2020

adalke commented Mar 31, 2020

e-kwsm commented Mar 31, 2020

ptosco commented Mar 31, 2020

adalke commented Mar 31, 2020

adalke commented Mar 31, 2020

shirishag75 commented Mar 31, 2020 • edited Loading

adalke commented Mar 31, 2020

shirishag75 commented Mar 31, 2020

greglandrum commented Apr 1, 2020

greglandrum commented Apr 1, 2020

shirishag75 commented Apr 1, 2020

UnixJunkie commented Jun 2, 2020

UnixJunkie commented Jun 2, 2020

UnixJunkie commented Jun 2, 2020

UnixJunkie commented Jun 2, 2020

adalke commented Jun 2, 2020

ryszard314159 commented Sep 3, 2020 • edited Loading

bp-kelley commented Sep 3, 2020

ryszard314159 commented Sep 3, 2020 • edited Loading

UnixJunkie commented Sep 4, 2020

shirishag75 commented Mar 31, 2020 •

edited

Loading

shirishag75 commented Mar 31, 2020 •

edited

Loading

ryszard314159 commented Sep 3, 2020 •

edited

Loading

ryszard314159 commented Sep 3, 2020 •

edited

Loading