Hi Dima,
Topic 1: Use of Apple cc for OpenMP.
Dima Pasechnik wrote:
> 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
> ...
> Let's look at the symbols?
> % cc -Xpreprocessor -fopenmp -c t.c -lomp
> ...
> % 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
I can confirm this: Building gettext's msgl-merge.c with the extra option
'-Wp,-fopenmp' produces:
$ nm msgmerge-msgl-merge.o | grep ' U '
...
U ___kmpc_dispatch_deinit
U ___kmpc_dispatch_init_8
U ___kmpc_dispatch_next_8
U ___kmpc_fork_call
...
So, really, theses pragmas appear to be understood by Apple cc.
But the fact remains that these symbols are defined in a library 'libomp'
that is
- not shipped by Apple,
- not mentioned in any documentation on apple.com. [1]
So, if there is a bug in the code generation, you can't turn to Apple
and submit a bug report. It's unsupported functionality.
> 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.
Thanks for explaining. Now that explains why Apple is acting like it does.
Still, developers cannot switch to Grand Central Dispatch for their
portable applications, since libdispatch is not ported to most Linux
platforms. On Debian, for instance, it is not delivered for the x86 and
riscv64 architectures [2].
> 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?
No. What I'm saying is that they don't distinguish a "happens to work"
situation from a "supported functionality situation".
> > 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? :-)
In these systems, the compiler and its run-time libraries come from the same
vendor; therefore the users can by support (e.g. from Red Hat) for the
combination.
Once there was the possibility to use, on Windows, a combination of
- the header files and runtime library from MSVC,
- the upstream clang compiler.
It did work in LLVM versions 9 and 10. In LLVM version 11, it broke: the
compiler started to emit references to some _InterlockedAnd64 symbol
that was not defined in the library. It was unsupported, because neither
Microsoft nor llvm.org was responsible for both.
The same thing can happen with your mix of runtime library from Homebrew
and compiler from Apple, at any time.
Btw, nowadays, Microsoft itself ships the combination of
- the header files and runtime library from MSVC,
- an adapted clang compiler.
So that combination is now supported.
And similarly, on the macOS side, llvm.org is shipping an
LLVM-22.1.8-macOS-ARM64.tar.xz, that contains both clang and libomp.dylib.
So if you use that, you are in a supported situation, and I encourage
everyone to help make sure that GNU tools support this environment.
> 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.
I'm sorry if you feel that your combination of runtime library from Homebrew
and an unsupported Apple cc feature is the "normal way" to do things. If
you want a future-proof environment, you'll need to change that.
Topic 2: Introduction of new OPENMP_CLIBS variable.
> % 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.
You can safely ignore this warning. I'm seeing it in all my projects,
as soon as I use clang. Really, it is not worth changing anything in the
Autotools because of this warning. Clang emits many warnings, and users
can turn them off, one by one, through command-line options. [3]
Bruno
[1] https://www.google.com/search?q=%22libomp%22+site%3Aapple.com
[2] https://packages.debian.org/sid/libswiftlang
[3] https://clang.llvm.org/docs/DiagnosticsReference.html
