https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #29 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- Created attachment 65834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65834&action=edit libgomp: Revise libgomp/Fortran support conditionals: 'FC=no' case Can you please try the patch I'm attaching here? (In reply to myself from comment #27) > [...] in > 'stage1-x86_64-pc-linux-gnu/libgomp/config.log', I see: > > [...] > configure:12375: checking for Fortran compiler version > configure:12384: [...]/build-gcc/./gcc/gfortran [...] --version >&5 > [...]/source-gcc/libgomp/configure: line 12386: > [...]/build-gcc/./gcc/gfortran: No such file or directory > configure:12395: $? = 127 > [...] > > I was under the assumption that "gfortran: No such file or directory" is a > benign error here, which doesn't cause any further trouble. That one actually is benign; before my 2026-08-14 change, we had "no: command not found" -- and with the proposed patch, we're now back to that. (Getting rid of that is subject for another patch; need to conditionalize 'AC_PROG_FC'.) Instead, the bogus (non-functional) 'FC' is the problem: (In reply to LIU Hao from comment #28) > (In reply to Thomas Schwinge from comment #27) > > > With such a non-functional '$FC', libtool configures its Fortran language > > > tag, [...] > > > > ..., so I wasn't right, and that bogus 'FC' actually does have adverse side > > effects. > > But either way: I tend to agree that (a) it's "OK" for libtool to produce a > > mess given such non-sensical input, and therefore, (b) libgomp 'configure' > > should handle this scenario in a defensive way, and it looks right to > > conditionalize libgomp's Fortran support wholly on > > '--enable-languages=fortran' being in effect. > [...] works somehow, but `FC=no` doesn't look > sensible. (why isn't it `FC=false`???) The reason is that 'configure'/Libtool treats 'FC=no' specially.
