JJB,
no, there are many different paths which apply for different compilers used in
the past. Note that the line you are referring to is a -change command so it
only applies if that entry is present in the binary, so it will only affect
clang4, not the currently used compilers. The current comp
Simon,
This is great! Thank you for sharing. I think I noticed a bug with the fixpathR
script: clang4 complier is hard coded.
https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R-build/fixpathR
Instances:
find . -name \*.dylib -or -name \*.so| xargs -n 1 install_name_tool -change
/usr/loc
hi simon,
it's been interesting looking at all your install_name_tool patching ...
i've been doing something very similar with jamovi (and jasp before
that), where we ship an embedded version of R inside the app bundle. in
my case, i have to patch all the paths to be relative (i.e.
@executabl
Jonathon,
when you build R it requires the compiler runtime libraries from /usr/local. We
don't want to require users to install compilers just to run R, so we supply
copies of those runtime libraries in the lib directory.
You can replicate the way CRAN R is built using the CRAN build scripts in
hi,
i've successfully built R for macOS, and it all works well, however i'm
wanting to achieve compatibility with the prebuilt .tgz CRAN R packages.
the compatibility issue i've been having is that the R produced lacks
the Resources/lib/libc++.1.dylib. the prebuilt CRAN R packages link to
th
