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 <[email protected]> wrote: > > On Sun, Dec 14, 2025 at 12:29 AM Simon Urbanek > <[email protected]> wrote: >> >> >> >>> On 14/12/2025, at 12:03 PM, Jeroen Ooms <[email protected]> wrote: >>> >>> On Sat, Dec 13, 2025 at 10:39 PM 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). >>> >>> 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 <[email protected]> >>> wrote: >>> >>>> On 12 Dec 2025, at 08:26, Jeroen Ooms <[email protected]> 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. > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
