Can't build "i686-w64-mingw32 CRT"
ViNi-Arco opened this issue · 13 comments
Hi Etienne, I hope you are ok.
Well, since the new changes in the scrip, I am not able to build Mingw 9 with GCC 10.
Only GCC 10 is compiling fine, this is just with Mingw..
Here is my configuration, to see if it happens to you too.
Click here to see more information about the problem
Building i686-w64-mingw32 CRT
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for i686-w64-mingw32-strip... no
checking for strip... strip
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... i686-w64-mingw32
checking for sysroot... /tmp/mostlyportable-mingw/usr/i686-w64-mingw32
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... (cached) gawk
checking for i686-w64-mingw32-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking for i686-w64-mingw32-g++... no
checking for i686-w64-mingw32-c++... no
checking for i686-w64-mingw32-gpp... no
checking for i686-w64-mingw32-aCC... no
checking for i686-w64-mingw32-CC... no
checking for i686-w64-mingw32-cxx... no
checking for i686-w64-mingw32-cc++... no
checking for i686-w64-mingw32-cl.exe... no
checking for i686-w64-mingw32-FCC... no
checking for i686-w64-mingw32-KCC... no
checking for i686-w64-mingw32-RCC... no
checking for i686-w64-mingw32-xlC_r... no
checking for i686-w64-mingw32-xlC... no
checking for i686-w64-mingw32-clang++... no
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking for i686-w64-mingw32-ranlib... no
checking for ranlib... ranlib
checking for i686-w64-mingw32-dlltool... no
checking for dlltool... no
checking for i686-w64-mingw32-ar... no
checking for i686-w64-mingw32-lib... no
checking for i686-w64-mingw32-link... no
checking for ar... ar
checking the archiver (ar) interface... ar
checking dependency style of gcc... gcc3
checking for i686-w64-mingw32-as... no
checking for as... as
checking whether to build a w32api package for Cygwin... no
checking whether to build the Win32 libraries... yes
checking whether to build the Win64 libraries... no
checking whether to build the WinARM32 libraries... no
checking whether to build the WinARM64 libraries... no
checking whether to use genlib... no
checking whether to enable globbing... yes
checking whether to enable private exports... no
checking whether to enable delay import libs... no
checking what to provide as libmsvcrt.a... msvcrt-os
checking whether to enable experimental features... no
checking whether the compiler supports -municode... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for _mingw_mac.h... no
configure: error: Please check if the mingw-w64 header set and the build/host option are set properly.
Hi ViNi-Arco!
I was able to build GCC10 + MinGW 8.0.2 as well as GCC11 + MinGW 9.0.0 (using releases/gcc-10 and releases/gcc-11 trees for GCC to grab upstream fixes + the current untouched toolset versions), so I believe that's expected behavior.
MinGW 9.0.0 was released less than two weeks after 8.0.2 (which is an unusual release pattern for MinGW), so I tend to believe 9.0.0 was targeting GCC11 specifically. In Mostlyportable, we switched to MinGW 9.0.0 in the default config after we switched to GCC11 also, so that GCC10 + MinGW 9.0.0 combo was never tested by people using the default config (the vast majority) nor myself.
Are you certain that specific combo used to work before the recent changes? Also the fact that it breaks only with MinGW with a MinGW-specific error while we only changed how we handle GCC looks weird to me.
Are you certain that specific combo used to work before the recent changes?
Yes, here:
so I tend to believe 9.0.0 was targeting GCC11 specifically
I don't think so, Valve also uses GCC 10+Mingw 9
I've been researching more about my problem and came up here, the first one talks about Gold, but I tried passing --enable-gold=no --enable-ld=default for Mingw-w64-Binutils and the error continued.
From the error description, I thought it might be this change you made that might have caused it, and I went back to the old one, and the same "configure: error: Please check if the mingw-w64 header set and the build/host option are set properly." error happens :'(
I've been looking at the Mingw wiki to see if I can find anything strange in the script, and so far.. I don't know, if there was something very wrong you would have noticed.
Now I'm happy, I found the "problematic" commit, that's it, the problem is the /usr that you passed, apparently that made CRT not find Mingw-w64-Headers, and give the error.
Here to build it now, I took the liberty and put some settings for my build:
With this I identified a broken symbolic link, and made a PR with the fix, this modification is fine, the problem was even with /usr
Sadly your changes would break mesa again and your symlink change would break Arch. After checking out your config, the issue doesn't exist on my end. The initial test I did was triggering a libgomp issue which is unrelated.
So the generic approach bites us here apparently and either we break compiling stuff with the toolchain or the toolchain compilation itself. It would be cool to know why your distro doesn't accept the /usr/bin approach as it's extremely generic.
your symlink change would break Arch.
Okay then I'll close the PR
After checking out your config, the issue doesn't exist on my end.
Really! my config works for you! I really want to know why this happens only for me.
It would be cool to know why your distro doesn't accept the /usr/bin approach as it's extremely generic.
I use Arch Linux too, I follow the Arch wiki when installing, what could cause this I have no idea..
My only hope is to change it to this _dstdir=/tmp/mostlyportable-mingw/usr
I came to this conclusion when I looked at the CRT log and it pointed to /tmp/mostlyportable-mingw/:
PATH: /tmp/mostlyportable-mingw/i686-w64-mingw32/
PATH: /tmp/mostlyportable-mingw/x86_64-w64-mingw32/
PATH: /tmp/mostlyportable-mingw/libexec/
PATH: /tmp/mostlyportable-mingw/bin/
PATH: /tmp/mostlyportable-mingw/lib/
PATH: /tmp/mostlyportable-mingw/include/
And as you can see there is no /usr.
I will try with the GCC12 tarball with Mingw 10 to see if this happens there too..
I'm trying to find a solution for everyone
I'm trying to find a solution for everyone
Thank you for dedicating your time to this Mr.Etienne
I'm reading the documentation on how to build it from Mingw and they recommend passing export PATH="$PATH:/home/luser/mingw64/bin" and there is the solution for, I passed export PATH=$PATH:/tmp/mostlyportable-mingw/usr/bin in terminal before building, and was able to build Mingw with no problems..
Finally! I thought this would have no solution, except to remove /usr from the scrip.
Apparently Gnome people had this problem and others with Mingw, and they started using PATH=$PATH:<prefix>/bin
Please try with those changes
Please try with those changes
Perfect, you did it! The build complete without errors.
The crt-i686-w64-mingw32 log now reports the path:
PATH: /tmp/mostlyportable-mingw/
PATH: /tmp/mostlyportable-mingw/lib/
PATH: /tmp/mostlyportable-mingw/bin/
PATH: /tmp/mostlyportable-mingw/usr/
And the broken symbolic link, was solved too:
Thank you very much Mr.Etienne, I hope you have a good night
Great news! 🐸 ❤️