load tbb stub library on windows again#249
Merged
Merged
Conversation
RcppParallel 6.0.0 (via #241) stopped loading any TBB library in .onLoad on Windows, on the grounds that TBB is statically linked there. However, we still ship a stub tbb.dll (see src/install.libs.R) for packages that link with '-ltbb', e.g. via StanHeaders' LdFlags(). Those packages record a load-time dependency on 'tbb.dll' in their DLL's import table, and the Windows loader can only resolve it against an already-loaded module -- RcppParallel's lib/x64 directory is not on the DLL search path. As a result, with 6.0.0 on Windows, Stan-based packages fail to load with: LoadLibrary failure: The specified module could not be found. as seen with e.g. WSPsignal on r-universe: https://github.com/r-universe/cran/actions/runs/30028540221/job/89334243681 Restore the preload, resolving the stub directly (tbbLibraryPath() now reports static library names on Windows, so it cannot be used here).
…-tbb-stub # Conflicts: # NEWS.md
kevinushey
added a commit
that referenced
this pull request
Jul 23, 2026
The stub loader added in #249 resolved tbb.dll via tbbRoot(), which prefers TBB_LIB when set -- and on Windows, configure always sets TBB_LIB to the Rtools library directory, which contains only static TBB libraries. As a result, the lookup silently failed and the stub was never loaded. Resolve against the package's own lib directory instead, which is where install.libs.R places the stub.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
RcppParallel 6.0.0 (via #241) stopped loading any TBB library in
.onLoadon Windows, on the grounds that TBB is statically linked there. However, we still ship a stubtbb.dll(seesrc/install.libs.R) for packages that link with-ltbb, e.g. via StanHeaders'LdFlags(). Those packages record a load-time dependency ontbb.dllin their DLL's import table, and the Windows loader can only resolve that against an already-loaded module -- RcppParallel'slib/x64directory is not on the DLL search path (and-Wl,-rpathis a no-op in PE binaries).As a result, with 6.0.0 on Windows, Stan-based packages fail their install-time load test with:
Seen with e.g. WSPsignal on r-universe: https://github.com/r-universe/cran/actions/runs/30028540221/job/89334243681
Pre-built binaries that import
tbb.dll(the original motivation for the stub, per the comment insrc/install.libs.R) are affected the same way.Verified against the r-universe
RcppParallel_6.0.0.zipWindows binary: it ships onlylibs/x64/RcppParallel.dll(which exports the oneTBBr1runtime symbols) andlib/x64/tbb.dll(the stub, self-contained), so-ltbbdirect-links the stub and the resulting import can never resolve without a preload.Fix
Restore the
.onLoadpreload of the stub on Windows. The stub is resolved directly viatbbRoot()rather thantbbLibraryPath(), since #241 repurposed the latter to report static library names on Windows.Notes
tbb.dllis shipped on Windows, soloadTbbLibrary("tbbmalloc")still returnsNULLthere, as before.