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

This is a summary of discussions relative to the merge request created by (Pe=
ter0x44) <[email protected]> titled
libgomp: Fix gfortran detection when program is found via PATH
since its creation.

Description: The gfortran detection logic in libgomp's configure uses
"test -x" to check whether the $GFORTRAN program is executable.
However, "test -x" only succeeds for absolute or relative paths that
name an existing file; it fails for bare program names (e.g.
"x86_64-w64-mingw32-gfortran") that are found via $PATH lookup.

This causes FC to be incorrectly set to "no" in cross-compilation
environments where $GFORTRAN is a bare command name rather than a
full path.  As a result, the Fortran OpenMP module (omp_lib.mod) is
never installed, and programs that "use omp_lib" fail with:

  Fatal Error: Cannot open module file 'omp_lib.mod' for reading

The fix adds a "command -v" fallback for testing whether a command
is available on $PATH.

The bug was introduced in r0-98199-g2122aa973ed
(2010-01-26), so the Fortran OpenMP module has been missing from
cross-compiled installs for 16 years.

libgomp/ChangeLog:

	* configure.ac: Also accept $GFORTRAN when it can be found
	via PATH lookup using "command -v", not only when "test -x"
	succeeds on the bare name.
	* configure: Regenerate.

CC: [email protected]

The full and up to date discussion can be found at https://forge.sourceware.o=
rg/gcc/gcc/pulls/172

The merge request has been closed without being merged directly on the forge =
repository.


On 2026-06-07 18:44:51+00:00, (Peter0x44) wrote:

This patch fixed this issue in w64devkit:

https://github.com/skeeto/w64devkit/issues/395

On 2026-07-10 08:00:29+00:00, (Peter0x44) <[email protected]> requested t=
hat Thomas Schwinge (tschwinge) <[email protected]> review the code:





On 2026-07-10 08:04:44+00:00, Thomas Schwinge (tschwinge) wrote:

@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.


On 2026-07-10 13:30:16+00:00, (Peter0x44) wrote:

Sure I'll elaborate on that. This patch was written to fix (and does fix) thi=
s issue in w64devkit.

https://github.com/skeeto/w64devkit/issues/395

It may not fix it for the right reasons.

 w64devkit builds two toolchains. One with --host of Linux, and --target of x=
86_64-w64-mingw32, and it then uses that gcc to cross-compile a gcc with host=
 of x86_64-64-mingw32 and target of x86_64-w64-mingw32.

It's done in this dockerfile:
https://github.com/skeeto/w64devkit/blob/master/Dockerfile

The two relevant configure commands are:

```
COPY src/gcc-*.patch $PREFIX/src/
RUN cat $PREFIX/src/gcc-*.patch | patch -d/dl/gcc -p1 \
 && /dl/gcc/configure \
        --prefix=3D/bootstrap \
        --with-sysroot=3D/bootstrap \
        --target=3D$ARCH \
        --enable-static \
        --disable-shared \
        --with-pic \
        --enable-languages=3Dc,c++,fortran \
        --enable-libgomp \
        --enable-threads=3Dposix \
        --enable-tls \
        --enable-version-specific-runtime-libs \
        --disable-libstdcxx-verbose \
        --disable-dependency-tracking \
        --disable-nls \
        --disable-lto \
        --disable-multilib \
        CFLAGS_FOR_TARGET=3D"-O2" \
        CXXFLAGS_FOR_TARGET=3D"-O2" \
        LDFLAGS_FOR_TARGET=3D"-s" \
        CFLAGS=3D"-O2" \
        CXXFLAGS=3D"-O2" \
        LDFLAGS=3D"-s" \
 && make -j$(nproc) all-gcc \
 && make install-gcc
```
And
```
& /dl/gcc/configure \
        --prefix=3D$PREFIX \
        --with-sysroot=3D$PREFIX \
        --with-native-system-header-dir=3D/include \
        --target=3D$ARCH \
        --host=3D$ARCH \
        --enable-static \
        --disable-shared \
        --with-pic \
        --with-gmp=3D/deps \
        --with-mpc=3D/deps \
        --with-mpfr=3D/deps \
        --enable-languages=3Dc,c++,fortran \
        --enable-libgomp \
        --enable-threads=3Dposix \
        --enable-tls \
        --enable-version-specific-runtime-libs \
        --disable-libstdcxx-verbose \
        --disable-dependency-tracking \
        --disable-lto \
        --disable-multilib \
        --disable-nls \
        --disable-win32-registry \
        --enable-mingw-wildcard \
        CFLAGS_FOR_TARGET=3D"-O2" \
        CXXFLAGS_FOR_TARGET=3D"-O2" \
        LDFLAGS_FOR_TARGET=3D"-s" \
        CFLAGS=3D"-O2" \
        CXXFLAGS=3D"-O2" \
        LDFLAGS=3D"-s" \
       ```


On 2026-07-17 23:44:33+00:00, (Peter0x44) wrote:

@tschwinge is there any other info and context I could provide that would hel=
p?


On 2026-07-22 09:29:30+00:00, Thomas Schwinge (tschwinge) wrote:

>From your build script/`Dockerfile`, the "second" `gcc/configure` is the rele=
vant one: that one builds the full GCC.  That has `--enable-languages=3D[...]=
,fortran`, and it does a plain `make`, so that looks alright.

Ah, of course!  You're building here a `--host=3Dx86_64-w64-mingw32`, `--targ=
et=3Dx86_64-w64-mingw32` GCC, with different `--build=3D[...]`.  That means, =
the build system cannot use the `--host=3Dx86_64-w64-mingw32` GCC to build th=
e `--target=3Dx86_64-w64-mingw32` libraries, so per <https://gcc.gnu.org/onli=
nedocs/gccint/Configure-Terms.html>, "you must have already built and install=
ed a cross compiler that will be used to build the target libraries", so that=
's exactly what you're doing (your "first" GCC), and you're now tripping over=
 the fact that the "second" GCC doesn't recognize the "first" GCC's `gfortran=
`.  Now I understand the problem.

Can you please attach the "second" GCC's top-level `{Makefile,config.log,conf=
ig.status}`, and `x86_64-pc-linux-gnu/libgomp/{Makefile,config.log,config.sta=
tus}`, so that I can understand how `GFORTRAN_FOR_TARGET` etc. are set up in =
that case?


On 2026-07-22 17:13:19+00:00, (Peter0x44) wrote:

https://gist.github.com/Peter0x44/df7dd9ce1f7d1cb558f73b7ebb6db763


On 2026-07-29 08:50:24+00:00, Thomas Schwinge (tschwinge) wrote:

Thanks for the files, and I've now also reproduced the problem in a `--build=
=3Dx86_64-unknown-linux-gnu --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux=
-gnu` configuration (using system GCC `x86_64-linux-gnu-gcc` etc., and approx=
imately matching GCC sources).

The proposed "libgomp: Fix gfortran detection when program is found via PATH"=
 patch has the issue that it picks up the "gfortran [...] found via PATH" als=
o in the case when GCC is configured without `--enable-languages=3Dfortran` i=
n effect, and it then still builds and installs the libgomp/Fortran support f=
iles in GCC configurations without Fortran support enabled.

Please test <https://inbox.sourceware.org/20260729084137.3657939-1-tschwinge@=
baylibre.com> "libgomp: Revise libgomp/Fortran support conditionals", which s=
hould achieve the same thing, but in a conceptually simpler way.


On 2026-07-29 08:51:57+00:00, (Peter0x44) wrote:

Thanks for handling this. I've put the patch in w64devkit now and will test t=
he build when I wake up.