Ah, I see, so it’s an XQuartz issue… thanks for clarifying!
> On 22 Dec 2020, at 10:37, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
>
> On 22/12/2020 3:45 a.m., Taras Zakharko wrote:
>> Thanks, this is great!
>> Why do you say that OpenGL is not available though? M1 has a fully working
>> OpenGL framework implemented on top of Metal. Apple might have deprecated
>> OpenGL, but I think it’s unlikely they will drop it any time soon seeing
>> that they went through the effort of updating their OpenGL wrapper to
>> support desktop GL.
>
> rgl uses GLX from XQuartz, and from the rgl install log:
>
> ld: warning: ignoring file /usr/X11/lib/libGL.dylib, missing required
> architecture arm64 in file /usr/X11/lib/libGL.dylib (2 slices)
> ld: warning: ignoring file /usr/X11/lib/libGLU.dylib, missing required
> architecture arm64 in file /usr/X11/lib/libGLU.dylib (2 slices)
> ld: warning: ignoring file /usr/X11/lib/libX11.dylib, missing required
> architecture arm64 in file /usr/X11/lib/libX11.dylib (2 slices)
>
> and the the dyn.load of rgl.so fails with Symbol not found: _XAllocClassHint.
>
> But even if this is eventually fixed, these changes make installing rgl a lot
> easier.
>
> Duncan Murdoch
>
>
>> Best,X
>> Taras
>>> On 21 Dec 2020, at 17:32, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
>>>
>>> Along the same lines: I have been working with Prof Ripley to get rgl to
>>> work on M1. Since OpenGL isn't available, it produces only WebGL output
>>> (viewable using rglwidget()) and can't do snapshots or Postscript output,
>>> but it should be enough to let its reverse dependencies install.
>>>
>>> Anyone interested in testing it can install from R-forge or Github:
>>>
>>> install.packages("rgl", repos="http://R-Forge.R-project.org";, type =
>>> "source")
>>>
>>> or
>>>
>>> remotes::install_github("https://github.com/r-forge/rgl";, subdir =
>>> "pkg/rgl")
>>>
>>> To see what it looks like without OpenGL on Windows, try
>>>
>>> Sys.setenv(RGL_NO_OPENGL = TRUE)
>>>
>>> before the install, or on a Unix-alike,
>>>
>>> install.packages("rgl", repos="http://R-Forge.R-project.org";,
>>> INSTALL_opts = '--configure-args="--disable-opengl"',
>>> type = "source")
>>>
>>> Duncan Murdoch
>>>
>>>
>>> On 21/12/2020 9:01 a.m., Jeroen Ooms wrote:
>>>> On Sun, Dec 13, 2020 at 6:45 AM Prof Brian Ripley <rip...@stats.ox.ac.uk>
>>>> wrote:
>>>>>
>>>>> We have managed a fairly complete check run with natively-compiled R and
>>>>> packages, and a full one with x86_64 R and packages running under
>>>>> Rosetta (mainly using CRAN binary distributions).
>>>>>
>>>>> The bottom line is that running under Rosetta works really well.
>>>>> Although relative speeds vary widely, using the native build was
>>>>> 1.3-1.5x faster for the central 50% of the distribution. And a MacBook
>>>>> Air is remarkably capable for a lightweight laptop.
>>>>>
>>>>>
>>>>> x86_64 tests
>>>>> ------------
>>>>>
>>>>> I compared the check output to that from my 2012 iMac: typically this
>>>>> was 1.7x faster than the iMac (and benchmarks have current iMac/MacMini
>>>>> about that much faster than mine).
>>>>>
>>>>> A couple of packages ran much slower than on the iMac and hit their
>>>>> check limits, and one fails because it checks elapsed time (and was
>>>>> slower than on the iMac).
>>>>>
>>>>> 10 packages segfaulted in their checks (but most of those are known to
>>>>> segfault intermittently on other platforms).
>>>>>
>>>>> There were issues with packages attempting to work with Python, which
>>>>> may be Big Sur differences.
>>>>>
>>>>> Given that I have 58 packages failing their checks on the iMac under
>>>>> High Sierra this was a very small amount of degradation.
>>>>>
>>>>>
>>>>> native tests
>>>>> ------------
>>>>>
>>>>> Currently I have 57 CRAN packages failing to install, but 650 others
>>>>> require those or BioC packages which fail to install (the most commonly
>>>>> required being rgl and V8 [*]). And ca 120 packages are not using
>>>>> conditionally Suggests packages which fail to install.
>>>>>
>>>>> There are segfaults from ca 150 packages using minpack.lm::nls.lm,
>>>>> deSolve::lsoda, rootSolve::stode ... all of which use Fortran.
>>>>>
>>>>> That platform does not have long doubles nor extended precision but the
>>>>> CRAN checking on Linux and Sparc with --disable-long-doubles has paid
>>>>> off: only a handful of check results show numerical differences.
>>>>>
>>>>> Quite a lot of external software and several packages have had to be
>>>>> patched, and it is early days for the former (and the Fortran compiler)
>>>>> - for example I was able to build v8, but V8 segfaulted in its checks.
>>>> Thank you for these fantastic efforts. I have added a binary for
>>>> libv8, so it works on arm64 now.
>>>> Re: the more general problem of external software, are there any
>>>> details available on how the external software on your server was
>>>> built/configured? For example I don't see libv8 on
>>>> https://github.com/R-macos/recipes or
>>>> https://mac.r-project.org/libs-arm/ so this makes it difficult for
>>>> package authors to debug a problem.
>>>> FWIW, Homebrew is quickly catching up on M1 support. Many people are
>>>> contributing patches, and François-Xavier Coudert (the same person who
>>>> is publishing the gfortran binaries) is publishing the homebrew arm64
>>>> binaries (aka bottles), hundreds over the past weekend:
>>>> https://github.com/Homebrew/homebrew-core/commits?author=fxcoudert
>>>> It is recommended to install homebrew on ARM in /opt/homebrew, and not
>>>> /usr/local, to prevent binaries from getting mixed up
>>>> (https://github.com/mikelxc/Workarounds-for-ARM-mac ). Using these
>>>> standard instructions, I was able to check many R packages that are
>>>> flagged on CRAN. For example:
>>>> brew install --build-from-source libgit2
>>>> Will make it possible to install gert and git2r. And:
>>>> brew install --build-from-source imagemagick@6
>>>> Will work for 'magick' and:
>>>> brew install protobuf
>>>> For protolite.
>>>> The main bottlenecks are libraries that depend (indirectly) on gcc
>>>> (fortran) or rust. FXCoudert is working on gcc, and for Rust, support
>>>> for apple-arm is available starting rust 1.49, which will be released
>>>> on Jan 1.
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac@r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>
>>>
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org <mailto:R-SIG-Mac@r-project.org>
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> <https://stat.ethz.ch/mailman/listinfo/r-sig-mac>
[[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
