This email is mostly of interest to those that build Mac binaries or want to maintain binary compatibility with CRAN. Also if you are on an Apple Silicon Mac (M1,M2,?) and your macOS is *older* than macOS 14, please read the last paragraph at the bottom.
Our current Mac R release and package builds are targeting macOS 11 (Big Sur) for both Intel and arm64 to offer as wide coverage of users as possible. Unfortunately, Apple has removed hardware support for most Intel Macs from recent macOS versions which means that majority of Intel Mac users cannot upgrade their OS - which is reflected in our estimated macOS version user share and therefore we cannot change the target for x86_64 binaries without abandoning a large fraction of our users.
However, all arm64 (Apple Silicon) Mac hardware is supported by latest macOS versions so there is no practical obstacle for Apple Silicon users to upgrade their macOS. Therefore we are considering moving the minimum target for CRAN R binaries and packages to macOS 14 (Sonoma), because it allows us and packages to leverage several new technologies and tools. To that effect R-devel arm64 builds have been switched to a "sonoma-arm64" build target, with the corresponding repository URL of /bin/macosx/sonoma-arm64/contrib/4.6 (output of contrib.url("", type="binary") in those builds). The binaries will be built with the following setup/settings:
Host OS: macOS 15.7.1 (Sequoia)
Toolchain: Xcode/CLT 26.0, GNU Fortran 14.2 (from CRAN)
SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk
MACOSX_DEPLOYMENT_TARGET=14.0
Accordingly, the recipes binaries are built using the same settings and are available in following repository:
https://mac.r-project.org/bin/darwin23/arm64/
Corresponding nightly R binaries are available as usual at
https://mac.r-project.org/sonoma/last-success/
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. I would also like to hear from any Apple Silicon users that are unable to upgrade to macOS 14 or higher for whatever reason (corporate system management etc.).
Thanks,
Simon
Announcement: R-devel "sonoma-arm64" Mac builds
10 messages · Jeroen Ooms, Peter Dalgaard, Simon Urbanek
1 day later
On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek
<simon.urbanek at 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? 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
On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek <simon.urbanek at 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). It does raise an interesting point, though: macOS 15 is not an issue since you can install all the way to Xcode 26.3 without problems, but macOS 14 (which is our designed target) only runs Xcode 16.2. However, the whole point of moving the target forward was that we upgrade from Xcode 16.2 since that's what we used for the Big Sur build, so sticking with it would defeat the whole purpose. So, would anyone be unhappy if we simply declared macOS 14 as the run-time target, but development needs macOS 15 for the compiler support? It's not ideal, but the only other way would be to deliberately disable C23 support - it's doable, though. Cheers, Simon
On Sat, Dec 13, 2025 at 10:39?PM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek <simon.urbanek at 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? According to otool it is the same
version as before?
otool -L lib/libomp.dylib
/Library/Frameworks/R.framework/Versions/4.6/Resources/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 1292.100.5)
On 14/12/2025, at 12:03 PM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Sat, Dec 13, 2025 at 10:39?PM Simon Urbanek <simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek <simon.urbanek at 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 at R-project.org> wrote:
On 12 Dec 2025, at 08:26, Jeroen Ooms <jeroenooms at 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. Cheers, Simon
otool -L lib/libomp.dylib
/Library/Frameworks/R.framework/Versions/4.6/Resources/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 1292.100.5)
On Sun, Dec 14, 2025 at 12:29?AM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 12:03 PM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Sat, Dec 13, 2025 at 10:39?PM Simon Urbanek <simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek <simon.urbanek at 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 at R-project.org> wrote:
On 12 Dec 2025, at 08:26, Jeroen Ooms <jeroenooms at 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.
Some Intel machines won't go to Sequoia, including this 2019 MB Air, but I suppose that is irrelevant. But Sequoia seems to have messed up the calendar integration with Exchange, which is a bit of a pain, so some might prefer staying on OS 14.x. -pd
On 13 Dec 2025, at 23.39, Simon Urbanek <simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek <simon.urbanek at 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). It does raise an interesting point, though: macOS 15 is not an issue since you can install all the way to Xcode 26.3 without problems, but macOS 14 (which is our designed target) only runs Xcode 16.2. However, the whole point of moving the target forward was that we upgrade from Xcode 16.2 since that's what we used for the Big Sur build, so sticking with it would defeat the whole purpose. So, would anyone be unhappy if we simply declared macOS 14 as the run-time target, but development needs macOS 15 for the compiler support? It's not ideal, but the only other way would be to deliberately disable C23 support - it's doable, though. Cheers, Simon
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
Peter, thanks. There may be a compromise is to disable C23 support in R so it is still compatible with the older Xcode while still being able to use the new compliers. I don?t think there is too much appetite for C23 anyway as people will move the C++20 at best and the C standards don?t really matter (well, C23 is absolutely terrible due to the "bool" mess they created). That may be the best way forward. Cheers, Simon
On 15 Dec 2025, at 11:33, peter dalgaard <pdalgd at gmail.com> wrote: Some Intel machines won't go to Sequoia, including this 2019 MB Air, but I suppose that is irrelevant. But Sequoia seems to have messed up the calendar integration with Exchange, which is a bit of a pain, so some might prefer staying on OS 14.x. -pd
On 13 Dec 2025, at 23.39, Simon Urbanek <simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek <simon.urbanek at 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). It does raise an interesting point, though: macOS 15 is not an issue since you can install all the way to Xcode 26.3 without problems, but macOS 14 (which is our designed target) only runs Xcode 16.2. However, the whole point of moving the target forward was that we upgrade from Xcode 16.2 since that's what we used for the Big Sur build, so sticking with it would defeat the whole purpose. So, would anyone be unhappy if we simply declared macOS 14 as the run-time target, but development needs macOS 15 for the compiler support? It's not ideal, but the only other way would be to deliberately disable C23 support - it's doable, though. Cheers, Simon
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
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 at gmail.com> wrote: On Sun, Dec 14, 2025 at 12:29?AM Simon Urbanek <simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 12:03 PM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Sat, Dec 13, 2025 at 10:39?PM Simon Urbanek <simon.urbanek at r-project.org> wrote:
On 14/12/2025, at 11:24 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: On Fri, Dec 12, 2025 at 3:20?AM Simon Urbanek <simon.urbanek at 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 at R-project.org> wrote:
On 12 Dec 2025, at 08:26, Jeroen Ooms <jeroenooms at 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.
On Mon, Dec 15, 2025 at 12:58?AM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
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).
It seems the issue has disappeared in the latest build of R-devel-arm64.pkg (2025/12/14). We can now build data.table for R-4.6-arm with openmp support on Xcode26.