[R-SIG-Mac] Announcement: R-devel "sonoma-arm64" Mac builds

Simon Urbanek @|mon@urb@nek @end|ng |rom R-project@org
Mon Dec 15 01:57:56 CET 2025


Jeroen,

I have no trouble with data.table, are you sure you are using the latest R-devel? It does have that symbol:

$ nm /Library/Frameworks/R.framework/Resources/lib/libomp.dylib| grep deinit
0000000000068b0c T ___kmp_hidden_helper_threads_deinitz_release
0000000000068af4 T ___kmp_hidden_helper_threads_deinitz_wait
0000000000051c64 T ___kmpc_dispatch_deinit

(FWIW note that the x86_64 build is still big-sur and it won’t change, only the arm64 builds are updated).

Cheers,
Simon


> On 15 Dec 2025, at 03:49, Jeroen Ooms <jeroenooms using gmail.com> wrote:
> 
> On Sun, Dec 14, 2025 at 12:29 AM Simon Urbanek
> <simon.urbanek using r-project.org> wrote:
>> 
>> 
>> 
>>> On 14/12/2025, at 12:03 PM, Jeroen Ooms <jeroenooms using gmail.com> wrote:
>>> 
>>> On Sat, Dec 13, 2025 at 10:39 PM Simon Urbanek
>>> <simon.urbanek using r-project.org> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms using gmail.com> wrote:
>>>>> 
>>>>> On Fri, Dec 12, 2025 at 3:20 AM Simon Urbanek
>>>>> <simon.urbanek using r-project.org> wrote:
>>>>> 
>>>>>> The goal is to remove the existing big-sur-arm64 R-devel binaries in favor of the sonoma-arm64 R-devel build. Since we are still far away from the R-devel release, all this is considered experimental and may change in the future (possibly Fortran upgrade is in the cards), but given that this is not a minor change, I want to give others the opportunity to test the new setup and comment as appropriate.
>>>>> 
>>>>> Thanks. Some quick observations:
>>>>> 
>>>>> The x86_64 build of r-devel on https://mac.r-project.org/ is almost 2 months old?
>>>>> 
>>>> 
>>>> Should be fixed now.
>>>> 
>>>> 
>>>>> On arm64, using the latest R-devel-arm64.pkg on a machine with macOS 15 and Xcode_16.2, I get the following error for all packages with compiled C code:
>>>>> 
>>>>> error: invalid value 'gnu23' in '-std=gnu23'
>>>>> note: use 'c2x' for 'Working Draft for ISO C2x' standard
>>>>> note: use 'gnu2x' for 'Working Draft for ISO C2x with GNU extensions' standard
>>>>> 
>>>> 
>>>> 
>>>> That is expected, you'll need at least Xcode 16.3 since 16.2 is LLVM 17 while 16.3 is LLVM 19 which, as has been discussed at length, was a big breaking jump. As noted, what is actually used is Xcode 26.x so that would be recommended (albeit not required).
>>> 
>>> The reason we were using 16.2 is that newer xcode versions still do
>>> not seem to work with the libomp.dylib included with base R. Has
>>> libomp.dylib been updated yet?
>> 
>> 
>> Yes, it matches the Xcode - as noted:
>> 
>> 
>>> On 12/12/2025, at 4:25 PM, Simon Urbanek <simon.urbanek using R-project.org> wrote:
>>> 
>>>> On 12 Dec 2025, at 08:26, Jeroen Ooms <jeroenooms using gmail.com> wrote:
>>>> [...]
>>>> Also It would be interesting to know which version of libomp.dylib will be included with R-macos 4.6 :)
>>>> 
>>> 
>>> LLVM 19.1.5 to match current Xcode 26.x, i.e. https://mac.r-project.org/openmp/openmp-19.1.5-darwin20-Release.tar.gz
>>> 
>> 
>> 
>> 
>> Again, that was the point of the tool upgrade :).
>> 
>> 
>> 
>>> According to otool it is the same version as before?
>>> 
>> 
>> 
>> otool shows the API version as declared by Intel OpenMP, but the LLVM team has never updated it despite breaking changes, unfortunately :/. It's really annoying since it means it is very hard to determine which LLVM it came from - even internally all of the them declare the same version 5.0.20140926 and API version 5.0.201611 - both being almost 10 years out of date.
> 
> Are you able to build e.g. data.table with OpenMP support with this
> new toolchain? I am still getting the linking error that we see with
> R-4.5 on MacOS-15, even with the newer libomp.dylib : symbol not found
> in flat namespace '___kmpc_dispatch_deinit'
> 
> See log: https://github.com/r-universe/rdatatable/actions/runs/20198940208/job/57994421244
> 
> I thought that the reason was that libomp.dylib included with R was
> too old, but maybe the diagnosis is incorrect.
> 



More information about the R-SIG-Mac mailing list