How to ensure that a LAMMPS plugin is compatible with the LAMMPS conda binary?

LAMMPS LAMMPS Installation
1

Consider building (and later running) the LAMMPS example plugins in an environment where the LAMMPS conda binary is installed:

conda create -n lammps cmake lammps -c conda-forge
conda activate lammps
git clone -b release https://github.com/lammps/lammps.git
cmake -S examples/plugins -B build-plugins

Output (on Fedora Linux 39):

-- The CXX compiler identification is GNU 13.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found MPI_CXX: /home/niklas/.more/apps/miniconda3/envs/lammps/lib/libmpi.so (found version "3.1") 
-- Found MPI: TRUE (found version "3.1")  
-- Looking for C++ include omp.h
-- Looking for C++ include omp.h - found
-- Found OpenMP_CXX: -fopenmp (found version "4.5") 
-- Found OpenMP: TRUE (found version "4.5")  
-- Configuring done (1.5s)
CMake Warning at CMakeLists.txt:63 (add_library):
  Cannot generate a safe runtime search path for target morse2plugin because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libgomp.so.1] in /usr/lib/gcc/x86_64-redhat-linux/13 may be hidden by files in:
      /home/niklas/.more/apps/miniconda3/envs/lammps/lib

  Some of these libraries may not be found correctly.


CMake Warning at CMakeLists.txt:67 (add_library):
  Cannot generate a safe runtime search path for target nve2plugin because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libgomp.so.1] in /usr/lib/gcc/x86_64-redhat-linux/13 may be hidden by files in:
      /home/niklas/.more/apps/miniconda3/envs/lammps/lib

  Some of these libraries may not be found correctly.


CMake Warning at CMakeLists.txt:70 (add_library):
  Cannot generate a safe runtime search path for target helloplugin because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libgomp.so.1] in /usr/lib/gcc/x86_64-redhat-linux/13 may be hidden by files in:
      /home/niklas/.more/apps/miniconda3/envs/lammps/lib

  Some of these libraries may not be found correctly.


CMake Warning at CMakeLists.txt:73 (add_library):
  Cannot generate a safe runtime search path for target zero2plugin because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libgomp.so.1] in /usr/lib/gcc/x86_64-redhat-linux/13 may be hidden by files in:
      /home/niklas/.more/apps/miniconda3/envs/lammps/lib

  Some of these libraries may not be found correctly.


-- Generating done (0.0s)
-- Build files have been written to: /home/niklas/src/tmp/lammps/build-plugins

CMake links the plugin libraries against system libraries in /usr/lib/. Libraries of the same name are present in .../miniconda3/envs/lammps/lib. I think the loader considers the latter location because that’s where it finds the MPI package here (the warnings go away with -DBUILD_MPI=OFF). Ultimately CMake warns that in the conda environment, at runtime, the libraries in .../miniconda3/envs/lammps/lib may be loaded unintentionally.

I am not sure how severe these warnings are and how to deal with them. One option would be to build the plugins with the conda environment deactivated. Then, one would have to manually install and link against the same libraries (i.e. MPI) that the LAMMPS conda binary uses. To me, it seems more reasonable to tell CMake to prefer libraries in the conda environment over system libraries, but I have not found how to do so easily.

In brief:

  1. Should I care about these warnings if I want a plugin to be compatible with the LAMMPS conda install?
  2. Is it preferable to link against system or conda libraries?
2

In my personal experience, using conda has been causing more problems that it solves. Specifically having multiple basic runtimes without some kind of containment (e.g. as it is done by flatpak or snap) or real containers via apptainer/singularity or docker is asking for trouble.

To build guaranteed to be compatible plugins you must have exactly the source that is used by the LAMMPS executable and link to the same or compatible compiler runtime and c-library.

Binary packaging for LAMMPS is for the most part not done by the LAMMPS developers (exceptions are Windows installers, and some standalone serial executables posted on the LAMMPS GitHub release pages). Thus any questions about compatibility and setup etc. should be directed to the people that do the packaging via their own feedback or user support mechanisms.

1 Like