https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947
--- Comment #7 from Kai Tietz ---
Just as note: This issue got partial addressed for 4.8 gcc for cross-compiler
version. We place bitness-version into specific lib folder for bitness.
Just for native mode - for being compatible with existing bui
--- Comment #6 from dmitrij dot ledkov at ubuntu dot com 2010-07-06 18:58
---
Yes please. I'm nearing completion of packaging co-installable w64 & w32
toolchains and I'm hitting a clash with this file now =) i'm wondering where to
shuffle it to.
I don't care about the naming but it sho
--- Comment #5 from jon_y at users dot sourceforge dot net 2010-01-24
07:59 ---
Ping,
We need to get this fixed ASAP. Probably involving the libtool devs as well. I
propose the following naming scheme.
libw64stdc++-6.dll (64bit mingw-w64)
libw32stdc++-6.dll (32bit mingw-w64)
libstdc++
--- Comment #4 from jon_y at users dot sourceforge dot net 2009-04-29
08:37 ---
(In reply to comment #3)
> (In reply to comment #2)
> > The same problem will occur for all dll's (libstdc++-x,dll,
> > libgfortran-x.dll,
> > libssp-x.dll, etc) that are built as part of gcc
> > Danny
>
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-29 07:38 ---
(In reply to comment #2)
> The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
> libssp-x.dll, etc) that are built as part of gcc
> Danny
That's correct. We have to find a way to install t
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29
07:29 ---
The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc
Danny
--
dannysmith at users dot sourceforge dot net changed:
--- Comment #1 from 10walls at gmail dot com 2009-04-28 15:39 ---
Hi,
some more info on the configured gcc:
built with:
../gcc-trunk/configure --host=i686-pc-mingw32 --build=i686-pc-mingw32
--target=x86_64-w64-mingw32 --enable-multilib --enable-64bit
--prefix=/mingw/w64_64 --with-sysroo
