From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8961 invoked by alias); 20 Sep 2011 14:12:48 -0000 Received: (qmail 8953 invoked by uid 22791); 20 Sep 2011 14:12:47 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_CX,TW_DC,TW_JL X-Spam-Check-By: sourceware.org Received: from mail-vw0-f48.google.com (HELO mail-vw0-f48.google.com) (209.85.212.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Sep 2011 14:12:32 +0000 Received: by vws7 with SMTP id 7so859893vws.21 for ; Tue, 20 Sep 2011 07:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.5.210 with SMTP id 18mr219709vcw.83.1316527950814; Tue, 20 Sep 2011 07:12:30 -0700 (PDT) Received: by 10.220.201.138 with HTTP; Tue, 20 Sep 2011 07:12:30 -0700 (PDT) In-Reply-To: <4E789A98.8060109@users.sourceforge.net> References: <4E77C57F.40808@users.sourceforge.net> <4E78932C.5070404@users.sourceforge.net> <4E789A98.8060109@users.sourceforge.net> Date: Tue, 20 Sep 2011 15:29:00 -0000 Message-ID: Subject: Re: [patch] --enable-dynamic-string default for mingw-w64 From: Kai Tietz To: Charles Wilson Cc: JonY , Gcc Patch List , MinGW Users List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg01165.txt.bz2 2011/9/20 Charles Wilson : > 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. =A0But I can confirm >>> that patch is ok from perspective of windows-target maintainer. >>> Just one question I have here. =A0Why do we enable this option only >>> for w64 flavor? =A0AFAIK 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: > > =A0../gcc-4.6.1/configure --enable-languages=3Dc,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=3Dmingw32 --prefix=3D/mingw > > =A0../gcc-4.5.2/configure > --enable-languages=3Dc,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=3Dmingw32 --prefix=3D/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=3D/usr/src/packages/mingw-gcc/mingw-gcc-4.5.2-1/src/gcc-4.5.2 > --prefix=3D/usr --exec-prefix=3D/usr --bindir=3D/usr/bin --sbindir=3D/usr= /sbin > --libexecdir=3D/usr/lib --datadir=3D/usr/share --localstatedir=3D/var > --sysconfdir=3D/etc --datarootdir=3D/usr/share > --docdir=3D/usr/share/doc/mingw-gcc -C --build=3Di686-pc-cygwin > --host=3Di686-pc-cygwin --target=3Di686-pc-mingw32 > --with-sysroot=3D/usr/i686-pc-mingw32/sys-root > --with-build-sysroot=3D/usr/i686-pc-mingw32/sys-root --disable-multilib > --disable-win32-registry --enable-languages=3Dc,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. =A0I *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. =A0Was 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