Dear all, On Mon, Mar 02, 2026 at 09:44:08AM -0500, Zack Weinberg wrote: > On Sun, Mar 1, 2026, at 11:10 PM, Dima Pasechnik wrote: > > Since a while, Apple clang allows OpenMP (from llvm project, GNU > > OpenMP doesn't work) if one supplies an option "-Xpreprocessor - > > fopenmp". > > I do not have an informed opinion on the "*should* we use this > undocumented mode of Apple clang" issue raised by Florian. I'm not > going to override his objection, though. Please work with him to come > to an agreement.
I can only add that I counted 17 packages in Homebrew (specifically, in https://github.com/Homebrew/homebrew-core, so this does not include any external packages ("taps") using Homebrew infrastructure) using "-Xpreprocessor -fopenmp -lomp". This includes very popular packages, such as OpenBLAS, probably the most popular BLAS/LAPACK open-source implementation out there. From Homebrew alone OpenBLAS was installed close to 300,000 times in the past year, see https://formulae.brew.sh/formula/openblas#default (this is despite Apple having its own freely available compatible BLAS/LAPACK implementation, called Accelerate). Homebrew is the de-facto macOS package manager (supported by Apple, in fact, albeit not too publicly), see https://brew.sh/ Searching through the whole of GitHub brings up almost 12,000 use cases of "-Xpreprocessor -fopenmp". I think this is an overwhelming evidence in favour of Autoconf supporting this feature, documented, or not, by the upstream (i.e. Apple). The community knows how to use it, and uses it, there is no need to be patronising here. By not supporting it Autotools shoot themselves in the foot, forcing users/developers of multi-platform OpenMP-using applications to look elsewhere for a build system supporting this feature out of the box. As I said, Meson supports it out of the box. Cmake supports it too. > > That said: > > ... > > GNU libtool needs a fix for this case ("-Xpreprocessor -fopenmp"), > > too, but this one I've already got (hopefully) accepted: > > https://lists.gnu.org/archive/html/libtool/2026-02/msg00003.html > > Autoconf proper cannot accept a patch to enable use of "-Xpreprocessor > -fopenmp" until it is supported in a *released* version of GNU libtool. > If any changes to Automake are necessary, those also need to happen first. > > Also, no matter what, this is not going into 2.73 (which I'm hoping to > cut a release candidate for *today*). > > Nonetheless, please go ahead and write and *post* your patch, so that > interested people can try it out (along with your libtool patch). > > > A slightly harder to fix issue is that for the linker to work, one has > > to explicitly link with "-lomp". I am inclined to say that a linking > > test should be added into AC_OPENMP, by a call to AC_LINK_IFELSE. > > AC_OPENMP already does a link test; the appropriate change would be, if > the compile test succeeds and the link test fails, to retry that link > test with -lomp added to LIBS (take care to restore the original value > of LIBS afterward). Apologies - I should have looked more carefully in c.m4, before making statements about the linking issue. Great, this makes the job to be done smaller. > > Note that this retry should happen for all values of ac_option, not > just for "-Xpreprocessor -fopenmp". > > > I am not sure how the result of the latter test should be > > communicated, by setting a variable, i.e. setting OPENMP_LIB / > > OPENMP_LIB / OPENMP_LIB to either '' or to '-lomp'? > > Yes, a new AC_SUBST variable. I think it should be called > OPENMP_{_AC_LANG_PREFIX}LIBS, consistent with the existing > OPENMP_{_AC_LANG_PREFIX}FLAGS. A patch is coming. Best, Dima > > zw >
signature.asc
Description: PGP signature
