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 <[email protected]> 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 <[email protected]> wrote: >> >> >> >>> On 14/12/2025, at 11:24 AM, Jeroen Ooms <[email protected]> wrote: >>> >>> On Fri, Dec 12, 2025 at 3:20 AM Simon Urbanek >>> <[email protected]> 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 >> [email protected] >> 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: [email protected] Priv: [email protected] > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
