ERROR: Error building `NNlib`:
┌ Warning: Platform `arm64-apple-darwin21.2.0` is not an officially supported platform
└ # BinaryProvider ~/.julia/packages/BinaryProvider/U2dKK/src/PlatformNames.jl:450
ERROR: LoadError: KeyError: key "unknown" not found
How to solve the issue or at least fix the environment?
Running Julia natively on MacOS on ARM chips, such as the M1, currently has only "Tier 3" support. This means
Tier 3: Julia may or may not build. If it does, it is unlikely to pass tests. Binaries may be available in some cases. When they are, they should be considered experimental. Ongoing support is dependent on community efforts.
For individual packages, if they have binary dependencies, it depends on how those are provided. If they are provided by the modern BinaryBuilder.jl / Yggdrasil.jl infrastructure, those binary dependencies may be available for arm64-apple-darwin; if they use some older system for binary dependencies, that will almost certainly not support Mac on ARM.
In the meanwhile, you might instead use the macOS x86 (Intel or Rosetta) release from https://julialang.org/downloads/ for production work; this should cause both Julia itself and any package binary dependencies to run using x86 binaries via Rosetta, and should generally work without error on M1.
Related
I am trying to use the Twitter.jl package locally on my M1 Mac. However, when I try to install it, I get:
ERROR: Error building `DecFP`:
┌ Warning: Platform `arm64-apple-darwin21.2.0` is not an officially supported platform
└ # BinaryProvider ~/.julia/packages/BinaryProvider/U2dKK/src/PlatformNames.jl:450
ERROR: LoadError: KeyError: key "unknown" not found
DecFP looks like it's an up to date Julia package so I am not sure what the issue would be in this case.
I would like to get a general set of steps to resolve issues like this since I know this package isn't the only one that will have installation issues so hopefully this can be used to help others who have similar issues.
The issue is that Twitter.jl is pulling an old version of OAuth.jl which doesn't work on the M1. I have opened a PR so it pulls a newer version and it should work.
About these cases in general the steps are identifying what package is using BinaryProvider, in this case it's an old MbedTLS that was pulled by an old OAuth. The solutions are, if there is a newer version, change the compat bounds, and if there isn't then one has to build the needed binary using BinaryBuilder.jl and change the dependent packages to use it.
In most cases just opening an issue in github should be enough :).
When I install.package() in R on a Windows machine, the package downloads from CRAN and installs. When I do the same on a Linux box, the package usually has to compile (at least, I assume that's what going with all those g++ lines that scroll past).
Why is the package installation method different on Windows?
Other questions and their answers make it clear that using different methods and repositories for Linux particularly, enables users to get more/different packages (particularly using the cran2deb repository). My question is more theoretical in nature: why is the default choice in Windows to download precompiled (binary?) packages whereas the default in Linux seems to be to compile packages from source?
Or to put it another way (based on Dirk's assertion in the second link above), why doesn't CRAN offer binary packages for Unix-type operating systems?
In general, Windows binaries will work on all versions of Windows.
Ditto for the key / current versions of MacOS: the provided binaries work.
Linux, sadly, is more complicated because the different distros lay things out differently. Something I build on Ubuntu or Debian (or, more specifically, a particular release version thereof) may not even work on other releases of the same distro, let alone other distro. In some cases you can get binaries. At some point I (co-)owned a build service for all of CRAN, but it died/broke. All doable with effort, but ... some effort.
So from source it is. That use to be the standard anyway which "Unix" was a catch-all phrase covering SunOS/Solaris, AIX, *BSD, SGI and on and on. Often even with different processors. So source.
There have been attempts to provide 'universal binaries': flatpack and snap are two more recent examples. And then there is of course Docker.
Having used Rtools for a while on R v3.3.3 and 64bit Win10, I suddenly faced the following error when trying to locally install, i.e., compile_dll(pkg = "...", quiet = FALSE) or
load_all(pkg = "...") any package via devtools:
*** fatal error - cygheap base mismatch detected
and the following suggestion in the error output:
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
None of the suggested error handling brought a solution. The concerned library cygwin1.dll was indeed only present as part of Rtools (i.e., in the Rtools folder itself).
Found that this was related to a recent Windows update, namely the 2017-10 Security Update for Adobe Flash Player for Windows 10 Version 1703 for x64-based Systems (KB4049179). Undoing this update under Settings/Updates and Security/... solved the issue. I would nevertheless like to know how exactly this problem arose. Beware that there are other potential issues between Rtools and Cygwin, such as "version collisions of fundamental Cygwin libraries" as described by https://www.r-bloggers.com/rtools-and-cygwin-on-ms-windows/ , but they were seemingly not related to the described problem. Also beware that any automatic Windows 10 updates can only be undone within a month of their installation.
When submitting a package to CRAN, how can one get the resulting binaries for Windows and Mac OSX to take advantage of OpenMP?
i.e., what make or compiler hooks do the CRAN machines look for to build for OpenMP code?
Unix source
R has good OpenMP support under unix. Just include the ifdef _OPENMP. (users must download package source and compile packages on their machine).
OS X binaries
Since mid-2018, R for OS X is compiled using clang, with a custom clang giving OpenMP support. Binary packages which take advantage of OpenMP (e.g. OpenMx) run in parallel. Source compilation is eased by the compiler installer provided at CRAN toolshttps://cran.r-project.org/bin/macosx/tools/clang-6.0.0.pkg
Using other non-CRAN compilers (e.g. homebrew) is strongly advised against.
Windows binaries
As of 2019, the windows toolchain supports OpenMP and pthreads, but it's slow and not enabled by default. Comments indicate this might change.
Refs
https://cran.r-project.org/doc/manuals/R-exts.html#OpenMP-support
As of R 3.5.3 manual:
Apple builds of clang on macOS currently have no OpenMP support, but
CRAN binary packages are built with a clang-based toolchain which
supports OpenMP.
http://www.openmp.org/resources/openmp-compilers-tools gives some idea
of what compilers support what versions.
Source-based installs of CRAN packages for most MacOS users will fail and/or not have openmp, unless they have installed, e.g. via homebrew, clang with openmp support. The method for doing evolves, so search for recent posts with terms like "homebrew clang openmp makevars R CRAN".
When I run the simple profiling test case given in the Julia docs, my Julia kernel invariably dies regardless of environment. I've tried julia.exe, JuliaStudio, and Sublime Text with IJulia. I'm running a fresh install (via the standard 64-bit Windows installer) of version 0.3.0 on Windows 8.
Other components of Julia appear to be working without a hitch. What might be the issue?
This is a known bug in Julia 0.3.0, and will be fixed in the upcoming Julia 0.3.1