From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 498 invoked by alias); 20 Sep 2011 13:53:05 -0000 Received: (qmail 489 invoked by uid 22791); 20 Sep 2011 13:53:03 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_CX,TW_DC,TW_JL X-Spam-Check-By: sourceware.org Received: from out3.smtp.messagingengine.com (HELO out3.smtp.messagingengine.com) (66.111.4.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Sep 2011 13:52:43 +0000 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C1EC3348BD; Tue, 20 Sep 2011 09:52:42 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 20 Sep 2011 09:52:42 -0400 Received: from [192.168.1.3] (50-88-210-98.res.bhn.net [50.88.210.98]) by mail.messagingengine.com (Postfix) with ESMTPSA id 43D43C207E1; Tue, 20 Sep 2011 09:52:42 -0400 (EDT) Message-ID: <4E789A98.8060109@users.sourceforge.net> Date: Tue, 20 Sep 2011 14:06:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: JonY CC: Kai Tietz , Gcc Patch List , MinGW Users List Subject: Re: [patch] --enable-dynamic-string default for mingw-w64 References: <4E77C57F.40808@users.sourceforge.net> <4E78932C.5070404@users.sourceforge.net> In-Reply-To: <4E78932C.5070404@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg01157.txt.bz2 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? 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. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 'course, Cesar will have to weigh in. -- Chuck