Hi Bruno, On Sun, Oct 18, 2026 at 11:20:11PM +0200, Bruno Haible wrote: > > Dima Pasechnik wrote in > <https://lists.gnu.org/archive/html/autoconf/2026-10/msg00000.html>: > > > for AC_OPENMP which allows for Apple clang > > to be configured to use OpenMP > > I am opposing this patch, for two reasons: > > 1) This is pointless, because Apple clang *does not* support OpenMP.
This is not the case, and this has been discussed. Please read my reply to you back in March this year, https://lists.gnu.org/archive/html/autoconf/2026-03/msg00022.html I explained how to get code like yours to compile and run, and you seemingly agreed that it's not a problem. Apple's clang does support OpenMP pragmas, but you need to supply the header and the library. With library provided by Homebrew, you'd need % cc foo.c -Xpreprocessor -fopenmp -I$(brew --prefix)/opt/libomp/include -L$(brew --prefix)/opt/libomp/lib -lomp > > But what about the code generation routines for '#pragma omp' in the compiler? They are there, what does tell you otherwise? > 2) The patch makes an incompatible change to the interface: > > The > > + new output variables OPENMP_CLIBS, OPENMP_CXXLIBS, OPENMP_FLIBS, and > > + OPENMP_FCLIBS report any additional library needed for the current > > language. > > + Packages using AC_OPENMP should add the corresponding variable to their > > OpenMP > > + link commands after the object files. > > This is not backward compatible. The Autoconf documentation states that the > link requirement for use of AC_OPENMP is $(OPENMP_CFLAGS). But this is wrong. Why would FOOBAR_CFLAGS control linking? That's a bug, and this patch fixes it. Meson and cmake have zero problems with using OpenMP with Apple clang, it just works. > Adding another > link requirement ($(OPENMP_CLIBS)) for the same thing will break existing > Makefiles. It won't "break makefiles". It might lead to linking errors, yes. Perhaps automake can be taught to add these flags, this would at least cover a lot of use cases. > > And actually, for your attempted case it is not needed, because you wrote: > > > configure_options="CPPFLAGS=-I/opt/homebrew/opt/libomp/include > > LDFLAGS=-L/opt/homebrew/opt/libomp/lib"' > > and $(LDFLAGS) are already used for linking. LDFLAGS here are used to tell the compiler where to look for a library, they don't tell you whether a library is needed to be explicitly supplied. > > So, this patch is wrong on two accounts. If you want OpenMP support > on macOS, just use gcc or upstream clang, not Apple clang. But this doesn't fly. First, gcc won't do, as gcc would use libgomp, and it will potentially start to compete with libomp, linked already in a dependency, with predictable and well-known havoc assured. Second, upstream clang won't fly, at least on Homebrew, where everything is built with Apple's clang. In effect, you are telling the users to stop using autotools for cross-platform OpenMP software. Is this the official GNU policy? As a last resort, we can think of giving the patched macro a new name, make old AC_OPENMP emit a warning, and after a deprecation period rename the patched version AC_OPENMP. Dima
