Hi Bruno, On Mon, Oct 19, 2026 at 01:04:05PM +0200, Bruno Haible wrote: > Topic 1: Use of Apple cc for OpenMP. [...] > 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.
What exactly do you mean by "extra option"? Adding it to OPENMP_CFLAGS? (and the appropriate -l and -L somewhere?) Does one need to explicitly call `./configure --enable-openmp` as well? (I'd like to update Homebrew gettext formula to use OpenMP) > 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. Have you ever dealt with submitting bug reports to Apple (or to big commercial companies in general)? It doesn't seem possible to even get an acknowledgement that there is anything wrong with their products. E.g. there is a reproducible libpthread macOS bug floating around on the net for almost a year. I had a go at submitting it to Apple lately. See https://feedbackassistant.apple.com/feedback/25195692 (I gather it's not public - but perhaps you know somebody at Apple :-)) report id FB25195692, with subject "libsystem_pthread POSIX thread cancellation bug" You can look at the bug details on https://github.com/orgs/Homebrew/discussions/7132 in their full glory (including the attitude of people invested with Apple products more than us :-)).. Anyway, if there is a bug in code generation of Apple clang, the way to go is to the LLVM clang project, as Apple closely follows LLVM branches, and is a contributor to the LLVM project. See https://github.com/swiftlang/llvm-project This way we were able to eventually sort out an Apple clang floating point bug. https://github.com/sagemath/sage/issues/22799 [...] > > 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. And where the users should go if something is wrong at the level of hardware support for their GNU/Linux/*BSD software? Nowhere, just nowhere. (well, reverse engineering at best). [...] > 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. For Apple it's a 3rd party tool, and given their hostility to alternative 3rd party toolchains (cf. the gcc blocks case) I won't be too hopeful here. > > > 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. That's capitalism in its full glory. Woe is me. ;-) > 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] We still need to support `-Xpreprocessor -fopenmp` thing, no? Because it might be in OPENMP_CFLAGS provided by the user. If not, then we can amend the patch you propose to not introduce the new variables, live with warnings (better - suppress this particular one if possible, because once in a while we saw Apple clangs giving up after a pre-set number of warnings popped up), and stuff the needed by the linker, and inappropriate for the compiler, flags into the existing OPENMP_CFLAGS and its variants. Dima > [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
signature.asc
Description: PGP signature
