2011/9/20 Charles Wilson <cwils...@users.sourceforge.net>: > On 9/20/2011 9:20 AM, JonY wrote: >> On 9/20/2011 13:59, Kai Tietz wrote: >>> 2011/9/20 JonY: >>>> Its been used in the automated toolchain builds for sometime, >>>> seems like a good idea to enable it by default. It can be >>>> easily changed to match for all mingw as well if needed. >>> >>> This patch looks reasonable to me. Note that this is no approval >>> for it, as I'm not a libstdc++ maintainer. But I can confirm >>> that patch is ok from perspective of windows-target maintainer. >>> Just one question I have here. Why do we enable this option only >>> for w64 flavor? AFAIK is mingw.org also building their libstdc++ >>> with enabling this configure-option >> >> OK "i?86-*-mingw* | x86_64-*-mingw*)" then, any mingw.org >> developers care to comment? >> > > Unfortunately, while very old (3.x?) versions of mingw.org gcc used > this option IIRC, neither the latest official, nor the immediately > previous official mingw.org version were compiled with that option: > > ../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++ > --disable-sjlj-exceptions --with-dwarf2 --enable-shared > --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug > --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw > > ../gcc-4.5.2/configure > --enable-languages=c,c++,ada,fortran,objc,obj-c++ > --disable-sjlj-exceptions --with-dwarf2 --enable-shared > --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug > --enable-version-specific-runtime-libs --disable-werror > --build=mingw32 --prefix=/mingw > > > To match native mingw.org behavior, the cygwin->mingw.org-ish cross > toolchain is configured as: > Configured with: > /usr/src/packages/mingw-gcc/mingw-gcc-4.5.2-1/src/gcc-4.5.2/configure > --srcdir=/usr/src/packages/mingw-gcc/mingw-gcc-4.5.2-1/src/gcc-4.5.2 > --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin > --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var > --sysconfdir=/etc --datarootdir=/usr/share > --docdir=/usr/share/doc/mingw-gcc -C --build=i686-pc-cygwin > --host=i686-pc-cygwin --target=i686-pc-mingw32 > --with-sysroot=/usr/i686-pc-mingw32/sys-root > --with-build-sysroot=/usr/i686-pc-mingw32/sys-root --disable-multilib > --disable-win32-registry --enable-languages=c,c++,fortran,objc,obj-c++ > --enable-libgomp --disable-sjlj-exceptions --enable-libstdcxx-debug > --enable-version-specific-runtime-libs --with-dwarf2 --disable-werror > --enable-lto > > > So, this would be a change in current mingw.org behavior. I *was* > under the impression that this workaround for the old "can't pass > empty strings across DLL boundary" problem[1] was no longer necessary > in the gcc-4.x era, but I haven't tested the proposition. Was I wrong > about that?
Yes. If you read last comment of the thread you are citing, then you would notice that for static-libstdc++ version the issue is still present. So to allow users to use also static-libstdc++ variant, this option is still necessary. > I'm not really opposed to making this change for i*86-pc-mingw -- and > now's the time to do it, as the recently released 4.6.1 mingw.org gcc > broke the C++ abi anyway, thanks to thiscall. Here I am a bit curious? How is 4.6.1 affected by new thiscall calling-convention? Is it just its presence in 4.6.x, or what? As the thiscall-convention ABI change for C++ is done in 4.7.x only, and 4.6.x shouldn't be affected by it. Regards, Kai
