Open barracuda156 opened 1 year ago
Are you also setting the rpath
to include that location? It seems like no, which would explain why it links but fails at runtime
Are you also setting the
rpath
to include that location? It seems like no, which would explain why it links but fails at runtime
@WardBrian I have tried to do that after I got the failure, but to no avail. It is quite possible though, that I made some mistake in the relevant chunk of code. I will look into that.
On a side-note, rstanarm
appears to be the only package failing this way. Other dependents of RcppParallel
link and load correctly. For example, bayesforecast
:
/opt/local/bin/g++-mp-12 -std=gnu++14 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/opt/local/Library/Frameworks/R.framework/Resources/lib -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-rpath,/opt/local/lib/libgcc -arch ppc -o bayesforecast.so RcppExports.o stanExports_SVM.o stanExports_Sarima.o stanExports_ets.o stanExports_tgarch.o -L/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/RcppParallel/lib/ -Wl,-rpath,/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/RcppParallel/lib/ -ltbb -ltbbmalloc -F/opt/local/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
installing to /opt/local/var/macports/build/_opt_PPCRosettaPorts_R_R-bayesforecast/R-bayesforecast/work/destroot/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/00LOCK-bayesforecast/00new/bayesforecast/libs
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
*** copying figures
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (bayesforecast)
@WardBrian This fixed the build:
--- src/Makevars.orig 2022-04-09 03:53:34.000000000 +0700
+++ src/Makevars 2022-12-19 06:37:41.000000000 +0700
@@ -4,7 +4,7 @@
PKG_CXXFLAGS = `"${R_HOME}/bin$(R_ARCH_BIN)/Rscript" -e "RcppParallel::CxxFlags()"` `"${R_HOME}/bin$(R_ARCH_BIN)/Rscript" -e "StanHeaders:::CxxFlags()"`
SHLIB_LDFLAGS = $(SHLIB_CXXLDFLAGS)
SHLIB_LD = $(SHLIB_CXXLD)
-PKG_LIBS = `"${R_HOME}/bin$(R_ARCH_BIN)/Rscript" -e "RcppParallel::RcppParallelLibs()"` -L"$(TBB_LIB)" -ltbb -ltbbmalloc
+PKG_LIBS = `"${R_HOME}/bin$(R_ARCH_BIN)/Rscript" -e "RcppParallel::RcppParallelLibs()"` -L"$(TBB_LIB)" -Wl,-rpath,"$(TBB_LIB)" -ltbb -ltbbmalloc
CXX_STD = CXX14
SOURCES = $(wildcard stan_files/*.stan)
rstanarm TBB linking will be fixed with the merge of #574
rstanarm TBB linking will be fixed with the merge of #574
@andrjohns Sounds good. I hope the new arrangement will remain compatible with my Macports solution (the PR you have probably seen).
P. S. BTW, any plans of moving to the new oneTBB
? I have it fixed for PPC (and likely i386): https://github.com/oneapi-src/oneTBB/pull/840
Old TBB
builds fine with a few fixes (existing RcppParallel
code does not work correctly), but I guess no one gonna work on it.
I am making an implementation for R packages in Macports now, and I would like to have
rstanarm
among supported packages. This is still WIP, however what mostly remains to be done is fine-tuning for Macports environment. That is, pretty much everything already builds fine – both locally on my machines and on Macports build bots.I get an error, however, with
rstanarm
: for some reason, it cannot findlibtbb.dylib
, even though it is there (see log below). No external version ofTBB
is installed, so the failure is not caused by duplicate dylibs. Existinglibtbb.dylib
is sitting inRcppParallel
package, and linker flag is pointing to the correct location:-L/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/RcppParallel/lib/ -ltbb -ltbbmalloc
. Yet when testing package loading, it fails to find it.P. S. It is probably desirable to dump an old
tbb
inRcppParallel
altogether and use an externaloneTBB
(given that we have fixed it forppc32
, so all macOS are covered), but I am not sure if that gonna work smoothly, since ABI has changed quite a bit.@andrjohns @WardBrian Any ideas here?