emit an -rpath for tbb in LdFlags() on macos

The TBB libraries RcppParallel ships on macOS record an '@rpath'-relative
install name, but LdFlags() emitted only a '-L' search path. That satisfies
the linker, so downstream packages built fine, but the resulting binary
carried no LC_RPATH at all: dyld could resolve '@rpath/libtbb.dylib' only
when RcppParallel -- and hence TBB -- had already been loaded into the
process. Loading such a binary on its own failed with "Library not loaded:
@rpath/libtbb.dylib".

Pair the '-L' with a matching '-rpath', as the TBB_LIB branch just above
already does. A stale rpath (e.g. in a binary package built where
RcppParallel lived at a different path) is harmless: dyld skips a path that
does not resolve and falls back to matching the already-loaded image, which
is the current behaviour.

Fixes #209.

Author: kevinushey

NEWS.md

@@ -1,5 +1,13 @@
 # RcppParallel (development version)
 
+* On macOS, `RcppParallel::LdFlags()` now also emits an `-rpath` entry for the
+  directory containing the TBB libraries. The libraries record an
+  `@rpath`-relative install name, so packages linking against them previously
+  produced binaries with no runtime search path for TBB; those binaries could
+  only be loaded when RcppParallel (and hence TBB) already happened to be
+  loaded into the process, and failed with "Library not loaded:
+  @rpath/libtbb.dylib" otherwise. (#209)
+
 * Fixed an issue where compiling code including `tbb/parallel_for_each.h`
   could fail with toolchains that accept `-std=c++20` but provide a
   pre-C++20 standard library, with errors of the form "no member named

R/tbb.R

@@ -108,8 +108,15 @@ tbbLdFlags <- function() {
 
    # explicitly link on macOS
    # https://github.com/RcppCore/RcppParallel/issues/206
+   #
+   # the bundled libraries record an '@rpath'-relative install name (e.g.
+   # '@rpath/libtbb.dylib'), so '-L' alone is not enough: the client library
+   # ends up with no runtime search path for TBB at all, and only loads
+   # because RcppParallel -- and hence TBB -- normally happens to be loaded
+   # into the process first. Emit a matching '-rpath' so the client can
+   # resolve TBB on its own. (#209)
    if (is_mac()) {
-      fmt <- "-L%s -l%s -l%s"
+      fmt <- "-L%1$s -Wl,-rpath,%1$s -l%2$s -l%3$s"
       return(sprintf(fmt, asBuildPath(tbbLibraryPath()), TBB_NAME, TBB_MALLOC_NAME))
    }
 

tests/test-ld-flags.R

@@ -0,0 +1,33 @@
+# Unit tests for tbbLdFlags(), the linker flags handed to downstream packages
+# via RcppParallel::LdFlags().
+#
+# On macOS, the TBB libraries RcppParallel ships record an '@rpath'-relative
+# install name (e.g. '@rpath/libtbb.dylib'), so a '-L' search path alone only
+# satisfies the linker: the resulting binary carries no runtime search path for
+# TBB, and dyld can resolve it only when RcppParallel has already pulled TBB
+# into the process. Every '-L' we emit must therefore be paired with a matching
+# '-rpath'. (#209)
+
+RcppParallel:::test_init()
+
+flags <- tbbLdFlags()
+
+assert(is.character(flags))
+assert(length(flags) == 1L)
+assert(!is.na(flags))
+
+if (is_mac()) {
+
+   parts <- strsplit(flags, "\\s+")[[1L]]
+
+   libPaths <- sub("^-L", "", grep("^-L", parts, value = TRUE))
+   rpaths <- sub("^-Wl,-rpath,", "", grep("^-Wl,-rpath,", parts, value = TRUE))
+
+   # we always link TBB explicitly on macOS, so there is a search path to check
+   assert(length(libPaths) > 0L)
+   assert(all(nzchar(libPaths)))
+
+   # and each one must also be searched at load time
+   assert(all(libPaths %in% rpaths))
+
+}