# Bug: Library compatibility version differs between CMake and autotools build on macOS

**URL:** <https://forum.hdfgroup.org/t/bug-library-compatibility-version-differs-between-cmake-and-autotools-build-on-macos/5308>\
**Category:** HDF5 Library\
**Created:** [January 20, 2019, 9:51am UTC](https://forum.hdfgroup.org/t/bug-library-compatibility-version-differs-between-cmake-and-autotools-build-on-macos/5308 "2019-01-20T09:51:08Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![elvis.stansvik](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/e/46a35a/32.png) [@elvis.stansvik](https://forum.hdfgroup.org/u/elvis.stansvik)\
**Post date:** [January 20, 2019, 10:07am UTC](https://forum.hdfgroup.org/t/bug-library-compatibility-version-differs-between-cmake-and-autotools-build-on-macos/5308/2 "2019-01-20T10:07:52Z")

</div>

I had a look at the autotools stuff, and I believe this snippet from `bin/ltmain.sh` explains it:

```
darwin)
  # Like Linux, but with the current version available in
  # verstring for coding it into the library header
  func_arith $current - $age
  major=.$func_arith_result
  versuffix=$major.$age.$revision
  # Darwin ld doesn't like 0 for these options...
  func_arith $current + 1
  minor_current=$func_arith_result
  xlcverstring="$wl-compatibility_version $wl$minor_current $wl-current_version $wl$minor_current.$revision"
  verstring="-compatibility_version $minor_current -current_version $minor_current.$revision"
  # On Darwin other compilers
  case $CC in
      nagfor*)
          verstring="$wl-compatibility_version $wl$minor_current $wl-current_version $wl$minor_current.$revision"
          ;;
      *)
          verstring="-compatibility_version $minor_current -current_version $minor_current.$revision"
          ;;
  esac
  ;;

```

Libtool doing + 1 here probably explains why you’ve chosen to set `LT_VERS_INTERFACE` to 103 on HDF5 1.10.4?

Then maybe the CMake logic should be updated to match the libtool logic, so add 1?

As a side note, I found this snipped just below in `config/cmake/HDF5Macros.cmake`:

```
  #-- Apple Specific install_name for libraries
  if (APPLE)
    option (HDF5_BUILD_WITH_INSTALL_NAME "Build with library install_name set to the installation path" OFF)
    if (HDF5_BUILD_WITH_INSTALL_NAME)
      set_property(TARGET ${libtarget} APPEND PROPERTY
          LINK_FLAGS "-current_version ${HDF5_PACKAGE_VERSION} -compatibility_version ${HDF5_PACKAGE_VERSION}"
      )
      set_target_properties (${libtarget} PROPERTIES
          INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib"
          BUILD_WITH_INSTALL_RPATH ${HDF5_BUILD_WITH_INSTALL_NAME}
      )
    endif ()
    ...

```

so it seems that currently, one way of working around this discrepancy issue is to make do the CMake build with the `HDF5_BUILD_WITH_INSTALL_NAME` option set, because then the CMake scripts will manually pass `-compatibility_version ${HDF5_PACKAGE_VERSION}`. Haven’t tested this though, just an observation.

---

_[View the full topic](https://forum.hdfgroup.org/t/bug-library-compatibility-version-differs-between-cmake-and-autotools-build-on-macos/5308)._