Apple: Set CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG on non-macOS too

Since CMake 3.19, we no longer support macOS SDKs older than 10.5,
which corresponds to Xcode 3. Supporting older Xcode versions for
device platforms is also not realistic. We therefore expect the -rpath
linker option should always be supported now.

When targeting iOS, tvOS or watchOS, the previous disabling of -rpath
support meant that the install_name_dir of shared libraries and
frameworks was unable to use @rpath. This resulted in embedding
absolute paths for their install_name. When they were embedded in an
app bundle, this would cause the app to fail at runtime. By enabling the
-rpath linker option, the default install_name_dir is now @rpath for these platforms, which results in binaries that do work at runtime.

Fixes: #20036

1 files changed, 6 insertions, 0 deletions

diff --git a/Help/release/3.20.rst b/Help/release/3.20.rst
index 9991eab..e452926 100644
--- a/Help/release/3.20.rst
+++ b/Help/release/3.20.rst
@@ -341,3 +341,9 @@ Changes made since CMake 3.20.0 include the following.
   and ``Intl_IS_BUILTIN``, but they were not implemented correctly.
   These have been removed and replaced with a single ``Intl_IS_BUILT_IN``
   check, whose name is consistent with the :module:`FindIconv` module.
+
+* The ``-rpath`` linker flag is now specified as supported on all Apple
+  platforms, not just macOS.  The ``install_name_dir`` used for
+  iOS, tvOS and watchOS should now default to ``@rpath`` instead of using
+  a full absolute path and failing at runtime when the library or framework
+  is embedded in an application bundle (see :prop_tgt:`XCODE_EMBED_<type>`).