trouble with building MinGW-w64 windows-hosted toolchain using Linux

trouble with building MinGW-w64 windows-hosted toolchain using Linux

[i.nixman]

Hi,

I'm trying to build the windows-hosted MinGW-w64 toolchain using Linux 
and MinGW-w64 linux-hosted cross-compiler.

I have two questions:
1) is it possible? can someone point me to the necessary documentation?
2) I was able to successfully built 
libiconv+binutils+gmp+mpfr+mpc+isl+zlib+MinGW-w64-headers and faced with 
this error on the `make all-gcc` stage:

x86_64-w64-mingw32-gcc \
-L/mingw64/x86_64-w64-mingw32/lib \
-L/mingw64/mingw/lib \
-isystem /mingw64/x86_64-w64-mingw32/include \
-isystem /mingw64/mingw/include \
-fno-checking \
-g \
-O2 \
-pipe \
-fno-ident \
-I/home/nixman/mingw-gcc-9.3.0/x86_64-930-posix-seh-rt_v7-s/mingw64/opt/include 
\
-I/home/nixman/mingw-gcc-9.3.0/prerequisites/x86_64-zlib-static/include 
\
-I/home/nixman/mingw-gcc-9.3.0/prerequisites/x86_64-w64-mingw32-static/include 
\
-O2 \
-I../../../../../src/gcc-9.3.0/libgcc/../winsup/w32api/include \
-g \
-O2 \
-pipe \
-fno-ident \
-I/home/nixman/mingw-gcc-9.3.0/x86_64-930-posix-seh-rt_v7-s/mingw64/opt/include 
\
-I/home/nixman/mingw-gcc-9.3.0/prerequisites/x86_64-zlib-static/include 
\
-I/home/nixman/mingw-gcc-9.3.0/prerequisites/x86_64-w64-mingw32-static/include 
\
-DIN_GCC \
-W \
-Wall \
-Wno-narrowing \
-Wwrite-strings \
-Wcast-qual \
-Wno-format \
-Wstrict-prototypes \
-Wmissing-prototypes \
-Wold-style-definition \
-isystem ./include \
-g \
-DIN_LIBGCC2 \
-fbuilding-libgcc \
-fno-stack-protector \
-I. \
-I. \
-I../.././gcc \
-I../../../../../src/gcc-9.3.0/libgcc \
-I../../../../../src/gcc-9.3.0/libgcc/. \
-I../../../../../src/gcc-9.3.0/libgcc/../gcc \
-I../../../../../src/gcc-9.3.0/libgcc/../include \
-I../../../../../src/gcc-9.3.0/libgcc/config/libbid \
-DENABLE_DECIMAL_BID_FORMAT \
-DHAVE_CC_TLS \
-DUSE_EMUTLS \
-Wno-missing-prototypes \
-Wno-type-limits \
-o divtf3.o \
-MT divtf3.o \
-MD \
-MP \
-MF divtf3.dep \
-c ../../../../../src/gcc-9.3.0/libgcc/soft-fp/divtf3.c \
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c: In function 
‘get_intel_cpu’:
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c:222:20: error: 
‘bit_AVX512VNNI’ undeclared (first use in this function); did you mean 
‘bit_AVX512VBMI’?
           if (ecx & bit_AVX512VNNI)
                     ^~~~~~~~~~~~~~
                     bit_AVX512VBMI
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c:222:20: note: 
each undeclared identifier is reported only once for each function it 
appears in
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c: In function 
‘get_available_features’:
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c:372:14: error: 
‘bit_AVX512VBMI2’ undeclared (first use in this function); did you mean 
‘bit_AVX512VBMI’?
     if (ecx & bit_AVX512VBMI2)
               ^~~~~~~~~~~~~~~
               bit_AVX512VBMI
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c:374:14: error: 
‘bit_GFNI’ undeclared (first use in this function); did you mean 
‘bit_BMI’?
     if (ecx & bit_GFNI)
               ^~~~~~~~
               bit_BMI
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c:376:14: error: 
‘bit_VPCLMULQDQ’ undeclared (first use in this function); did you mean 
‘bit_PCLMUL’?
     if (ecx & bit_VPCLMULQDQ)
               ^~~~~~~~~~~~~~
               bit_PCLMUL
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c:378:14: error: 
‘bit_AVX512VNNI’ undeclared (first use in this function); did you mean 
‘bit_AVX512VBMI’?
     if (ecx & bit_AVX512VNNI)
               ^~~~~~~~~~~~~~
               bit_AVX512VBMI
../../../../../src/gcc-9.3.0/libgcc/config/i386/cpuinfo.c:380:14: error: 
‘bit_AVX512BITALG’ undeclared (first use in this function); did you mean 
‘bit_AVX5124FMAPS’?
     if (ecx & bit_AVX512BITALG)
               ^~~~~~~~~~~~~~~~
               bit_AVX5124FMAPS
../../../../../src/gcc-9.3.0/libgcc/static-object.mk:17: recipe for 
target 'cpuinfo.o' failed
make[3]: *** [cpuinfo.o] Error 1



gcc was configured as:

--with-gmp=/home/nixman/m64src/libs \
--with-mpfr=/home/nixman/m64src/libs \
--with-mpc=/home/nixman/m64src/libs \
--with-isl=/home/nixman/m64src/libs \
--target=x86_64-w64-mingw32 \
--disable-multilib \
--prefix=/home/nixman/mingw-w64 \
--with-sysroot=/home/nixman/mingw-w64 \
--enable-languages=c,c++ \
--enable-libstdcxx-time=yes \
--enable-threads=posix \
--enable-libgomp \
--enable-libatomic \
--enable-lto \
--enable-graphite \
--enable-checking=release \
--enable-fully-dynamic-string \
--enable-version-specific-runtime-libs \
--enable-libstdcxx-filesystem-ts=yes \
--disable-libstdcxx-pch \
--disable-libstdcxx-debug \
--enable-bootstrap \
--disable-rpath \
--disable-win32-registry \
--disable-nls \
--disable-werror \
--disable-symvers \
--with-libiconv



any ideas?


thanks!

Re: trouble with building MinGW-w64 windows-hosted toolchain using Linux

[Jim Wilson]

On Thu, May 14, 2020 at 5:26 AM <i.nixman@autistici.org> wrote:
>            if (ecx & bit_AVX512VNNI)
>                      ^~~~~~~~~~~~~~
>                      bit_AVX512VBMI

These bit_* macros are in cpuid.h.  Maybe you have more than one copy
of this file, and are accidentally using an older version than the one
in the gcc source tree?  I see that you have lots of -I and -isystem
options which normally should not be needed.  The gcc one is
gcc/config/i386/cpuid.h and should get installed into the gcc install
tree.

In general, you can find some useful info about cross building
toolchains in the crosstool-ng project.
https://crosstool-ng.github.io/

Note that gmp, mpfr, mpc, and isil can just be dropped into the gcc
source tree, alongside the other libraries like libgcc and libstdc++,
and the gcc Makefile will build them for you as part of the gcc build.
That should also work for zlib but I haven't tried that in a while.
For libiconv, it is simpler to just use --disable-nls, but it looks
like the toplevel makefile has support for that too, so adding that
into the gcc source tree looks like it would work too.

Jim

Re: trouble with building MinGW-w64 windows-hosted toolchain using Linux

[i.nixman]

Hi Jim,

On 2020-05-14 21:09, Jim Wilson wrote:
> On Thu, May 14, 2020 at 5:26 AM <i.nixman@autistici.org> wrote:
>>            if (ecx & bit_AVX512VNNI)
>>                      ^~~~~~~~~~~~~~
>>                      bit_AVX512VBMI
> 
> These bit_* macros are in cpuid.h.  Maybe you have more than one copy
> of this file, and are accidentally using an older version than the one
> in the gcc source tree?

even if this is the case, I have not copied any files to the gcc source 
tree.

> I see that you have lots of -I and -isystem
> options which normally should not be needed.

but as you can see I did not specify -I and -isystem arguments in the 
gcc/configure options.

> In general, you can find some useful info about cross building
> toolchains in the crosstool-ng project.
> https://crosstool-ng.github.io/

thank you! will read.

> Note that gmp, mpfr, mpc, and isil can just be dropped into the gcc
> source tree, alongside the other libraries like libgcc and libstdc++,
> and the gcc Makefile will build them for you as part of the gcc build.
> That should also work for zlib but I haven't tried that in a while.
> For libiconv, it is simpler to just use --disable-nls, but it looks
> like the toplevel makefile has support for that too, so adding that
> into the gcc source tree looks like it would work too.

ok, I will check this case!

thank you!

Re: trouble with building MinGW-w64 windows-hosted toolchain using Linux

[Jim Wilson]

On Fri, May 15, 2020 at 1:40 AM <i.nixman@autistici.org> wrote:
> On 2020-05-14 21:09, Jim Wilson wrote:
> > On Thu, May 14, 2020 at 5:26 AM <i.nixman@autistici.org> wrote:
> >>            if (ecx & bit_AVX512VNNI)
> >>                      ^~~~~~~~~~~~~~
> >>                      bit_AVX512VBMI
> >
> > These bit_* macros are in cpuid.h.  Maybe you have more than one copy
> > of this file, and are accidentally using an older version than the one
> > in the gcc source tree?
>
> even if this is the case, I have not copied any files to the gcc source
> tree.

cpuid.h is a user header file.  gcc contains a copy, and other
packages may contain a copy too.  This file gets copied into the
install tree.  So if you already have an install tree, and already
have header files in it, then you may already have a cpuid.h file from
somewhere else that may be older than the one in the gcc source tree.
Or maybe you have one in the install tree from an older gcc version
that lacks features required by the current gcc sources.  Normally gcc
will take cpuid.h from the gcc source tree, but if you add -I or
-isystem options to $CC, then that may confuse the build process and
it may use a cpuid.h file from your install tree instead of the one in
the gcc source tree.

Jim

Re: trouble with building MinGW-w64 windows-hosted toolchain using Linux

[i.nixman]

On 2020-05-19 20:34, Jim Wilson wrote:

> cpuid.h is a user header file.  gcc contains a copy, and other
> packages may contain a copy too.  This file gets copied into the
> install tree.  So if you already have an install tree, and already
> have header files in it, then you may already have a cpuid.h file from
> somewhere else that may be older than the one in the gcc source tree.
> Or maybe you have one in the install tree from an older gcc version
> that lacks features required by the current gcc sources.  Normally gcc
> will take cpuid.h from the gcc source tree, but if you add -I or
> -isystem options to $CC, then that may confuse the build process and
> it may use a cpuid.h file from your install tree instead of the one in
> the gcc source tree.
> 
> Jim

Hi,

you were right!

in the end I was able to build gcc-9.3 (with host=x86_64-w64-mingw32 and 
target=x86_64-w64-mingw32), but for this I had to build cross-gcc-9.3 
first.
before that I tried to use mingw-w64 cross-compiler based on gcc-7.2.

thank you!