Bill, Apple does not support OpenMP in their toolchain, and OpenMP is disabled in XCode. Simon and others rely on the fact that the toolchain is built on top of Clang and thus the OpenMP support can be patched in. However, as far as Apple goes all this is undocumented behavior and subject to change at any time. So I wouldn�t expect things improving any time soon.
Best, Taras ________________________________ From: R-SIG-Mac <r-sig-mac-boun...@r-project.org> on behalf of bill+rsig...@8pawexpress.com <bill+rsig...@8pawexpress.com> Sent: 23 April 2025 15:33 To: Simon Urbanek <simon.urba...@r-project.org> Cc: r-mac <r-sig-mac@r-project.org> Subject: Re: [R-SIG-Mac] openmp and xcode Simon, Long time fan :-) Downgrading to 16.2 worked. I�m baffled why a /minor/ release change was sufficient to make it work, I had assumed that the major different (14 to 16) would have been more responsible. I guess they aren�t using semver? Thank you for that advice, I�m on 16.2 now. I found 16.2 at https://xcodereleases.com. While the release notes for 16.3 are detailed (much of it beyond my familiarity), I don�t see anything clear that would indicate to me that 16.2 would work and 16.3 would not. (For instance, no mention of OMP or OpenMP.) Besides you having a running familiarity with the topic of R compilation on macos in general, is there something that should have clued me in to suggest 16.2? (Quick background: I�ve been on Linux and FOSS since 1993, when floppies were the rage. I�ve used R on Windows and Linux since 2011. I started on MacOS and therefore R on MacOS in Dec 2024. I�m definitely a freshman on campus here, constantly befuddled by some of the nuanced differences in macos.) /will have to do a bit of legwork to make sure it works as it is not entirely trivial to do that correctly/ My legwork has been educating. Can we ease the burden slightly? The docs are clear about XCode 14.2/14.3, but since that version isn�t supported on Sequoia there is no hint at a path forward other than to find this mailing list and ask (you). The |/openmp/| portion of the website discusses downloading one of 26 versions of |openmp-*.tar.gz|; it seems risky to me that it would be wise to use a version of OpenMP that is different than what R is linked against, ergo /�chaos when more OMP run-times get loaded into one process�/. Perhaps I�m making a hasty assumption here � the R packaging includes libraries for OMP, BLAS, and LAPACK, to name a few, and none of their headers are included. I had assumed that including headers for all of them would be useful, but I think you�re saying that you�d rather make devs learn some of the nuances of building R against those libraries before writing packages that link against them, is that right? How about two alternatives: 1. Update documentation on https://mac.r-project.com to include a note about 16.3, perhaps as simple as �16.3 is known to break some packages�. This may be hampered if the �16.2� downgrade works for |data.table| but other packages would require perhaps �15.*� or �14.*� to compile. 2. Provide a tarball that contains the header files for libraries against which a particular version of R is compiled. For instance, �R-headers-4.4.tar.gz� would include the OMP headers and possibly (I�m stretching) headers for BLAS and LAPACK. It would be an optional download that is updated when the linked libraries are updated, probably not at every R release. Having a tarball of /just/ headers helps keep the headers the same version as the linked |libomp|, and still requires some legwork for the devs. I think this encourages safer version compatibility, and requires the dev to work harder if they need something further. Thoughts? Last oh-btw: you said you are using CLT 16.2, is that available from Apple, are you using homebrew to install it, or something else? I�m not yet tight on disk space, but I don�t use the rest of XCode so it seems I�m wasting some space. Thanks, Bill On 4/22/25 22:31, Simon Urbanek wrote: > Bill, > > the libomp.dylib inside R is there solely for the CRAN binaries to make sure > that package binaries on CRAN can use the correct OpenMP runtime. Is it not > intended to be used outside of that setup. > > That is also why we don�t ship the headers as anyone compiling from sources > will have to do a bit of legwork to make sure it works as it is not entirely > trivial to do that correctly. The CRAN build machines are setup such that it > "just works" to make it easy on package maintainers. However, there are lot > of issues/moving parts when building OpenMP-enabled code yourself (as you > found out), so it is not encouraged unless you are very familiar with the > issues (correct run-time and complier match-up etc.). > > That said, Xcode 16.3 is a big jump in the clang versions (from 17 to 19) so > I would not recommend it just yet - have you tried Xcode 16.2? I tried to > reproduce your problem and it worked just fine with Xcode 16.2 (CLT 16.2 to > be precise and my corresponding OpenMP run-time from LLVM 17.0.6). Xcode 16.2 > is supported on all macOS versions (and what the arm64 R builds are moving > to) so I would suggest trying that first. (I didn't have CLT 16.3 installed > yet, so I�ll have to wait for a quiet minute to see if that�s really what > breaks.) > > Cheers, > Simon > > >> On 23 Apr 2025, at 02:21,bill+rsig...@8pawexpress.com wrote: >> >> If the CRAN R installation for macos includes |libomp.dylib|, is there a >> reason it does not include the paired |./include/omp*.h| files as well? It�s >> just three, they�re small, and it seems a reasonable step to making >> building packages that use OpenMP more direct. >> >> Background: I�ve been having some difficulty compiling |data.table| (dev) on >> my MBP (M4, 15.4.1, R-4.4.3), due to an error (I do not assume it�s this >> package, I�ve had trouble with other packages too). >> >> |symbol not found in flat namespace '___kmpc_dispatch_deinit' | >> >> When troubleshooting this, I�ve verified that I have Xcode, but it is >> version 16.3, well past the 14.3 used for R-4.4.3. Sleuthing some more, I >> realized that it�s an easy mistake to update the >> |/usr/local/lib/libomp.dylib| file to be a different version than what is >> distributed in CRAN�s R. I don�t see an easy way to change version within >> XCode, and when I tried installing XCode-14.3 it says my OS does not support >> that (old) version. (Even with gfortran 12.2, I can�t fix that error, but >> that�s a different subject.) >> >> I recognize the challenge in distributing binaries for multiple versions of >> macos and xcode. I believe R-4.5 is still being built on XCode-14.3, which >> begs another question of if/when XCode updates are planned for R binaries >> and CRAN. (Big topic, I understand, I did not find a recent discussion. My >> apologies if I missed something.) >> >> Thanks, >> Bill >> >> ​ >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac@r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> ​ [[alternative HTML version deleted]] _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac [[alternative HTML version deleted]]
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
