Hi Dima,
> > 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.
At that time, we concentrated on the include file and the library.
Even if that was solved (by use of Homebrew, as you say), what about
the code generation routines for '#pragma omp' in the compiler?
> They are there, what does tell you otherwise?
You can try to see what code gets generated for OpenMP code,
such as gettext-1.0/gettext-tools/src/msgl-merge.c (from the gettext-1.0
release). When this file gets compiled to a .o file, and you do an
"nm msgl-merge.o", which OpenMP or multithread symbols does it reference?
- If none, this would tell us that the compiler "supports" these pragmas
by ignoring them.
- If it introduces such symbol references, do they match the symbols
defined in your libomp from Homebrew?
But even in that latter case, I don't think it would be a wise decision
for any project (be it gettext, be it SAGE, or any other) to rely on
compiler internals that the compiler vendor makes a lot of effort
to make unusable.
> > 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.
Nope, that's not a bug.
CFLAGS are used both during compilation (.c -> .o) and during linking.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.73/html_node/Preset-Output-Variables.html
> > 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.
That's what I mean: It would lead to link errors, requiring the
maintainer to adjust the Makefile.am.
> 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.
Yes, this is how one can avoid making backwards-incompatible changes
to Autoconf macros.
> > > 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.
OK, right. $(OPENMP_CFLAGS) would contain '-lomp', and $(LDFLAGS) would
contain the -L option required for finding libomp.
> > 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.
I can't buy this argument. If someone does not use Homebrew, or
does not use 'libomp' from Homebrew, there is no conflict; they
can use gcc with its libgomp.
> Second, upstream clang won't fly, at least on Homebrew, where everything is
> built with Apple's clang.
Well, if Homebrew doesn't fly, people can still take the clang
binaries from upstream:
https://github.com/llvm/llvm-project/releases/tag/llvmorg-22.1.8
(look for LLVM-22.1.8-macOS-ARM64.tar.xz)
> In effect, you are telling the users to stop using autotools for
> cross-platform OpenMP software.
No, by far not. (I am using OpenMP in GNU gettext, as stated above.)
What I'm worried about is that Autoconf gets additional complexity that,
seen in the big picture, is pointless because unsupported by the compiler
vendor. The build environment that you are proposing a combination of
- omp.h and libomp from Homebrew,
- unsupported compiler features ('#pragma omp' in a compiler that reports
"error: unsupported option '-fopenmp'").
Bruno
