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

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 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 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.

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

On a mac, install kim-api with

cd build
make install

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

Best regards


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.