https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #27 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to LIU Hao from comment #26)
> (In reply to Thomas Schwinge from comment #25)
> > Now hopefully fixed for good. ;-)
>
> This breaks bootstrapping fortran on x86_64-w64-mingw32.
Famous last words (of mine)... ;'-(
> For some reason,
> the build system attempts to create a static library with MSVC suffix (.lib)
> instead of GNU suffix (.a), and fails with
>
> .../x86_64-w64-mingw32/bin/ar.exe: .libs/libgomp.lib: file format not
> recognized
>
>
> Here is a patch created by AI which seems to work somehow, but I don't know
> whether it's correct:
>
> During a bootstrap build, stage 1 by default only builds the languages
> selected by '--enable-stage1-languages' ('c,c++'), so the '$GFORTRAN' that
> the top-level build system passes to the libgomp build does not exist yet.
ACK. I confirm that also, for example, 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. But your "AI" now
states:
> With such a non-functional '$FC', libtool configures its Fortran language
> tag, and the per-host library naming of that tag then overwrites the one
> established for the C language tag: on Windows hosts, 'library_names_spec'
> becomes '${libname}${release}${versuffix}${shared_ext} $libname.lib' (the
> naming used for MSVC) and 'libext' becomes 'lib'. The libgomp link then
> creates a 'libgomp.lib' copy of the DLL, and subsequently fails when trying
> to create the static archive of the same name:
>
> .../x86_64-w64-mingw32/bin/ar.exe: .libs/libgomp.lib: file format not
> recognized
..., so I wasn't right, and that bogus 'FC' actually does have adverse side
effects.
One question is whether the top-level build system shouldn't actually be
passing a non-functional 'GFORTRAN' to the stage 1 libgomp 'configure'?
(Non-trivial change in the top-level build system.)
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.
We can't accept an "AI"-generated patch (and I'd do this a little bit
differently, anyway), but I'll cook up something similar.
Is there a way for me to (easily) reproduce this x86_64-w64-mingw32 bootstrap
build? (I don't have a Windows machine.) Otherwise, I'll later send you my
patch for testing?
