Testing fails on MacOs Sonoma / new Xcode (?)

[t-w]

Recently MacOs tests for CMake build started failing with the following error:

Run examples/tests/test_examples_basic.sh bin/
dyld[3536]: Library not loaded: @rpath/libadf.1.dylib
=============================================================
  Referenced from: <D0BF97E0-B827-3C12-A423-EC317A63BCB6> /usr/local/bin/unadf
executing:  unadf -r examples/tests/arccsh.adf
  Reason: no LC_RPATH's found
examples/tests/test_examples_basic.sh: line 39:  3536 Abort trap: 6           ${EXEC} $@
Error: Process completed with exit code 134.

So basically the dynamic linker for MacOs dyld has trouble finding/loading the shared library.

It seems there is some kind of an issue either with the new MacOs (Sonoma) and/or its (default?) environment, or with updated XCode (though setting the rpath to @rpath/libadf.1.dylib did not change...

There are many discussions on this, in particular, Apple's developer forum contains a relevant thread - but the issue seems unresolved.

If anyone with more insight on MacOs matter has tips what has changed and how it should be addressed, help welcomed.

[t-w]

What is interesting here is that the test of the build using autotools works and passes the tests. So maybe something changed CMake or some build system part.

[t-w]

Here is a suggestion that there are some security setting which prevents setting DYLIB_LIBRARY_PATH. However, on an older MacOs, I do not see this variable set (maybe only for dyld?) and everything worked...

There is some proposed workaround - but not really a solution for a cloud (manipulation with boot time settings...).

[t-w]

It looks like the problem is in the lack of setting LC_RPATH in the binaries that use the dynamic library. On an older MacOs:

$ otool -l build/shared/examples/unadf
[...]
Load command 14
          cmd LC_RPATH
      cmdsize 72
         path /Users/[...]/src/ADFlib/build/shared/src (offset 12)
[...]

for a binary which is not installed. For the installed one, this should change to /usr/local/lib.

However, on current MacOs on github, CMake build produces a binary which, when installed, does not have the LC_RPATH at all...

However, it does have the LC_RPATH, ealier, when it is built and not yet installed:

$ otool -l build/shared/examples/unadf
[...]
 Load command 16
          cmd LC_RPATH
      cmdsize 64
         path /Users/runner/work/ADFlib/ADFlib/build/shared/src (offset 12)
[...]

and the tests running from CMake pass!

So the problem comes from something done during installation - the LC_RPATH is basically removed. It was set properly before, so something must have changed either in MacOs, XCode or CMake...

Reasumming - the binaries linked with the library and installed(!) indeed lack the LC_RPATH and their execution fails. The question remain: why it is not set?

[t-w]

Apparently, on the new images of MacOs, CMake require setting the INSTALL_RPATH property to properly configure binaries being installed.

Why exactly this started to be needed? - no clue so far... (some env. setting changed? CMake changed?). Again, if anyone has some insights - comments welcomed.