CMake files on macOS link to non-existent libtbb.12.8.dylib


I want to compile an application (LibrePCB) which depends on OpenCascade. On macOS therefore I installed OpenCASCADE with Homebrew, which automatically installs the dependency tbb as well:

brew install opencascade

OpenCascade is then found by CMake when building LibrePCB. But then make fails because libtbb.12.8.dylib does not exist:

make[2]: *** No rule to make target `/usr/local/opt/tbb/lib/libtbb.12.8.dylib', needed by `apps/librepcb-cli/'.  Stop.

It seems that the installed CMake files of OpenCASCADE depend on a very specific TBB version, probably the TBB version installed while building OpenCASCADE(?). But if TBB has been updated to a later version in the mean time, the CMake files of OpenCASCADE will be broken because the referenced TBB version does not exist on the system anymore.

After a quick look, I found these lines in /usr/local/opt/opencascade/lib/cmake/opencascade/OpenCASCADEFoundationClassesTargets.cmake:

set_target_properties(TKernel PROPERTIES
  INTERFACE_LINK_LIBRARIES "/usr/local/opt/tbb/lib/libtbb.12.8.dylib;/usr/local/opt/tbb/lib/libtbbmalloc.2.8.dylib"

# Create imported target TKMath
add_library(TKMath SHARED IMPORTED)

set_target_properties(TKMath PROPERTIES
  INTERFACE_LINK_LIBRARIES "TKernel;/usr/local/opt/tbb/lib/libtbb.12.8.dylib;/usr/local/opt/tbb/lib/libtbbmalloc.2.8.dylib"

So there are indeed "hardcoded" versions for libtbb and libtbbmalloc.

My main question is now: Is this intended or a bug? If it's a bug, how to proceed? It seems I cannot open an issue in the bug tracker, so I hope somebody could pick this up. Thanks.

For context, here's the corresponding issue for the Homebrew package: Homebrew/homebrew-core/#129111

carlocab's picture

For reference, the install names of libtbb and libtbbmalloc are $prefix/libtbb.12.dylib and $prefix/libtbbmalloc.2.dylib, respectively. This means that any libtbb.12.*.dylib and libtbbmalloc.2.*.dylib should be ABI compatible with whatever was used to build OpenCascade, so there should be no need to hardcode the library minor versions in these config files.

gkv311 n's picture

CMake generates a lot of hardcoded paths by default, so that this is kind of an issue of CMake itself, that you may try to fight against in CMake scripts of your own.

If you know how to fix this particular issue - fill free to share your thoughts / patches. Maybe homebrew maintainers know better how to deal with such issues in their packaging workflow (I don't recall similar reports for OCCT packages for Linux, but maybe I'm wrong).