You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RcppParallel 6.1.1: tbbLibraryPath() broken on Windows - looks in build-time RTools not runtime #270
The use of RcppParallel::tbbLibraryPath("tbb") on Windows returns nothing when called from the CRAN pre-built binary, and tbbRoot() returns a filepath on a D:/ drive:
All works as expected when RcppParallel is built from source:
install.packages("RcppParallel", type="source")
#> Installing package into 'C:/Users/andrew/AppData/Local/R/win-library/4.6'#> (as 'lib' is unspecified)RcppParallel::tbbLibraryPath("tbb")
#> [1] "C:/rtools45/x86_64-w64-mingw32.static.posix/lib/libtbb12.a"RcppParallel:::tbbRoot()
#> [1] "C:/rtools45/x86_64-w64-mingw32.static.posix/lib"
This appears to be due to RcppParallel looking in the dir specified by the internal TBB_LIB variable set by the configure run at package build time, rather than the location at runtime
I've got a package that I've updated to link directly to the tbb libraries instead of RcppParallel, and it uses RcppParallel::tbbLibraryPath() to lookup the right location and library name.
Unfortunately, this results in a build failure on Windows when the library path returns nothing:
Thanks; that's exactly the example I needed. One thought, though -- why not use RcppParallelLibs() instead of deriving the TBB library paths + compiler invocation by hand?
EDIT: But that also appears to be similarly broken ...
Thanks; that's exactly the example I needed. One thought, though -- why not use RcppParallelLibs() instead of deriving the TBB library paths + compiler invocation by hand?
EDIT: But that also appears to be similarly broken ...
That change was spawned from this issue where the recommendation was to link against TBB directly since the symbols weren't exported through RcppParallel anymore - but it looks like that might have changed?
You're right, but now that I've seen the fallout, I think I'm going to revert that and return to just shipping tbb.dll and tbbmalloc.dll, with the correct TBB flags.
Activity
kevinushey commentedon Jul 28, 2026
Argh. Thanks for the bug report; I'll take a look.
kevinushey commentedon Jul 28, 2026
Beyond this, what actual issue(s) are you seeing with using RcppParallel right now? A more concrete example would be helpful.
andrjohns commentedon Jul 28, 2026
I've got a package that I've updated to link directly to the tbb libraries instead of
RcppParallel, and it usesRcppParallel::tbbLibraryPath()to lookup the right location and library name.Unfortunately, this results in a build failure on Windows when the library path returns nothing:
resolve the tbb library path against the installed package on windows
kevinushey commentedon Jul 28, 2026
Thanks; that's exactly the example I needed. One thought, though -- why not use
RcppParallelLibs()instead of deriving the TBB library paths + compiler invocation by hand?EDIT: But that also appears to be similarly broken ...
resolve the tbb library path against the installed package on windows (…
andrjohns commentedon Jul 28, 2026
That change was spawned from this issue where the recommendation was to link against TBB directly since the symbols weren't exported through RcppParallel anymore - but it looks like that might have changed?
kevinushey commentedon Jul 28, 2026
You're right, but now that I've seen the fallout, I think I'm going to revert that and return to just shipping tbb.dll and tbbmalloc.dll, with the correct TBB flags.
build the bundled onetbb as a shared library on windows (#274)
kevinushey commentedon Jul 30, 2026
Alright -- RcppParallel 6.2.0 is now on CRAN and we again ship separate tbb libraries that you should be able to discover and link to as appropriate.