Hi Bruno, On Mon, Oct 19, 2026 at 02:46:56AM +0200, Bruno Haible wrote: > > > 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?
Well, you somehow seem to assume that Homebrew, or R Project, are run by
complete
amateurs, who can't tell whether the code gets a parallelisation speedup, or
not?
Core Homebrew provides such popular OpenMP-using projects as OpenBLAS and
SuiteSparse, fftw, pytorch, with OpenMP support (and about 70
other OpenMP-using, i.e. with real OpenMP code in them, projects).
And, yes, at least OpenBLAS and SuiteSparse are built with cmake,
despite having been started and still being autotools-using projects. And
you know why? Because GNU hasn't been accommodating in supporting
libomp with Apple clang...
> > 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?
As far as I can tell, gettext on Homebrew is not using OpenMP.
And it's big (but I can try to build it with OpenMP support and see how
much faster it gets, provided there are speed benchmarks available).
So instead, here comes a simple illustration, with
#include <omp.h>
#include <stdio.h>
int main() {
int c=0;
#pragma omp parallel
{
c++;
}
printf("%d times\n", c);
return 0;}
% uname -a
Darwin debruijn.local 27.0.0 Darwin Kernel Version 27.0.0: Tue Aug 11 21:05:48
PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T6041 arm64
% cc -v
Apple clang version 21.0.0 (clang-2100.3.34.2)
Target: arm64-apple-darwin27.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
% export OM=$(brew --prefix)/opt/libomp
% export CPATH=$OM/include
% export LIBRARY_PATH=$OM/lib
% export OMP_NUM_THREADS=42
% cc -Xpreprocessor -fopenmp t.c -lomp
% ./a.out
42 times
And, well, a.out is linked with libomp, obviously:
% otool -L a.out
a.out:
/opt/homebrew/opt/libomp/lib/libomp.dylib (compatibility version 5.0.0,
current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1359.0.0)
Let's look at the symbols?
% cc -Xpreprocessor -fopenmp -c t.c -lomp
clang: warning: -lomp: 'linker' input unused [-Wunused-command-line-argument]
See, that would be fun to fight compiler warnings here, as it's unhappy
about linker food being shoved into its compiler mouse, and that's
another reason why OPENMP_CFLAGS should not be polluted with linker input.
% nm t.o
U ___kmpc_fork_call
0000000000000000 T _main
0000000000000068 t _main.omp_outlined
U _printf
00000000000000a7 s l_.str
00000000000000b8 s l___unnamed_1
0000000000000090 s l___unnamed_2
0000000000000000 t ltmp0
0000000000000090 s ltmp1
00000000000000b8 s ltmp2
00000000000000d0 s ltmp3
> 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.
The vendor in this case pushes users towards Apple-only solution,
Grand Central Dispatch, which is well-integrated into the OS.
OpenMP would be a direct competitor, if shipped along with the native
toolchain. They still keep the OpenMP frontend and driver in the
compilers.
Amusingly, if you build gcc without OpenMP support, it still does the
same, and you can make it build and run OpenMP code, as long as you link
with libomp (or, probably, with libgomp, just as well).
>
> > > 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
See above - clang is not happy about linker commands supplied to the
compiler. And rightly so...
> > > 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.
R Project is using OpenMP with Apple clang without Homebrew. Anyway, I
can't buy your argument, as it is conditional on people not doing things
in a normal way - that's what you're telling us now.
> > 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)
Who knows whether it'd work 100% correctly on macOS. Apple clang isn't
fully open-source.
>
> > 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'").
Millions of people are using Linux and *BSDs, and autotools, on systems which
are only meant to
support Windows, why don't you object to it? :-)
This way, gettext must only be used on macOS...
I am merely proposing that autotools, at last, gets a normal way to use
OpenMP with Apple clang; this is well-tested usage, a daily driver of
hundreds of thousands of Homebrew and R Project users, etc etc.
Dima
signature.asc
Description: PGP signature
