dev-util/mingw64-runtime was released in version 2.0.7.
should be all set now in the tree; thanks for the report! Commit message: Version bump http://sources.gentoo.org/dev-util/mingw64-runtime/mingw64-runtime-2.0.7.ebuild?rev=1.1
dev-util/mingw64-runtime-2.0.7 seems to create x86 libraries in addition to x86-64 ones. Is that intended? And also it installs the 64bit libraries into lib/ instead of lib64/. Is that intended, too?
(In reply to comment #2) i really don't know. i've never used mingw64 personally and have no plans to start. i've only ever had a need for mingw32 targets. cross-compilers by default use only /lib. it could be that we want to add multilib support to mingw64 targets and use /lib for the 32bit stuff and /lib64 for the 64bit stuff.
(In reply to comment #3) > (In reply to comment #2) > > i really don't know. i've never used mingw64 personally and have no plans > to start. i've only ever had a need for mingw32 targets. The mingw32 is completely obsolete... > cross-compilers by default use only /lib. it could be that we want to add > multilib support to mingw64 targets and use /lib for the 32bit stuff and > /lib64 for the 64bit stuff. There is an effort to support mingw in multilib configuration. This why you have the 32bit libraries. It is not working at crossdev configuration: $ x86_64-w64-mingw32-gcc -m64 a.c $ file a.out a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped $ x86_64-w64-mingw32-gcc -m32 a.c /usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.6.3/libgcc_eh.a when searching for -lgcc_eh <snip> But it is not that important as using the i686-w64-mingw32 target is working.
This was fixed long ago.
