Bug 687074 – cross-x86_64-w64-mingw64/gcc: fixincludes breaks stage1 build

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Jonas Jelten 2019-05-31 13:47:31 UTC]

Created attachment 578144 [details, diff]
proposed patch

crossdev --target x86_64-w64-mingw64 (8.3.0 and 9.1.0) fails for me at stage1 because of:

In file included from /usr/x86_64-w64-mingw64/sys-include/_mingw.h:12,
                 from /usr/x86_64-w64-mingw64/sys-include/crtdefs.h:10,
                 from /usr/x86_64-w64-mingw64/sys-include/stddef.h:7,
                 from /tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/build/gcc/include/stddef.h:1,
                 from /tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/gcc-8.3.0/libgcc/../gcc/tsystem.h:44,
                 from /tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/gcc-8.3.0/libgcc/libgcc2.c:27:
/tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/build/gcc/include-fixed/stdio.h: In function ‘_func’:
/tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/build/gcc/include-fixed/stdio.h:136:3: error: expected declaration specifiers before ‘__extension__’
   __MINGW_EXTENSION typedef __int64 fpos_t;
   ^~~~~~~~~~~~~~~~~



The real reason behind this error is a mis-applied fixincludes-patch for hpux.

A simple fix to the problem is my proposed and attached patch.

I've just submitted this to upstream here:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02127.html

[Comment 1 James Le Cuirot 2019-05-31 22:07:47 UTC]

The toolchain team deals with this stuff.

[Comment 2 Sergei Trofimovich (RETIRED) 2019-06-01 07:10:01 UTC]

I wonder why I don't see a build failure. Can you attach your gcc's build.log?

[Comment 3 Jonas Jelten 2019-06-03 11:55:58 UTC]

Created attachment 578508 [details]
cross-x86_64-w64-mingw64:gcc-8.3.0-r1:20190529-234457.log

build log containing the failure

[Comment 4 Sergei Trofimovich (RETIRED) 2019-06-10 18:23:15 UTC]

Only now I've noticed that you are using 'x86_64-w64-mingw64' instead of more popular 'x86_64-w64-mingw32'. Trying to reproduce locally.

[Comment 5 Sergei Trofimovich (RETIRED) 2019-06-10 21:55:38 UTC]

(In reply to Sergei Trofimovich from comment #4)
> Only now I've noticed that you are using 'x86_64-w64-mingw64' instead of
> more popular 'x86_64-w64-mingw32'. Trying to reproduce locally.

Confirmed. '-mingw64' variant fails while '-mingw32' works. I wonder where the difference comes from.

[Comment 6 Sergei Trofimovich (RETIRED) 2019-06-10 22:07:12 UTC]

(In reply to Sergei Trofimovich from comment #5)
> (In reply to Sergei Trofimovich from comment #4)
> > Only now I've noticed that you are using 'x86_64-w64-mingw64' instead of
> > more popular 'x86_64-w64-mingw32'. Trying to reproduce locally.
> 
> Confirmed. '-mingw64' variant fails while '-mingw32' works. I wonder where
> the difference comes from.

Found it. fixincludes is a no-op for mingw32*, but not on mingw64:

https://github.com/gcc-mirror/gcc/blob/661fdbbb031bbc6d46c52523b1842493b31737eb/fixincludes/mkfixinc.sh#L12

Looking at libstdc++-v3/configure.host there are more assumptions about mingw32*-style prefix:

  mingw32*)
    case "$host" in
      *-w64-*)
        os_include_dir="os/mingw32-w64"
        error_constants_dir="os/mingw32-w64"
        ;;
      *)
        os_include_dir="os/mingw32"
        error_constants_dir="os/mingw32"
        ;;
    esac
    OPT_LDFLAGS="${OPT_LDFLAGS} \$(lt_host_flags)"
    ;;

Closing as invalid. Consider using 'mingw32*' tuples.

[Comment 7 Jonas Jelten 2019-06-11 10:11:18 UTC]

Thanks for your investigation!

I've learned by now that one has to use *-mingw32 even though one wants a 64-bit-target compiler. I've updated the wiki page to prevent further confusion :)

https://wiki.gentoo.org/wiki/Mingw