Re: fixing AC_OPENMP for Apple clang

--ebndVdALxYhbdn4i
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 02, 2026 at 10:14:10AM -0600, Dima Pasechnik wrote:
>=20
> On Mon, Mar 02, 2026 at 09:44:08AM -0500, Zack Weinberg wrote:
> > On Sun, Mar 1, 2026, at 11:10 PM, Dima Pasechnik wrote:
> > > Since a while, Apple clang allows OpenMP (from llvm project, GNU
> > > OpenMP doesn't work) if one supplies an option "-Xpreprocessor -
> > > fopenmp".
> >=20
[...]
> > Nonetheless, please go ahead and write and *post* your patch, so that
> > interested people can try it out (along with your libtool patch).
> >=20
> > > A slightly harder to fix issue is that for the linker to work, one has
> > > to explicitly link with "-lomp". I am inclined to say that a linking
> > > test should be added into AC_OPENMP, by a call to AC_LINK_IFELSE.
> >=20
> > AC_OPENMP already does a link test; the appropriate change would be, if
> > the compile test succeeds and the link test fails, to retry that link
> > test with -lomp added to LIBS (take care to restore the original value
> > of LIBS afterward).
>=20
> Apologies - I should have looked more carefully in c.m4,=20
> before making statements about the linking issue.
> Great, this makes the job to be done smaller.
>=20
> >=20
> > Note that this retry should happen for all values of ac_option, not
> > just for "-Xpreprocessor -fopenmp".
> >=20
> > > I am not sure how the result of the latter test should be
> > > communicated, by setting a variable, i.e. setting OPENMP_LIB /
> > > OPENMP_LIB / OPENMP_LIB to either '' or to '-lomp'?
> >=20
> > Yes, a new AC_SUBST variable.  I think it should be called
> > OPENMP_{_AC_LANG_PREFIX}LIBS, consistent with the existing
> > OPENMP_{_AC_LANG_PREFIX}FLAGS.
>=20
> A patch is coming.

What I am confused about is that there seems to be no way in the current
AC_OPENMP to tell whether the call was a success. Note that there is
case in the macro where no flags are needed. Then the test may succeed,
or may fail.
To quote the manual:

"OPENMP_CFLAGS is set to empty if the compiler already supports OpenMP,
if it has no way to activate OpenMP support, or if the user rejects OpenMP =
support by invoking =E2=80=98configure=E2=80=99 with the =E2=80=98--disable=
-openmp=E2=80=99 option."
[...]
This macro caches its result in the ac_cv_prog_c_openmp, ac_cv_prog_cxx_ope=
nmp, ac_cv_prog_f77_openmp,
or ac_cv_prog_fc_openmp variable, depending on the current language.

Only by reading the macro code, or by doing a trial run and looking at
config.log, one can conclude that to test for failure
(say, with current language C)
one has to test ac_cv_prog_c_openmp for being equal to 'unsupported'.

Should the manual be more clear on this?

Best,
Dima


--ebndVdALxYhbdn4i
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQFPBAABCAA5FiEEJVdDnfI7raAa4RJxoksLHjfJBTEFAmnQjo4bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEKJLCx43yQUxd8MH+wUrUzfbLToZKhvVoDI/
HuiJdORJFCrx7G/8LV3ulpN7ehCbsp8p5+Oz2rwNV41i4aFiPkLkxF4Z+YLEXy90
wFPQahBC0qd3N9WxAfWo8b+W5Ja2yl3yXqyKW0JajmiRy92SHGQ/qMY5+NloJVVN
lyiLynti0mc8v0JzwoaJN4NqLZTDzSlCUnDTLZm6p4GCIUjJ8owkmX9BfFSZawoL
SJ7DC7kSj5IYZWhKErGQluu6NkdPwBkVZkd/nkAPgwVWtaq4MhJtg3epWzxLXEqm
cM2RmaIZE2AmHx0Bg68m7eD+n8ejnZUUSdbPofuUYLrKAXmTLLFubmsv+Bfa3dwH
yys=
=UVYJ
-----END PGP SIGNATURE-----

--ebndVdALxYhbdn4i--