Minimal build compilation errors

Development
1

Hi,

I’m trying to work out the absolute minimum steps and dependencies required to build Avogadro successfully, so that @brockdyer03 and I can (informed by our recent experiences trying to compile the project) improve the documentation on building to help newcomers.

So to start with:

  • I’m attempting to build with the submodules avogadroapp, avogadrolibs, crystals, fragments, and molecules only
  • ./thirdparty/ is empty for now other than the CMakeLists.txt file and the empty directories of pybind11/qttesting/VTK/yaehmop
  • molequeue, avogadrodata, and avogadrogenerators are absent
  • avogadro-i18n wasn’t present but after attempting to build it seems to have been automatically downloaded
  • Working out the necessary dependencies is a challenge but so far I’ve identified QtCore, QtWidgets, QtGui, QtOpenGL, QtConcurrent, and QtNetwork as being necessary (obviously the way these are packaged varies by system – I will add notes for openSUSE to the docs)
  • It also seems I need to have glew installed on the system so I have done so
  • openbabel is not installed on my system

That’s just so you have an idea what the base I’m building on is.

I’m then building using:

cmake -D QT_VERSION=5 -D BUILD_MOLEQUEUE=OFF -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ -S . -B ./b  
uild
cmake --build ./build

Which gets fairly far, then stops just at the end of compiling avogadrolibs with:

[ 91%] Building CXX object src/formats/CMakeFiles/chemdoodlejsonformat.dir/json/chemdoodlejsonformat.cpp.o  
In file included from /home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/include/openbabel  
/json.h:22,  
                from /home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/src/formats/json/  
chemdoodlejsonformat.cpp:19:  
/home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/external/rapidjson-1.1.0/include/rapidj  
son/document.h: In member function ‘rapidjson::GenericStringRef<CharType>& rapidjson::GenericStringRef<CharType>::op  
erator=(const rapidjson::GenericStringRef<CharType>&)’:  
/home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/external/rapidjson-1.1.0/include/rapidj  
son/document.h:319:82: error: assignment of read-only member ‘rapidjson::GenericStringRef<CharType>::length’  
 319 |     GenericStringRef& operator=(const GenericStringRef& rhs) { s = rhs.s; length = rhs.length; }  
     |                                                                           ~~~~~~~^~~~~~~~~~~~  
In file included from /home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/include/openbabel  
/atom.h:35,  
                from /home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/src/formats/json/  
chemdoodlejsonformat.cpp:22:  
/home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/include/openbabel/math/vector3.h: In me  
mber function ‘bool OpenBabel::vector3::operator!=(const OpenBabel::vector3&) const’:  
/home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/include/openbabel/math/vector3.h:281:29  
: warning: ‘bool OpenBabel::vector3::operator==(const OpenBabel::vector3&) const’ is deprecated: Use vector3::IsAppr  
ox() instead. [-Wdeprecated-declarations]  
 281 |       return ! ( (*this) == other );  
     |                             ^~~~~  
/home/matt/avo/openchemistry/build/thirdparty/openbabel-prefix/src/openbabel/include/openbabel/math/vector3.h:274:10  
: note: declared here  
 274 |     bool operator== ( const vector3& ) const;  
     |          ^~~~~~~~  
gmake[5]: *** [src/formats/CMakeFiles/chemdoodlejsonformat.dir/build.make:76: src/formats/CMakeFiles/chemdoodlejsonf  
ormat.dir/json/chemdoodlejsonformat.cpp.o] Error 1  
gmake[4]: *** [CMakeFiles/Makefile2:3904: src/formats/CMakeFiles/chemdoodlejsonformat.dir/all] Error 2  
gmake[3]: *** [Makefile:136: all] Error 2  
gmake[2]: *** [thirdparty/CMakeFiles/openbabel.dir/build.make:86: thirdparty/openbabel-prefix/src/openbabel-stamp/op  
enbabel-build] Error 2  
gmake[1]: *** [CMakeFiles/Makefile2:355: thirdparty/CMakeFiles/openbabel.dir/all] Error 2  
gmake: *** [Makefile:91: all] Error 2

It’s not immediately obvious to me how this should be fixed. Any ideas?

2

This is an Open Babel issue – it uses rapidjson which hasn’t had a release in eons (2016!). It doesn’t compile with current GCC compilers: problem with gcc trunck (gcc 15.0.0) · Issue #2277 · Tencent/rapidjson · GitHub

There is a fix for rapidjson: Remove non-compiling assignment operator by yachoor · Pull Request #719 · Tencent/rapidjson · GitHub

Unfortunately, I need to go fix up some things in Open Babel (and presumably make a 3.2 release with the CJSON support).

3

Thanks for the links. I’m using clang though, so shouldn’t it be fine?

Can I ask for some clarification on something? So if I have USE_SYSTEM_OPENBABEL=ON then I can use an openbabel binary that is on my path. If it is left off/default then during building the openbabel source code is downloaded to the build directory and compiled. Firstly, what version of the code gets downloaded? (The link in projects.cmake is to some commit but no idea which one.) Secondly, if I clone the current code of Open Babel to ./thirdparty/openbabel, so that I can add the fix you mentioned, will it get used during compilation or will it still download the code itself because I’m still not using the system Open Babel?

How are you currently compiling successfully? Without the fix you mentioned, but with clang on Mac? And how come the Linux binaries produced by GitHub actions aren’t failing, is it because they aren’t using recent gcc?

4

I did manage to solve the immediate problem at least by installing rapidjson-devel from my package manager, which is a patched version, that then gets picked up during the openbabel build.

1 Like
5

I think so? The commit in projects.cmake was a recent HEAD for Open Babel. There may be a few more commits, but it doesn’t have anything for the RapidJSON issue. I just found that myself.

MacOS uses Apple Clang, not GCC. (It’s reporting as clang-15.0)

Correct. They’re running on Ubuntu 20.04, so not versions of GCC that throw the error. (Which is why I haven’t seen the failure until recently.)

I don’t understand why there isn’t a newer release of RapidJSON – there are literally hundreds of patches since the 1.1.0 release.

6

I’ll test it out. Since the build succeeds when a patched version is installed, I guess just listing rapidjson as a dependency in the instructions is the simplest way to get users round the problem for now.

But it does seem to be a problem for me on Linux even when using clang, not just gcc, FYI.

Yeah no idea, it’s not exactly like it’s unmaintained. Possibly similar to Open Babel; the concept of a “release” brings ideas of neatness, stability, and thorough testing that make it non-trivial to just release?

I changed the CMakeLists.txt file in Open Babel to use the current master-branch code and it builds now. I opened a PR for it if you’re interested.