This is a summary of discussions relative to the merge request created by
(Peter0x44) <[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.org/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
that 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 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.
The latter is -- in my current understanding -- an invalid assumption:
`GFORTRAN` is passed into libgomp `configure` via the top-level build system's
`GFORTRAN_FOR_TARGET=$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/gcc/gfortran
-B$$r/$(HOST_SUBDIR)/gcc/`, and `$$r/$(HOST_SUBDIR)/gcc/gfortran` always an
absolute path, via `` r=`${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=fortran`? Because, in that case,
you'd get: `GFORTRAN_FOR_TARGET=$(STAGE_CC_WRAPPER) [TARGET]-gfortran`, and
with that:
> 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
... this behavior is correct, as libgomp doesn't have a Fortran compiler
available (as of the current GCC build).
It's not possible to use an external Fortran compiler; GCC target libraries are
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
> available 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/gfortran` 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
[compiler 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) this
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
x86_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=/bootstrap \
--with-sysroot=/bootstrap \
--target=$ARCH \
--enable-static \
--disable-shared \
--with-pic \
--enable-languages=c,c++,fortran \
--enable-libgomp \
--enable-threads=posix \
--enable-tls \
--enable-version-specific-runtime-libs \
--disable-libstdcxx-verbose \
--disable-dependency-tracking \
--disable-nls \
--disable-lto \
--disable-multilib \
CFLAGS_FOR_TARGET="-O2" \
CXXFLAGS_FOR_TARGET="-O2" \
LDFLAGS_FOR_TARGET="-s" \
CFLAGS="-O2" \
CXXFLAGS="-O2" \
LDFLAGS="-s" \
&& make -j$(nproc) all-gcc \
&& make install-gcc
```
And
```
& /dl/gcc/configure \
--prefix=$PREFIX \
--with-sysroot=$PREFIX \
--with-native-system-header-dir=/include \
--target=$ARCH \
--host=$ARCH \
--enable-static \
--disable-shared \
--with-pic \
--with-gmp=/deps \
--with-mpc=/deps \
--with-mpfr=/deps \
--enable-languages=c,c++,fortran \
--enable-libgomp \
--enable-threads=posix \
--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="-O2" \
CXXFLAGS_FOR_TARGET="-O2" \
LDFLAGS_FOR_TARGET="-s" \
CFLAGS="-O2" \
CXXFLAGS="-O2" \
LDFLAGS="-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 help?
On 2026-07-22 09:29:30+00:00, Thomas Schwinge (tschwinge) wrote:
>From your build script/`Dockerfile`, the "second" `gcc/configure` is the
>relevant one: that one builds the full GCC. That has
>`--enable-languages=[...],fortran`, and it does a plain `make`, so that looks
>alright.
Ah, of course! You're building here a `--host=x86_64-w64-mingw32`,
`--target=x86_64-w64-mingw32` GCC, with different `--build=[...]`. That means,
the build system cannot use the `--host=x86_64-w64-mingw32` GCC to build the
`--target=x86_64-w64-mingw32` libraries, so per
<https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html>, "you must have
already built and installed 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,config.status}`, and
`x86_64-pc-linux-gnu/libgomp/{Makefile,config.log,config.status}`, 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=x86_64-unknown-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu` configuration (using system GCC
`x86_64-linux-gnu-gcc` etc., and approximately 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" also
in the case when GCC is configured without `--enable-languages=fortran` in
effect, and it then still builds and installs the libgomp/Fortran support files
in GCC configurations without Fortran support enabled.
Please test
<https://inbox.sourceware.org/[email protected]>
"libgomp: Revise libgomp/Fortran support conditionals", which should 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 the
build when I wake up.
