[R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

Gábor Csárdi
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:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib
(compatibility version 3.5.0, current version 3.5.1)
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
(compatibility version 0.0.0, current version 0.0.0)
/usr/local/clang4/lib/libomp.dylib (compatibility version 5.0.0,
current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)

Notice '/usr/local/clang4/lib/libomp.dylib' above. R seems to run
happily without this file, though, until you start it with lldb:

❯ R -d  lldb
(lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
Current executable set to
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).
(lldb) run
Process 74239 launched:
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)
dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib
  Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
  Reason: image not found
Process 74239 stopped
* thread #1, stop reason = signal SIGABRT
    frame #0: 0x000000010002c9ee dyld`__abort_with_payload + 10
dyld`__abort_with_payload:
->  0x10002c9ee <+10>: jae    0x10002c9f8               ; <+20>
    0x10002c9f0 <+12>: movq   %rax, %rdi
    0x10002c9f3 <+15>: jmp    0x10002c300               ; cerror_nocancel
    0x10002c9f8 <+20>: retq

After clang4 is installed from http://r.research.att.com/libs/
everything is fine.

Is linking to this library intentional? If yes, then maybe the web
could be updated to suggest installing clang6 and clang4?

Thanks,
Gabor

_______________________________________________
R-SIG-Mac mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Reply | Threaded
Open this post in threaded view
|

Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

Gábor Csárdi
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 <[hidden email]> 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 CRAN's clang4 build:
>
> ❯ otool -L  /Library/Frameworks/R.framework/Resources/bin/exec/R
> /Library/Frameworks/R.framework/Resources/bin/exec/R:
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib
> (compatibility version 3.5.0, current version 3.5.1)
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> /usr/local/clang4/lib/libomp.dylib (compatibility version 5.0.0,
> current version 5.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1226.10.1)
>
> Notice '/usr/local/clang4/lib/libomp.dylib' above. R seems to run
> happily without this file, though, until you start it with lldb:
>
> ❯ R -d  lldb
> (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
> Current executable set to
> '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).
> (lldb) run
> Process 74239 launched:
> '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)
> dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib
>   Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
>   Reason: image not found
> Process 74239 stopped
> * thread #1, stop reason = signal SIGABRT
>     frame #0: 0x000000010002c9ee dyld`__abort_with_payload + 10
> dyld`__abort_with_payload:
> ->  0x10002c9ee <+10>: jae    0x10002c9f8               ; <+20>
>     0x10002c9f0 <+12>: movq   %rax, %rdi
>     0x10002c9f3 <+15>: jmp    0x10002c300               ; cerror_nocancel
>     0x10002c9f8 <+20>: retq
>
> After clang4 is installed from http://r.research.att.com/libs/
> everything is fine.
>
> Is linking to this library intentional? If yes, then maybe the web
> could be updated to suggest installing clang6 and clang4?
>
> Thanks,
> Gabor

_______________________________________________
R-SIG-Mac mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Reply | Threaded
Open this post in threaded view
|

Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

Simon Urbanek
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 5.0.0, current version 5.0.0)

as well as packages:

$ otool -L BNN/libs/BNN.so | grep libomp
        /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)

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 has nothing to do with clang4/clang6. We use clang6 to compile, it is only a matter of the location of Intel’s libomp.

Cheers,
Simon




> On Dec 14, 2018, at 6:00 PM, Gábor Csárdi <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 CRAN's clang4 build:
>>
>> ❯ otool -L  /Library/Frameworks/R.framework/Resources/bin/exec/R
>> /Library/Frameworks/R.framework/Resources/bin/exec/R:
>> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib
>> (compatibility version 3.5.0, current version 3.5.1)
>> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
>> (compatibility version 0.0.0, current version 0.0.0)
>> /usr/local/clang4/lib/libomp.dylib (compatibility version 5.0.0,
>> current version 5.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1226.10.1)
>>
>> Notice '/usr/local/clang4/lib/libomp.dylib' above. R seems to run
>> happily without this file, though, until you start it with lldb:
>>
>> ❯ R -d  lldb
>> (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
>> Current executable set to
>> '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).
>> (lldb) run
>> Process 74239 launched:
>> '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)
>> dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib
>>  Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
>>  Reason: image not found
>> Process 74239 stopped
>> * thread #1, stop reason = signal SIGABRT
>>    frame #0: 0x000000010002c9ee dyld`__abort_with_payload + 10
>> dyld`__abort_with_payload:
>> ->  0x10002c9ee <+10>: jae    0x10002c9f8               ; <+20>
>>    0x10002c9f0 <+12>: movq   %rax, %rdi
>>    0x10002c9f3 <+15>: jmp    0x10002c300               ; cerror_nocancel
>>    0x10002c9f8 <+20>: retq
>>
>> After clang4 is installed from http://r.research.att.com/libs/
>> everything is fine.
>>
>> Is linking to this library intentional? If yes, then maybe the web
>> could be updated to suggest installing clang6 and clang4?
>>
>> Thanks,
>> Gabor
>
> _______________________________________________
> R-SIG-Mac mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

_______________________________________________
R-SIG-Mac mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Reply | Threaded
Open this post in threaded view
|

Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

Gábor Csárdi
On Sat, Dec 15, 2018 at 2:29 AM Simon Urbanek
<[hidden email]> 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 happen with

❯ R -d lldb
(lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
[...]
(lldb) run
[...]
Process 52551 launched:
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)
dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib
  Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
  Reason: image not found
Process 52551 stopped
* thread #1, stop reason = signal SIGABRT
    frame #0: 0x000000010002c9ee dyld`__abort_with_payload + 10
dyld`__abort_with_payload:
->  0x10002c9ee <+10>: jae    0x10002c9f8               ; <+20>
    0x10002c9f0 <+12>: movq   %rax, %rdi
    0x10002c9f3 <+15>: jmp    0x10002c300               ; cerror_nocancel
    0x10002c9f8 <+20>: retq
(lldb)

So maybe this is a bug in the R shell wrapper then? I am not sure, but
it would be nice to make 'R -d lldb' work out of the box.

Thanks,
G.

[...]

_______________________________________________
R-SIG-Mac mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Reply | Threaded
Open this post in threaded view
|

Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

Simon Urbanek
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 can’t help here. You can get the full setting from R if the above is not sufficient:

$ R --slave -e 'cat(Sys.getenv("DYLD_FALLBACK_LIBRARY_PATH"))'
/Library/Frameworks/R.framework/Resources/lib:/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/lib/server

Cheers,
Simon

PS: I have fixed the path for the nightly builds so it should be fixed in tonight’s build, but the lesson is that the debugger does indeed have an environment that is different from the actual executable.

[1] http://lists.llvm.org/pipermail/lldb-dev/2015-October/008691.html


> On Dec 15, 2018, at 4:41 AM, Gábor Csárdi <[hidden email]> wrote:
>
> On Sat, Dec 15, 2018 at 2:29 AM Simon Urbanek
> <[hidden email]> 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 happen with
>
> ❯ R -d lldb
> (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
> [...]
> (lldb) run
> [...]
> Process 52551 launched:
> '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)
> dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib
>  Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
>  Reason: image not found
> Process 52551 stopped
> * thread #1, stop reason = signal SIGABRT
>    frame #0: 0x000000010002c9ee dyld`__abort_with_payload + 10
> dyld`__abort_with_payload:
> ->  0x10002c9ee <+10>: jae    0x10002c9f8               ; <+20>
>    0x10002c9f0 <+12>: movq   %rax, %rdi
>    0x10002c9f3 <+15>: jmp    0x10002c300               ; cerror_nocancel
>    0x10002c9f8 <+20>: retq
> (lldb)
>
> So maybe this is a bug in the R shell wrapper then? I am not sure, but
> it would be nice to make 'R -d lldb' work out of the box.
>
> Thanks,
> G.
>
> [...]
>

_______________________________________________
R-SIG-Mac mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Reply | Threaded
Open this post in threaded view
|

Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

Gábor Csárdi
Great, thanks much!

Gabor

On Sat, Dec 15, 2018 at 9:47 PM Simon Urbanek
<[hidden email]> 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 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
>
> or similar. Unfortunately, it means the wrapper can’t help here. You can get the full setting from R if the above is not sufficient:
>
> $ R --slave -e 'cat(Sys.getenv("DYLD_FALLBACK_LIBRARY_PATH"))'
> /Library/Frameworks/R.framework/Resources/lib:/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/lib/server
>
> Cheers,
> Simon
>
> PS: I have fixed the path for the nightly builds so it should be fixed in tonight’s build, but the lesson is that the debugger does indeed have an environment that is different from the actual executable.
>
> [1] http://lists.llvm.org/pipermail/lldb-dev/2015-October/008691.html
>
>
> > On Dec 15, 2018, at 4:41 AM, Gábor Csárdi <[hidden email]> wrote:
> >
> > On Sat, Dec 15, 2018 at 2:29 AM Simon Urbanek
> > <[hidden email]> 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 happen with
> >
> > ❯ R -d lldb
> > (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
> > [...]
> > (lldb) run
> > [...]
> > Process 52551 launched:
> > '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)
> > dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib
> >  Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
> >  Reason: image not found
> > Process 52551 stopped
> > * thread #1, stop reason = signal SIGABRT
> >    frame #0: 0x000000010002c9ee dyld`__abort_with_payload + 10
> > dyld`__abort_with_payload:
> > ->  0x10002c9ee <+10>: jae    0x10002c9f8               ; <+20>
> >    0x10002c9f0 <+12>: movq   %rax, %rdi
> >    0x10002c9f3 <+15>: jmp    0x10002c300               ; cerror_nocancel
> >    0x10002c9f8 <+20>: retq
> > (lldb)
> >
> > So maybe this is a bug in the R shell wrapper then? I am not sure, but
> > it would be nice to make 'R -d lldb' work out of the box.
> >
> > Thanks,
> > G.
> >
> > [...]
> >
>

_______________________________________________
R-SIG-Mac mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac