Great, thanks much!
Gabor
On Sat, Dec 15, 2018 at 9:47 PM Simon Urbanek
wrote:
>
> Gabor,
>
> this appears to be a known issue with lldb[1] - it doesn’t pass DYLD_*
> variables to the executable anymore. You have to explicitly set it in lldb:
>
> process launch -v
>
Gabor,
this appears to be a known issue with lldb[1] - it doesn’t pass DYLD_*
variables to the executable anymore. You have to explicitly set it in lldb:
process launch -v
DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
or similar. Unfortunately, it means the wrapper
On Sat, Dec 15, 2018 at 2:29 AM Simon Urbanek
wrote:
[...]
> although the R binary itself was omitted. However it doesn’t actually matter,
> because it is always executed through the R shell wrapper which correctly
> prepends $R_HOME/lib which is why R works just fine.
This does not seem to
Gabor,
unfortunately, I didn’t see your original e-mail. The paths are correct in
libraries, e.g.:
$ otool -L /Library/Frameworks/R.framework/Resources/lib/libRblas.dylib | grep
libomp
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libomp.dylib
(compatibility version
Would it be possible to fix this for the builds of the upcoming release?
Thanks,
Gabor
On Wed, Oct 10, 2018 at 11:12 PM Gábor Csárdi wrote:
>
> https://cran.r-project.org/bin/macosx/tools/ suggests installing a
> special clang6 build. OTOH, the R binary links to a library that comes
> with
https://cran.r-project.org/bin/macosx/tools/ suggests installing a
special clang6 build. OTOH, the R binary links to a library that comes
with CRAN's clang4 build:
❯ otool -L /Library/Frameworks/R.framework/Resources/bin/exec/R
/Library/Frameworks/R.framework/Resources/bin/exec/R:
