fix installation using clang-17

[tdhock]

Closes #6622

So far I have just setup CI to test the installation.

Maybe we just need to remove "-fopenmp" somewhere in configure? (this was the fix in vllm-project/vllm#16086)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.10%. Comparing base (6f225f3) to head (8a144cd).
⚠️ Report is 13 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #7318   +/-   ##
=======================================
  Coverage   99.09%   99.10%           
=======================================
  Files          83       84    +1     
  Lines       16092    16126   +34     
=======================================
+ Hits        15947    15981   +34     
  Misses        145      145           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aitap]

Based on R-SIG-Mac posts from earlier this year, I think that clang-17 needs the very latest OpenMP runtime from <https://mac.r-project.org/openmp/>, because the one shipped with R is not compatible with Xcode 16.3+. Then we need to set the compilation flags so that data.table picks up the new /usr/local/lib/libomp.dylib installed by us instead of the -lomp shipped with R. I think it should work if (1) our CI sets the SHLIB_OPENMP_CFLAGS Make macro in ~/.R/Makevars (like a Mac user would do after upgrading Xcode and before recompiling everything from scratch) and (2) data.table checks this macro in the ./configure script, but I haven't seen this exact configuration in the wild. Will try to get it working.

[tdhock]

the github action R-CMD-check / macos-15 is failing with the same error as reported in #6622

 ** testing if installed package can be loaded from temporary location
Error: Error: package or namespace load failed for ‘data.table’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/private/var/folders/sw/lqy3v8g55m76fhwckg439jjm0000gn/T/RtmpzQ41MM/Rinstfe91e48ef29/00LOCK-data.table/00new/data.table/libs/data_table.so':
  dlopen(/private/var/folders/sw/lqy3v8g55m76fhwckg439jjm0000gn/T/RtmpzQ41MM/Rinstfe91e48ef29/00LOCK-data.table/00new/data.table/libs/data_table.so, 0x0006): symbol not found in flat namespace '___kmpc_dispatch_deinit'
Error: Error: loading failed

[tdhock]

I deleted this line because I would like to have the macos-14 build run to completion/sucess as a positive control https://github.com/Rdatatable/data.table/actions/runs/17743367148/job/50422540824 but I still see macos-14 build gets cancelled as soon as macos-15 build fails. is there a way to configure that here? Or is the configuration from master branch overriding somehow?

[aitap]

Installing a custom OpenMP runtime seems to help, but this is somewhat fragile:

• The PKG_* environment variables are set globally for all source packages. We get most of our dependencies as binary packages from CRAN, so it only affects data.table. If there was a standard Make macro like SHLIB_OPENMP_LIBS documented in WRE, we would set it in ~/.R/Makevars when setting up the custom OpenMP runtime so that only packages that need OpenMP would be affected. Unfortunately, there's only SHLIB_OPENMP_CFLAGS/SHLIB_OPENMP_FFLAGS/SHLIB_OPENMP_CXXFLAGS, where the same flags are supposed to be passed to both the compiler and the linker (so SHLIB_OPENMP_LIBS would be counter-productive); only macOS needs different flags.
• Strictly speaking, this setup is not compatible with CRAN binaries. If we try to run a CRAN-built package that uses OpenMP together with our own source build of data.table, it will probably fail. But installing from source takes time and effort, and data.table is the only user of OpenMP during R CMD check, so it works.

[tdhock]

great please add NEWS item

[aitap]

What would you suggest for the text of the news item when the change is mostly not user-visible? "The package is now also tested with Apple clang 17"?

[tdhock]

sure that is fine.
I would disagree about "mostly not user-visible" -- easy installation is a really important user-visible feature.

Should the news item say that the compilation works with homebrew clang-17? (which is apparently different from xcode clang)

I have a response actions/runner-images#13012 (comment) from the github actions macos-15 image dev, who says: Clang is available as a part of Xcode and separately as an independent application instance installed from the Homebrew. Your #6622 referring to clang-17 which is not a part of our default config by the way. That means that one of your steps changes the default setup somehow.

[tdhock]

to finalize this pr, we should revert the deletions I made in the R CMD check CI config.
But I would suggest keeping the macos-15 build that I added (and changing it to macos-latest), is that OK?

[aitap]

easy installation is a really important user-visible feature

Then we might want to add a configure test in addition to the current CI fixes. When running macOS and $(R CMD config CC) --version says Apple clang 17, check whether /usr/local/lib/libomp.dylib exists. If it does exist, use it instead of -lomp. If not, suggest installing the OpenMP runtime from https://mac.r-project.org/openmp and try using -lomp as before.

The risk is breaking installation from source on systems with Apple clang 17 where -lomp works but /usr/local/lib/libomp.dylib is broken. This sounds weird but not impossible in theory. Another risk is breaking installation on CRAN builders in the future, when they update to Xcode ≥16.0 and a new version of bundled libomp (so that -lomp would be sufficient).

Your #6622 referring to clang-17 which is not a part of our default config by the way.

This is technically correct (there's probably no binary named clang-17 in the macos-15 image), but doesn't contradict what's stated in #6622: the C compiler we're having problems with is Apple clang version 17 from Xcode 16.4, default in macos-15.

[aitap]

I found a test that distinguishes between working and broken OpenMP runtime situations on macOS: it's #pragma omp schedule(dynamic). Without the correct OpenMP runtime on Xcode 16.4, the resulting shared library fails to load due to missing ___kmpc_dispatch_deinit. This can be used in the configure test (à la #6642 but less intrusive), letting us be more confident about setting PKG_LIBS=/usr/local/lib/libomp.dylib for Apple clang 17. Give me some more time and we'll have a proper fix and a NEWS item here.

[tdhock]

wow excellent job thanks Ivan!

[github-actions]

No obvious timing issues in HEAD=fix-macos-15-image

Generated via commit 8a144cd

Download link for the artifact containing the test results: ↓ atime-results.zip

Task	Duration
R setup and installing dependencies	2 minutes and 50 seconds
Installing different package versions	43 seconds
Running and plotting the test cases	2 minutes and 56 seconds

[jeroen]

Could you also add a runner with macos-15-intel to the matrix? That way we also test on x86_64, see https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/

[tdhock]

Could you also add a runner with macos-15-intel to the matrix? That way we also test on x86_64, see https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/

before this pr there were no macos github actions checks, so adding 3 seems like an unusually large move.

I would propose to add either 1 macos-15 or 2 macos (macos-15 for arm and macos-15-intel for x86_64).

[aitap]

It turns out that our caching scheme was in conflict with having macOS 15 running on both Intel and ARM.

Coincidentally, this enables OpenMP support on FreeBSD. Previously, the configure script only tried it for macOS and Linux; now it's tested everywhere, with extra cases on macOS.

Do we want to fail CI if data.table installs without OpenMP support on systems where it should be supported?

Would it be feasible for someone to test this with a Homebrew installation of R?

[tdhock]

Do we want to fail CI if data.table installs without OpenMP support on systems where it should be supported?

No, I think it would be better to install single core. Anyway we dont see large speedups when adding cores, for many common operations https://github.com/Anirban166/data.table.threads

[jeroen]

FYI, data.table builds on r-universe are broken because of this: http://cran.dev/data.table/buildlog

[jangorecki]

I think this should go into NOTES section of news.md

[aitap]

@jeroen, is there a way to get a CRAN-compatible toolchain on the macos-15 runner? Otherwise macOS builds produced on R-Universe using this runner should (and will, after this PR) have OpenMP disabled: the new compiler requires a new OpenMP runtime, but the new OpenMP runtime is incompatible with the one shipped with base R (and presumably used by other CRAN binaries).

[jeroen]

I'm not sure. Could you ask this on the r-sig-mac mailing list? I'll try to update the headers to the latest from https://mac.r-project.org/openmp/ but IIUC they need to ship a newer openmp dylib with base R?