The custom 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.
---
libgomp/configure | 2 +-
libgomp/configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgomp/configure b/libgomp/configure
index 56cffe79634..a56c5691c26 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -12270,7 +12270,7 @@ case `echo $GFORTRAN` in
FC=no ;;
*)
set dummy $GFORTRAN; ac_word=$2
- if test -x "$ac_word"; then
+ if test -x "$ac_word" || command -v "$ac_word" >/dev/null 2>&1; then
FC="$GFORTRAN"
else
FC=no
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index 1730c62c74c..2cde2a05df4 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -164,7 +164,7 @@ case `echo $GFORTRAN` in
FC=no ;;
*)
set dummy $GFORTRAN; ac_word=$2
- if test -x "$ac_word"; then
+ if test -x "$ac_word" || command -v "$ac_word" >/dev/null 2>&1; then
FC="$GFORTRAN"
else
FC=no
--
2.54.0
