Bug #2722

gmxapi may over-manage RPATH

Added by Mark Abraham about 1 year ago. Updated 4 days ago.

build system
Target version:
Affected version - extra info:
Affected version:


The RPATH settings we have for libgmxapi look either like defaults or things that are artefacts of developing outside the main GROMACS project. We should simplify these, or document what they are intended to achieve.


Related issues

Blocked by GROMACS - Task #2756: gmxapi integration testingIn Progress

Associated revisions

Revision 3fd14b5f (diff)
Added by Paul Bauer 12 months ago

Disable gmxapi by default

Due to outstanding issues with the integration testing and tests failing
with large number of ranks, the gmxapi default has been changed to not
be build. In Jenkins, all supported builds still are still set to build
with GMXAPI enabled.

Refs #2765, #2722, #2756

Change-Id: I2cc42c461edc206aaa30be6cac3db0a52ccae991


#1 Updated by Mark Abraham about 1 year ago

In particular, when building with clang+cuda+ninja, I get

CMake Error at src/api/cpp/CMakeLists.txt:53 (add_library):
  The install of the gmxapi target requires changing an RPATH from the build
  tree, but this is not supported with the Ninja generator unless on an
  ELF-based platform.  The CMAKE_BUILD_WITH_INSTALL_RPATH variable may be set
  to avoid this relinking step.

which I can get rid of if I comment out


so unless the later has a clear use, then we should probably drop it.

#2 Updated by Gerrit Code Review Bot about 1 year ago

Gerrit received a related patchset '1' for Issue #2722.
Uploader: Mark Abraham ()
Change-Id: gromacs~release-2019~Ic697f596285acdb5c7728b7ebc995ea44c82f3ac
Gerrit URL:

#3 Updated by Eric Irrgang about 1 year ago

I had never encountered a problem with changing RPATH between build and install directory before. Good to know.

As long as the RPATH is relative and the relationship between libgmxapi and libgromacs is consistent, removing that line should be fine.

#4 Updated by Eric Irrgang about 1 year ago

  • Blocked by Task #2756: gmxapi integration testing added

#5 Updated by Gerrit Code Review Bot 12 months ago

Gerrit received a related DRAFT patchset '1' for Issue #2722.
Uploader: Paul Bauer ()
Change-Id: gromacs~release-2019~I2cc42c461edc206aaa30be6cac3db0a52ccae991
Gerrit URL:

#6 Updated by Paul Bauer 12 months ago

More likely to happen in 2020

#7 Updated by Paul Bauer 12 months ago

  • Target version changed from 2019 to 2020

#8 Updated by Eric Irrgang about 2 months ago

  • Target version changed from 2020 to 2020-beta3

We should be able to resolve this with less effort when we move to the new testing infrastructure, but the appropriate test coverage is pretty broad.

Note that some of these CMake config options predate the current CMake policy behaviors and GROMACS choices, but originally they could affect both how libgmxapi finds libgromacs and how libgmxapi clients find libgmxapi (or how the libgmxapi ability to find libgromacs could be affected by how libgmxapi is loaded by a client.)

I believe that the behavior we want is that (a) libgmxapi is built so that libgromacs is at a fixed location relative to itself at build through to install, that (b) the installed libgmxapi (and imported CMake target) provide the necessary information for client code to resolve the libgmxapi location via the client RPATH (or equivalent facility). I don't think we need to support relocatability of the libgmxapi installation, but if we do, it doesn't seem like much to ask clients linked against the first location to have to relink against the new location. We do need to allow client code to be relocatable without relinking because of how various packaging systems work, which has slight constraints on how the library identifies itself and what RPATH hinting is provided through CMake.

Note that, currently, we do not produce an installable binary package of client software (such as the Python gmxapi package or the sample_restraint MD extension) in the GROMACS build tree. If we did, we would need to consider that the package would have to be built in an environment where its ultimate link targets are not yet available.

Matrix dimensions


  • make
  • ninja


  • Linux (multiple binary formats?)
  • Mac OS X
  • Windows? (please no)

libgmxapi state

Assume libgromacs state == libgmxapi state

  • in build tree (BUILD_INTERFACE and library target)
  • installed (INSTALLED_INTERFACE and imported target)

Client state

  • _gmxapi target in build tree (e.g. with gmxapi_pytest target)
  • Python gmxapi package building and linking against GROMACS installation in packaging sandbox.
  • Python gmxapi package relocated during package installation.
  • sample_restraint target tested in GROMACS build tree.
  • sample_restraint package installed in user environment.

#9 Updated by Paul Bauer 6 days ago

  • Target version changed from 2020-beta3 to 2020-rc1


#10 Updated by Mark Abraham 4 days ago

We haven't ever designed for supporting multiple binary/linking formats (e.g. ELF, DWARF) and definitely not mixing them, so the only thing we should consider now is testing with the toolchain provided by the user and that means we have to assume it's capable of correct behavior and issuing a message when it can't.

Since Windows has never been tested with GMXAPI, we should give an error from src/CMakeLists.txt if someone tries it (not just default off).

Otherwise, Erik's matrix looks fine. We need scripts that can cover those cases, whether we run them manually or automated. Once we have them, then it's easier to see whether things in src/api/cpp/CMakeLists.txt are necessary or not.

Also available in: Atom PDF