Re: [PATCH v2 0/1] libgomp: Fix gfortran detection when program is found via PATH

Thomas Schwinge via Sourceware Forge <[email protected]> Fri, 10 Jul 2026 08:04:44 +0000
Newsgroups gmane.comp.gcc.patches,gmane.comp.gcc.fortran
Message-ID <bmm.hk9b008oow.gcc.gcc.tschwinge.172.6635.CMT@forge-stage.sourceware.org>
@Peter0x44 wrote in https://forge.sourceware.org/gcc/gcc-TEST/pulls/172#issue=
-415:
> The gfortran detection logic in libgomp's configure uses "test -x" to check=
 whether the $GFORTRAN program is executable. However, "test -x" only succeed=
s for absolute or relative paths that name an existing file; it fails for bar=
e program names (e.g. "x86_64-w64-mingw32-gfortran") that are found via $PATH=
 lookup.

The latter is -- in my current understanding -- an invalid assumption: `GFORT=
RAN` is passed into libgomp `configure` via the top-level build system's `GFO=
RTRAN_FOR_TARGET=3D$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/gcc/gfortran -B$$r/=
$(HOST_SUBDIR)/gcc/`, and `$$r/$(HOST_SUBDIR)/gcc/gfortran` always an absolut=
e path, via `` r=3D`${PWD_COMMAND}` ``.  It should never be found "via $PATH =
lookup".

How are you `configure`ing your cross-compiler, could it be that it doesn't (=
effectively) include `--enable-languages=3Dfortran`?  Because, in that case, =
you'd get: `GFORTRAN_FOR_TARGET=3D$(STAGE_CC_WRAPPER) [TARGET]-gfortran`, and=
 with that:

> This causes FC to be incorrectly set to "no" in cross-compilation environme=
nts where $GFORTRAN is a bare command name rather than a full path. As a resu=
lt, the Fortran OpenMP module (omp_lib.mod) is never installed, and programs =
that "use omp_lib" fail with:
>=20
> Fatal Error: Cannot open module file 'omp_lib.mod' for reading

... this behavior is correct, as libgomp doesn't have a Fortran compiler avai=
lable (as of the current GCC build).

It's not possible to use an external Fortran compiler; GCC target libraries a=
re only to be built using the compilers of the current GCC build.

> The fix adds a "command -v" fallback for testing whether a command is avail=
able on $PATH.

So, that seems very dubious to be.

> The bug was introduced in r0-98199-g2122aa973ed (2010-01-26)

No, that commit just changed the `test -x` check from the full `"$GFORTRAN"` =
"path" (which includes compiler flags) to just its `$$r/$(HOST_SUBDIR)/gcc/gf=
ortran` part.

> so the Fortran OpenMP module has been missing from cross-compiled installs =
for 16 years.

Quite likely even longer!  Because, `test -x "x86_64-w64-mingw32-gfortran [co=
mpiler flags here]"` is generally `false`.

Please first clarify how you're `configure`ing your cross-compiler.

--
https://forge.sourceware.org/gcc/gcc/pulls/172#issuecomment-6635