Hi Bastian,
Thanks for taking the time to propose a bug report. However (and please see below) I don't think this is the way forward. There have been a lot of recent changed in RcppParallel upstream (as I lurk on the GH repo which is part of our Rcpp org), and maybe some of these things will be different under the as-of-right-now-still-unreleased version 5.1.0 of RcppParallel. I am CCing its (upstream) maintainer / core developer who is also a friend and Rcpp collaborator. In the meantime please see https://github.com/RcppCore/RcppParallel/blob/master/inst/NEWS As for your suggested patch to R's own dynload.c: that is very well tested and robust system code I do not have any real intention of changing because one package out of 17k at CRAN is having hickups under one (maybe suboptimal) Debian config. Maybe Andreas (for r-cran-rcppparallel) should talk to Kevin here to see what if anything could or should be changed. As for ~ expansion, we usually do that _before_ calling dyn.load() and passing paths on to other C level functions: > Sys.glob("~/.Rprofile") [1] "/home/edd/.Rprofile" > I would be happy to take a patch forward to R Core and fend for it, as we have in fact done in the past, but I think I would need to see a stronger case of why we would all of a sudden inject a getcwd() here. Happy to chat more and hear real arguments if there are any. Cheers, Dirk On 10 February 2021 at 18:55, Bastian Blank wrote: | Control: clone -1 -2 | Control: reassign -1 r-base 4.0.3-1 | Control: retitle -1 r-base: dyn.load not useful for system libraries | Control: affects -1 r-cran-rcppparallel 5.0.2+dfsg-3 | Control: severity -1 important | Control: reassign -2 r-cran-rcppparallel 5.0.2+dfsg-3 | Control: retitle -2 r-cran-rcppparallel: generates broken load path for libtbb and fails on several architectures | Control: severity -2 serious | | Hi Andreas | | This are actually two bugs: | - r-base dyn.load not accepting relative library names on Linux systems | and | - r-cran-rcppparallel trying to workaround the bug in dyn.load by | deducting the full path of libtbb from the architecture instead of the | correct multiarch setting and failing. | | This has nothing to do with r-cran-rstan or r-cran-rstanarm, but it | seems to be the first one to find out. I've attached patches to fix | both problems, properly re-assigned and adjusted the bugs. | | This behaviour of R dyn.load might even be considered a security | vulnerability, because loading libraries from the working directory is a | problem. | | Bastian | | -- | Kirk to Enterprise -- beam down yeoman Rand and a six-pack. | x[DELETED ATTACHMENT r-base_4.0.3-1.1.debdiff, plain text] | x[DELETED ATTACHMENT r-cran-rcppparallel_5.0.2+dfsg-3.1.debdiff, plain text] -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org