Problem compiling LAMMPS with Intel compilers on macOS Catalina

I’ve been trying to install LAMMPS (30Jun2020) on macOS Catalina (10.15.5) with the Intel compilers (19.1.1.216) and with OpenMPI (4.0.4) and Intel Python (3.7m). I am getting a warning that has proven very difficult to diagnose.

a) this has nothing to do with the GPU package but stems (as the output indicates) from the fmtlib header.
b) it is due to the intel compiler trying to make itself look like the native compiler (which is clang based), similar things have happened on Linux (which the “native” compiler is GNU)
c) the issue should be easily fixed with the following change (that is how we fixed the Linux issue mentioned above).

axel.

index 5d07611772…645e0630cd 100644
— a/src/fmt/format.h
+++ b/src/fmt/format.h
@@ -74,7 +74,7 @@
#endif

#if __cplusplus == 201103L || __cplusplus == 201402L
-# if defined(clang)
+# if defined(clang) && !defined(__INTEL_COMPILER)

define FMT_FALLTHROUGH [[clang::fallthrough]]

elif FMT_GCC_VERSION >= 700 && !defined(__PGI) && !defined(__INTEL_COMPILER)

define FMT_FALLTHROUGH [[gnu::fallthrough]]

Many thanks for your quick and precise advice. This indeed fixed the warnings.

I now have only one error remaining during the very last linking step for the lmp binary. It seems that the “SharedAllocationRecord” symbol for Kokkos is undefined, despite being found in both libkokkoscore.a and libkokkoscontainers.a. Is this a known issue?

/usr/local/bin/mpicxx -restrict -O2 -g -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/lib CMakeFiles/lmp.dir/Users/home/local/src/lammps-patch_30Jun2020/src/main.cpp.o -o lmp_local -Wl,-rpath,/opt/intel/mkl/lib -Wl,-rpath,/opt/intel/tbb/lib -Wl,-rpath,/opt/intel/python/lib liblammps_local.a /opt/openmpi/lib/libmpi.dylib /opt/intel/compilers_and_libraries_2020.1.216/mac/compiler/lib/libiomp5.dylib /usr/lib/libpthread.dylib /Users/home/local/lib/libjpeg.dylib /Users/home/local/lib/libpng.dylib /opt/intel/python/lib/libz.dylib /opt/intel/mkl/lib/libmkl_rt.dylib /opt/intel/python/lib/libpython3.7m.dylib -lm lib/kokkos/containers/src/libkokkoscontainers.a lib/kokkos/core/src/libkokkoscore.a /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libdl.tbd /opt/intel/tbb/lib/libtbbmalloc.dylib
Undefined symbols for architecture x86_64:
“__tls____ZN6Kokkos4Impl22SharedAllocationRecordIvvE18t_tracking_enabledE”, referenced from:
__ZN9LAMMPS_NS10AtomKokkos20allocate_type_arraysEv in liblammps_local.a(atom_kokkos.cpp.o)
__ZN9LAMMPS_NS10AtomKokkos4sortEv in liblammps_local.a(atom_kokkos.cpp.o)
__ZN9LAMMPS_NS10AtomKokkos4growEj in liblammps_local.a(atom_kokkos.cpp.o)
__ZN9LAMMPS_NS10AtomKokkos10add_customEPKci in liblammps_local.a(atom_kokkos.cpp.o)
__ZN9LAMMPS_NS10AtomKokkos19deallocate_topologyEv in liblammps_local.a(atom_kokkos.cpp.o)
_ZN6Kokkos8DualViewIPiNS_11LayoutRightENS_6OpenMPEvEC1ERKS4 in liblammps_local.a(atom_kokkos.cpp.o)
_ZN6Kokkos8DualViewIA3_PdNS_11LayoutRightENS_6OpenMPEvEC1ERKS5 in liblammps_local.a(atom_kokkos.cpp.o)

grep -rnw . -e “SharedAllocationRecord”
Binary file lib/kokkos/containers/src/libkokkoscontainers.a matches
Binary file lib/kokkos/core/src/libkokkoscore.a matches

as far as LAMMPS is concerned, you have a very unusual combination of platform and compiler, so there may be undetected platform specific issues simply because of the lack of exposure. on macos this is more common due to the tendency of the apple engineers’ tendency to make their platform behave differently from others. it used to be straightforward to compile software like LAMMPS that works well in a unix-oid environment in the early days, but with every new major update it is becoming more painful and complex and more exceptions and workarounds need to be added.

you are also making things more complex by using rather elaborate settings and a non-standard toolchain. I would suggest to see whether this linking issue happens also if you compile the entire software stack with the “native” apple compilers. if that works, you need to try to get a detailed compilation log to determine whether the compilation of the Kokkos library is done consistently with the rest of LAMMPS. one option to consider is to download/compile/link an external Kokkos library instead of the bundled one. if this all doesn’t help, please try to find the simplest way with the fewest options to reproduce the linker failure and report those back here.

axel.