kim-api-v2, macOS, python extensions, and compiler versions.

OpenKIM
1

Dear all,

This is mostly an informational posting, in case anybody else wants to use the new version 2 on a Mac - maybe this info should go into the installation instructions.

At the workshop last week, I build the kim-api (the cmake build system) with GCC version 8 from Homebrew, since that is the version of GCC that comes with gfortran. The “native” gcc / g++ are clang version 9.1, but there is no fortran with that one.

GNU g++ and the clang++ cannot very well be mixed, it is apparently something about an incompatible library or something. So I had to compile “asap” (my Python-based MD program) with GCC 8 as well. That was not a problem as long as I was using Asap’s makefile-based build system. But Asap has two build systems, a makefile based (great for development since it only recompiles what is strictly necessary) and a setup.py based one (which is the one a user will use to install it without special knowledge - pip install asap3 will also use that build system).

Once I was back from the workshop, I tried to update the setup.py based build system, but ran into trouble. It uses the same compiler that was used to build Python (I use Homebrew’s Python) - i.e. clang. And then it could not link the kim-api libraries because of incompatible C++ compilers.

Solution:
I installed the kim-api with clang as C/C++ compilers, but gfortran from GCC 8.1. Yes, that combination does not appear to cause trouble! Then Asap is built with clang but can link to kim models built with gfortran-8

TL;DR:
On a mac, install kim-api with

cd build
CC=clang CXX=clang++ FC=gfortran-8 cmake ../ -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=$HOME/local -DKIM_API_BUILD_MODELS_AND_DRIVERS=ON
make
make install

Then you can also build Python modules depending on the KIM API.

Best regards

Jakob

2

Hi Jakob,

Thanks for this note! Yes, that should (I think) work quite nicely.

It is true that C is the most portable in this sense. All portions of Fortran and C++ codes must be compiled with the same compiler to be assured of working correctly due to various details that those standards allow to the compiler specific (Fortran: mod files, etc.; C++ name-mangling, etc.). These issues are just something that must be delt with when working with a multi-language system...

It is interesting to note that an alternative solution for a c++ simulator would be to use the kim-api c-bindings instead of the c++ bindings for implementing the ASAP support. This would avoid the C++ compiler dependency, but you would have to give up all the nice namespace/object-oriented features that come with the C++ bindings.

Cheers,

Ryan