https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #28 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to Thomas Schwinge from comment #27)
> > 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.)
It's exactly the part that I'm not familiar with. Sorry.
> 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.
I'm not proposing this patch. This works somehow, but `FC=no` doesn't look
sensible. (why isn't it `FC=false`???)
> 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?
Maybe you can try MSYS2 PKGBUILD with GitHub Actions:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gcc
However I suspect it's no easy way; they are currently building GCC 16 tarball,
so the source URL and directory name have to be changed.
That's fine, you send any patches to me, and I'm glad to help.
