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