configure:3233: /var/tmp/cross/x86_64-w64-mingw32/portage/cross-x86_64-w64-mingw32/gcc-4.5.1/work/build/./gcc/xgcc -B/var/tmp/cross/x86_64-w64-mingw32/portage/cross-x86_64-w64-mingw32/gcc-4.5.1/work/build/./gcc/ -L/usr/x86_64-w64-mingw32/lib -L/usr/mingw/lib -isystem /usr/x86_64-w64-mingw32/include -isystem /usr/mingw/include -B/usr/x86_64-w64-mingw32/bin/ -B/usr/x86_64-w64-mingw32/lib/ -isystem /usr/x86_64-w64-mingw32/include -isystem /usr/x86_64-w64-mingw32/sys-include -m32 -c -g -O2 -pipe conftest.c >&5 Assembler messages: Fatal error: selected target format 'pe-i386' unknown
Created attachment 248480 [details] cross-x86_64-w64-mingw32-info.log
Created attachment 248481 [details] cross-x86_64-w64-mingw32-gcc-stage1.log
Created attachment 248482 [details] libgcc/config.log
BTW: recent portage prints this: """ !!! WARNING - Cannot auto-configure CHOST x86_64-w64-mingw32 !!! You should edit /usr/x86_64-w64-mingw32/etc/make.conf !!! by hand to complete your configuration """
Same for i686-w64-mingw32
almost the same for me when doing crossdev i686-w64-mingw32 on amd64 system part of confog.log at build/i686-w64-mingw32/64/libgcc/config.log: configure:3020: /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.5.1/work/build/./gcc/xgcc -B/var/tmp/cross/i686-w64-mingw32/portag e/cross-i686-w64-mingw32/gcc-4.5.1/work/build/./gcc/ -L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem /usr/i686-w64-mingw32/include -isystem /usr/ mingw/include -B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem /usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-inclu de -m64 -o conftest -g -O2 -pipe conftest.c >&5 conftest.c:1:0: sorry, unimplemented: 64-bit mode not compiled in Assembler messages: Fatal error: No compiled in support for x86_64 configure:3023: $? = 1 configure:3211: checking for suffix of object files configure:3233: /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.5.1/work/build/./gcc/xgcc -B/var/tmp/cross/i686-w64-mingw32/portag e/cross-i686-w64-mingw32/gcc-4.5.1/work/build/./gcc/ -L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem /usr/i686-w64-mingw32/include -isystem /usr/ mingw/include -B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem /usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-inclu de -m64 -c -g -O2 -pipe conftest.c >&5 conftest.c:1:0: sorry, unimplemented: 64-bit mode not compiled in Assembler messages: Fatal error: No compiled in support for x86_64 configure:3237: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3251: error: in `/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.5.1/work/build/i686-w64-mingw32/64/libgcc': configure:3254: error: cannot compute suffix of object files: cannot compile that looks strange that xgcc uses -m64 switch.
that's strange but old good mingw-gcc-4.4.4 fails to build too /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/build/./gcc/xgcc -B/var/tmp/cross/i686-w64-mingw32/portage/cross-i686- w64-mingw32/gcc-4.4.4-r2/work/build/./gcc/ -L/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/build/i686-w64-mingw32/wi nsup/mingw -L/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/build/i686-w64-mingw32/winsup/w32api/lib -isystem /var/tm p/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/winsup/mingw/include -isystem /var/tmp/cross/i686-w64-mingw32/porta ge/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/winsup/w32api/include -B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem /usr/i68 6-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include -g -O2 -pipe -O2 -I/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc- 4.4.4-r2/work/gcc-4.4.4/gcc/../winsup/w32api/include -g -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -W missing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../ ./gcc -I/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/libgcc -I/var/tmp/cross/i686-w64-mingw32/portage/cro ss-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/libgcc/. -I/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/l ibgcc/../gcc -I/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/libgcc/../include -DHAVE_CC_TLS -o _lshrdi3. o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/lib gcc/../gcc/libgcc2.c \ In file included from ../.././gcc/tm.h:13, from /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/libgcc/../gcc/libgcc2.c:31: /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/gcc-4.4.4-r2/work/gcc-4.4.4/libgcc/../gcc/config/i386/cygming.h:72:19: error: stdio.h: No such file or directory
regarding my last comment. that was wrong. i manually removed cross compiler but portage still thought its present, that cause missing headers. so sorry for my inattention my post-previous comment... i just tried to remove (emerge -C) anything mingw related, installed latest(9999999) crossdev, then started crossdev again with USE="-opnemp" and everything built fine. so i see 2 possible reasons for failures: 1) i did something wrong 2) something wrong with crossdev-20100814
oh i mean USE="-openmp" of course. details here http://bugs.gentoo.org/show_bug.cgi?id=326757 but anyway its just additional details not related to this report
binutils gets built with 32-bit OR 64-bit gcc gets built with 32-bit AND 64-bit When building the *-w64-mingw32 target, we need binutils to --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 The multitarget use flag adds --enable-targets=all; this appears to do nothing.
gcc should not be attempting a multilib build
(In reply to comment #11) > gcc should not be attempting a multilib build > So, crossdev should add -multilib to the gcc use flags?
no
(In reply to comment #12) > (In reply to comment #11) > > gcc should not be attempting a multilib build > > > > So, crossdev should add -multilib to the gcc use flags? > Ugh. My profile is default/linux/amd64/10.0, and multilib is a protected set use flag.
Looking at Alon Bar-Lev's gcc-stage1.log, gcc _defaults_ to multilib - the configure line has no --enable-multilib. If gcc shouldn't be trying to multilib the cross-compiler, we should ignore the the forced multilib USE flag, and tell gcc --disable-multilib
Created attachment 250071 [details, diff] Honour GCC_TARGET_NO_MULTILIB when compiling gcc
Created attachment 250073 [details, diff] Add GCC_TARGET_NO_MULTILIB=true when cross-compiling
Created attachment 250075 [details, diff] Add GCC_TARGET_NO_MULTILIB=true when cross-compiling Fixed typo
Comment on attachment 250075 [details, diff] Add GCC_TARGET_NO_MULTILIB=true when cross-compiling i already said no
(In reply to comment #19) > (From update of attachment 250075 [details, diff]) > i already said no > What should we do then, since the amd64 profile's forced multilib USE flag is telling gcc to compile multilib, and gcc-4.5.1 defaults to multilib?
i havent decided. perhaps change toolchain.eclass:is_multilib() to require linux targets rather than blanket arches.
(In reply to comment #21) > i havent decided. perhaps change toolchain.eclass:is_multilib() to require > linux targets rather than blanket arches. > At the moment, toolchain.eclass:gcc-compiler-configure() will only disable multilib if is_multilib() is false and the target is *-linux*. On lines 189 to 223 of Alon Bar-Lev's gcc-stage1.log, multilib is not explicitly enabled, yet on lines 3120 to 3143 of Alon Bar-Lev's gcc-stage1.log, libgcc attempts to configure 32on64 multilib.
Hi, I can test anything you like... :)
(In reply to comment #11) > gcc should not be attempting a multilib build Actually, the mingw64 people aim at providing a multilib 64bit toolchain. That's why it might be the default in gcc 4.5.1. You should think about addin multilib support to mingw64 toolchains created by crossdev - probably optional. For now, I can live with having seperate 32bit and 64bit toolchains.
(In reply to comment #24) > Actually, the mingw64 people aim at providing a multilib 64bit toolchain. > That's why it might be the default in gcc 4.5.1. Looking at GCC SVN, multilib has been the default for all targets since EGCS 1.0 in 1997.
(In reply to comment #25) > (In reply to comment #24) > > Actually, the mingw64 people aim at providing a multilib 64bit toolchain. > > That's why it might be the default in gcc 4.5.1. > > Looking at GCC SVN, multilib has been the default for all targets since EGCS > 1.0 in 1997. Since gcc 4.5.x, there is the file t-mingw-w64 in gcc/config/i386. It's new, and it the file that causes our troubles. It the file that enabled both 32 _and_ 64 in a single multilib toolchain. In previsous versions, this was the case, and a mingw32-w64 toolchain was only "singlelib".
As I workaround, I tried the following: EXTRA_ECONF="--disable-multilib" emerge -1 cross-x86_64-w64-mingw32/gcc Unfortunatly, it was unsuccessful: checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Fehler 1 I'm trying USE="nocxx" and EXTRA_ECONF="--disable-multilib" right now.
(In reply to comment #27) > As I workaround, I tried the following: > EXTRA_ECONF="--disable-multilib" emerge -1 cross-x86_64-w64-mingw32/gcc > > Unfortunatly, it was unsuccessful: > checking for ld that supports -Wl,--gc-sections... configure: error: Link tests > are not allowed after GCC_NO_EXECUTABLES. > make[1]: *** [configure-target-libstdc++-v3] Fehler 1 > > I'm trying USE="nocxx" and EXTRA_ECONF="--disable-multilib" right now. > You need at least Binutils 2.20.51 to build gcc-4.5.1, as the name mangling for mingw-w64 was changed between 4.5.0 and 4.5.1
(In reply to comment #28) > You need at least Binutils 2.20.51 to build gcc-4.5.1, as the name mangling for > mingw-w64 was changed between 4.5.0 and 4.5.1 I updated binutils to the latest 2.20.51 in portage. USE="-nocxx" still fails with the same error as before.
(In reply to comment #29) > (In reply to comment #28) > > You need at least Binutils 2.20.51 to build gcc-4.5.1, as the name mangling for > > mingw-w64 was changed between 4.5.0 and 4.5.1 > > I updated binutils to the latest 2.20.51 in portage. USE="-nocxx" still fails > with the same error as before. > After building the latest binutils, you need to rebuild mingw64-runtime to successfully build gcc-4.5.1
thanks for the info
(In reply to comment #31) > thanks for the info Reopen, because the work EXTRA_ECONF-workaround is still needed.
(In reply to comment #30) > > After building the latest binutils, you need to rebuild mingw64-runtime to > successfully build gcc-4.5.1 > I should have said: > After building the latest binutils, you need to rebuild mingw64-runtime to > successfully build gcc-4.5.1 __with the --disable-multilib configure option__ To successfully build gcc-4.5.0+ without the EXTRA_ECONF=--disable-multilib workaround: * toolchain.eclass would need to be patched to disable multilib for all non-multilib builds; and/or * toolchain-binutils.eclass or binutils itself would need to be patched to enable the appropriate targets for multilib builds * optionally, add a use flag to enable or disable multilib cross-target tools
> To successfully build gcc-4.5.0+ without the EXTRA_ECONF=--disable-multilib > workaround: > * toolchain.eclass would need to be patched to disable multilib for all > non-multilib builds; and/or There would have to be a blacklist. arm toolchains should continue to be multilib, for example. > * toolchain-binutils.eclass or binutils itself would need to be patched to > enable the appropriate targets for multilib builds > * optionally, add a use flag to enable or disable multilib cross-target tools Crossdev could add appropriate configuration to the files in /etc/portage/env/cross*.
Created attachment 250559 [details, diff] Disable multilib when is_multilib returns false on non-linux targets
Created attachment 250561 [details, diff] Blacklist multilib on mingw
I seem to still have this problem on a fresh minimal system, and this bug was marked working... Is a resolution coming or should I just compile on windows...
(In reply to comment #37) > I seem to still have this problem on a fresh minimal system, and this bug was > marked working... Is a resolution coming or should I just compile on windows... > This is NOT working - see comments 31 onwards; SpanKY marked this as "WORKS FOR ME" and removed himself from the CC on this bug because he took my "need to rebuild" without looking at the fact that GCC defaults to multilib, and toolchain will only disable it when the target is linux. AFAIK, only Toolchain maintainers can re-open this bug. We may need to open a new bug to make ourselves heard.
With latest binutils (2.21.51.0.1), a stage3 multilib toolchain can actually be built. Unfortunatly, stage4 fails somewhere during configure of libstc++. Does a multilib toolchain actually build OK if you do it by hand? On https://sourceforge.net/apps/trac/mingw-w64/wiki/TODO%20List it says: Support of multilib build in configure and in gcc. Parts are already present in gcc's 4.5 version by using target triplet <cpu>-w64-mingw32 ktietz of the mingw64 team recommended to build a non-multilib toolchain. There are some pifalls building a multilib toolchain, he said. BTW: The reporter of this bug (Alon Bar-Lev) can reopen it.
(In reply to comment #39) > With latest binutils (2.21.51.0.1), a stage3 multilib toolchain can actually be > built. Unfortunatly, stage4 fails somewhere during configure of libstc++. The multilib gcc-stage2 compile is failing because GCC_NO_EXECUTABLES gets set because configure is telling GCC to look in /usr/$TARGET/lib (and not /usr/$TARGET/lib32) for the 32-bit libraries when it is doing the initial link test for the 32-bit libstdc++. This appears to be one of the issues mentioned on the mingw-w64 TODO page (Determine where to install the libraries). The non-multilib gcc-stage2 compiles fine when the EXTRA_ECONF=--disable-multilib workaround is used.
I confirm that: EXTRA_ECONF=--disable-multilib crossdev -t x86_64-w64-mingw32 --stage3 Works, while stage4 not. vapier, it should behave the same at your system as well.
(In reply to comment #41) > I confirm that: > EXTRA_ECONF=--disable-multilib crossdev -t x86_64-w64-mingw32 --stage3 > > Works, while stage4 not. > > vapier, it should behave the same at your system as well. > For the EXTRA_ECONF workaround, try: crossdev -t x86_64-w64-mingw32 --genv EXTRA_ECONF=--disable-multilib I had a look, and the --[bgkl]env option was added by vapier on 08 Oct 2010.
probably fixed by way of other changes http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.457&r2=1.458
Created attachment 270667 [details] `crossdev -t x86_64-w64-mingw32` gcc-stage-2 This is still not fixed. toolchain.eclass still uses multilib when cross-compiling. multilib is forced on for multilib hosts, and forced off for non-multilib hosts. Thus GCC still attempts to build multilib *-w64-mingw32 when the host is multilib. This results in GCC_NO_EXECUTABLES in gcc stage 2. The --genv EXTRA_ECONF=--disable-multilib workaround is still needed.
Comment on attachment 250559 [details, diff] Disable multilib when is_multilib returns false on non-linux targets patch obsoleted/included by toolchain.eclass revision 1.458
(In reply to comment #44) Stable crossdev is at 20110310. multilib unforcing was added in GIT on 2011-03-20. Will test crossdev-99999999
(In reply to comment #42) > (In reply to comment #41) > > I confirm that: > > EXTRA_ECONF=--disable-multilib crossdev -t x86_64-w64-mingw32 --stage3 > > > > Works, while stage4 not. > > > > vapier, it should behave the same at your system as well. > > > > For the EXTRA_ECONF workaround, try: > crossdev -t x86_64-w64-mingw32 --genv EXTRA_ECONF=--disable-multilib > > I had a look, and the --[bgkl]env option was added by vapier on 08 Oct 2010. I can confirm, that --genv can be used to workaround the problem. However, if comment #44 is correct, there's another bug here, I believe. Can the reporter please re-open?
This issue was fixed in crossdev git on 2011-03-20.
