| Message ID | 4E77C57F.40808@users.sourceforge.net |
|---|---|
| State | New |
| Headers | show |
2011/9/20 JonY <jon_y@users.sourceforge.net>: > Hi, > > 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. > > OK for trunk? > > Index: libstdc++-v3/configure.ac > =================================================================== > --- libstdc++-v3/configure.ac (revision 178946) > +++ libstdc++-v3/configure.ac (working copy) > @@ -132,7 +132,15 @@ > GLIBCXX_ENABLE_DEBUG([no]) > GLIBCXX_ENABLE_PARALLEL([yes]) > GLIBCXX_ENABLE_CXX_FLAGS > -GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([no]) > +case "$host" in > + # Enable fully ynamic strings on mingw-w64 by default > + i?86-w64-mingw* | x86_64-w64-mingw*) > + GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([yes]) > + ;; > + *) > + GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([no]) > + ;; > +esac > GLIBCXX_ENABLE_EXTERN_TEMPLATE([yes]) > > # Checks for operating systems support that doesn't require linking. 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 Kai
On 9/20/2011 13:59, Kai Tietz wrote: > 2011/9/20 JonY: >> Hi, >> >> 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. >> >> OK for trunk? >> >> Index: libstdc++-v3/configure.ac >> =================================================================== >> --- libstdc++-v3/configure.ac (revision 178946) >> +++ libstdc++-v3/configure.ac (working copy) >> @@ -132,7 +132,15 @@ >> GLIBCXX_ENABLE_DEBUG([no]) >> GLIBCXX_ENABLE_PARALLEL([yes]) >> GLIBCXX_ENABLE_CXX_FLAGS >> -GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([no]) >> +case "$host" in >> + # Enable fully ynamic strings on mingw-w64 by default >> + i?86-w64-mingw* | x86_64-w64-mingw*) >> + GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([yes]) >> + ;; >> + *) >> + GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([no]) >> + ;; >> +esac >> GLIBCXX_ENABLE_EXTERN_TEMPLATE([yes]) >> >> # Checks for operating systems support that doesn't require linking. > > 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 > > Kai > Adding mingw-users to CC list. OK "i?86-*-mingw* | x86_64-*-mingw*)" then, any mingw.org developers care to comment?
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.
2011/9/20 Charles Wilson <cwilso11@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
于 2011/9/20 21:52, 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. 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. > Based on TDM's advice, "--enable-fully-dynamic-string" can fix a bug when passing empty std::string objects between DLLs and EXEs.
On 9/20/2011 22:12, Kai Tietz wrote: >> 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. > IIUC, 4.6.x knows about thiscall, but I wasn't sure if it'll be made default.
On Tuesday 20 September 2011 15:12:30, Kai Tietz wrote: > 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. What ever happened to (from PR24196): > By the way, for gcc4.1 we will provide an alternate "versatile" string class > which doesn't have this problem, but in any case cannot become immediately > our default string class implementation due to ABI stability (you can already > play with it using CVS gcc: <ext/vstring.h>) and: > Sorry, but at this point in history, it's unlikely that we are going to do much > to the current std::string, given all the ABI implications. When we'll break > the ABI, for C++1x, a completely different implementation will be used, neither > affected by this issue nor by many others (ext/vstring is close, and already > available). ? It sounds like since 4.7 is breaking the ABI anyway on Windows targets, we could switch to this vstring instead for those targets? Or does that not work for C++ < C++11?
On 9/20/2011 10:12 AM, Kai Tietz wrote: > 2011/9/20 Charles Wilson <xxx@yyy.com>: http://cygwin.com/acronyms/index.html#PCYMTNQREAIYR >> 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. Thanks for the clarification. So, we (mingw.org) really should have been using this all along, to support users of -static-libstdc++ [*] >> 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. Ah, I misunderstood the previous conversation. My belief, at the end of that conversation, was that while the ABI of libstdc++-6.dll did not change in 4.6 (e.g. /THAT/ library wasn't affected by the new thiscall support), other C++ DLLs compiled using that compiler might see ABI changes due to thiscall. However, if in 4.6 thiscall must be explicitly activated -- __attribute__(thiscall) or somesuch, I assume -- and otherwise has no effect, then of course you're right: 4.6 imposes no ABI breakage on mingw. In that case, I suggest we (mingw.org) focus on maintaining ABI stability in our official releases in the 4.6 series, and plan to impose all the ABI changes (that we know of) when 4.7 is released: 1) --enable-fully-dynamic-string 2) thiscall 3) winpthreads? 4) anything else? SEH??? In the context of the patch under discussion at gcc-patches, that means only making --enable-fully-dynamic-string the default for i?86-pc-mingw32 in 4.7+, and not backporting to 4.6-. =====> side discussion ====> [*] We haven't been too kind to the "fully static" users (e.g both -static-libstdc++ AND -static-libgcc). As you know, without TDM's special patches [**], the i?86-pc-mingw32 compiler doesn't allow to throw exceptions across DLL boundaries unless using libgcc_s.dll -- there was hope that this could be remedied (without resorting to "horrible" patches) back in 2009 SoC [1] but that was never completed. [**] forward ports of Danny's self-described "horrible" patches to the 3.4.x series to enable exceptions-across-dll-bounds. We've (mingw.org) have been VERY hesitant to go back down that road, as the patches were in essence a fork, since they would "never be merged upstream" according to Danny. This was the main reason mingw.org's official gcc releases were "stuck" at 3.4.x during the entire 4.0, 4.1, AND 4.2 cycles -- hence our skittishness at doing something like that again. [1] http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008#Exceptions_across_DLL <===== side discussion <====== -- Chuck
On 9/20/2011 12:29 PM, Charles Wilson wrote: > On 9/20/2011 10:12 AM, Kai Tietz wrote: >> 2011/9/20 Charles Wilson<xxx@yyy.com>: >>> 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. > > Thanks for the clarification. So, we (mingw.org) really should have > been using this all along, to support users of -static-libstdc++ > Please let me present an opposing view. On the one hand, according to comment 4 of [1], by using --enable-fully-dynamic-string, all other users will miss a very good optimization. On the other hand, these users of -static-libstdc++ are mixing shared and static libraries, which isn't a good idea in general anyway, is it? [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 Regards, Cesar
于 2011/9/21 10:56, Cesar Strauss 写道: > Please let me present an opposing view. > > On the one hand, according to comment 4 of [1], by using > --enable-fully-dynamic-string, all other users will miss a very good > optimization. On the other hand, these users of -static-libstdc++ are > mixing shared and static libraries, which isn't a good idea in general > anyway, is it? > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 I think we can ask TDM, his release is built with "--enable-fully-dynamic-string". ( I forgot his Email... )
On 9/21/2011 17:08, xunxun wrote: > 于 2011/9/21 10:56, Cesar Strauss 写道: >> Please let me present an opposing view. >> >> On the one hand, according to comment 4 of [1], by using >> --enable-fully-dynamic-string, all other users will miss a very good >> optimization. On the other hand, these users of -static-libstdc++ are >> mixing shared and static libraries, which isn't a good idea in general >> anyway, is it? >> >> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 > > I think we can ask TDM, his release is built with > "--enable-fully-dynamic-string". > > ( I forgot his Email... ) > Ping, any updates?
On 09/23/2011 11:39 AM, JonY wrote:
> Ping, any updates?
I'm wondering if it wouldn't be cleaner to handle this in the
appropriate config/os/ headers, something like (with a good comment
before!):
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
#define _GLIBCXX_FULLY_DYNAMIC_STRING
#endif
Paolo.
On 9/23/2011 21:46, Paolo Carlini wrote: > On 09/23/2011 11:39 AM, JonY wrote: >> Ping, any updates? > I'm wondering if it wouldn't be cleaner to handle this in the > appropriate config/os/ headers, something like (with a good comment > before!): > > #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING > #define _GLIBCXX_FULLY_DYNAMIC_STRING > #endif > > Paolo. > Wouldn't that force it on no matter what the user sets in configure? IMHO, that would be breaking the --disable option.
On 09/23/2011 03:46 PM, Paolo Carlini wrote: > On 09/23/2011 11:39 AM, JonY wrote: >> Ping, any updates? > I'm wondering if it wouldn't be cleaner to handle this in the > appropriate config/os/ headers, something like (with a good comment > before!): > > #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING > #define _GLIBCXX_FULLY_DYNAMIC_STRING > #endif Even better would be changing the current infrastructure for this to have a default (not fully dynamic) of zero, a set value of one, undefined otherwise. Then in the mingw config/os we do the above and the configuring user is always happy. In that case the basic_string.* bits must be changed from #ifdef _GLIBCXX_FULLY_DYNAMIC_STRING to #if _GLIBCXX_FULLY_DYNAMIC_STRING == 1 of course. Paolo.
On 09/23/2011 03:59 PM, Paolo Carlini wrote: > On 09/23/2011 03:46 PM, Paolo Carlini wrote: >> On 09/23/2011 11:39 AM, JonY wrote: >>> Ping, any updates? >> I'm wondering if it wouldn't be cleaner to handle this in the >> appropriate config/os/ headers, something like (with a good comment >> before!): >> >> #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING >> #define _GLIBCXX_FULLY_DYNAMIC_STRING >> #endif > Even better would be changing the current infrastructure for this to > have a default (not fully dynamic) of zero, a set value of one, > undefined otherwise. I hope you got the basic point anyway, sorry about the confusion ;) I meant that if the user configuring doesn't pass anything to configure, then _GLIBCXX_FULLY_DYNAMIC_STRING remains undefined. Otherwise, zero is set in the acinclude.m4 procedure for no fully dynamic string and one for fully dynamic string. Then we have #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING #define _GLIBCXX_FULLY_DYNAMIC_STRING 1 #endif in the mingw config/os (with a good comment before!) and, in the basic_string.* headers we use: #if _GLIBCXX_FULLY_DYNAMIC_STRING == 1 This is a standard pattern in configuries, anyway... Paolo.
On 9/23/2011 22:15, Paolo Carlini wrote: > On 09/23/2011 03:59 PM, Paolo Carlini wrote: >> On 09/23/2011 03:46 PM, Paolo Carlini wrote: >>> On 09/23/2011 11:39 AM, JonY wrote: >>>> Ping, any updates? >>> I'm wondering if it wouldn't be cleaner to handle this in the >>> appropriate config/os/ headers, something like (with a good comment >>> before!): >>> >>> #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING >>> #define _GLIBCXX_FULLY_DYNAMIC_STRING >>> #endif >> Even better would be changing the current infrastructure for this to >> have a default (not fully dynamic) of zero, a set value of one, >> undefined otherwise. > I hope you got the basic point anyway, sorry about the confusion ;) > > I meant that if the user configuring doesn't pass anything to configure, > then _GLIBCXX_FULLY_DYNAMIC_STRING remains undefined. Otherwise, zero is > set in the acinclude.m4 procedure for no fully dynamic string and one > for fully dynamic string. Then we have > > #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING > #define _GLIBCXX_FULLY_DYNAMIC_STRING 1 > #endif > > in the mingw config/os (with a good comment before!) and, in the > basic_string.* headers we use: > > #if _GLIBCXX_FULLY_DYNAMIC_STRING == 1 > > This is a standard pattern in configuries, anyway... > > Paolo. > Ping, mingw.org OK with this?
On 09/25/2011 02:36 AM, JonY wrote: > On 9/23/2011 22:15, Paolo Carlini wrote: >> I hope you got the basic point anyway, sorry about the confusion >> ;) >> >> I meant that if the user configuring doesn't pass anything to >> configure, then _GLIBCXX_FULLY_DYNAMIC_STRING remains undefined. >> Otherwise, zero is set in the acinclude.m4 procedure for no fully >> dynamic string and one for fully dynamic string. Then we have >> >> #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING #define >> _GLIBCXX_FULLY_DYNAMIC_STRING 1 #endif >> >> in the mingw config/os (with a good comment before!) and, in the >> basic_string.* headers we use: >> >> #if _GLIBCXX_FULLY_DYNAMIC_STRING == 1 >> >> This is a standard pattern in configuries, anyway... >> >> Paolo. >> > > Ping, mingw.org OK with this? Please, enable this only for w64 flavor. We (mingw.org) are not building our libstdc++ with this configure option, and there are no plans to change it. I quote my reasoning: On 09/20/2011 11:56 PM, Cesar Strauss wrote: > On the one hand, according to comment 4 of [1], by using > --enable-fully-dynamic-string, all other users will miss a very good > optimization. On the other hand, these users of -static-libstdc++ are > mixing shared and static libraries, which isn't a good idea in > general anyway, is it? > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 Thanks, Cesar
On 09/25/2011 05:14 PM, Cesar Strauss wrote: > I quote my reasoning: On 09/20/2011 11:56 PM, Cesar Strauss wrote: >> On the one hand, according to comment 4 of [1], by using >> --enable-fully-dynamic-string, all other users will miss a very good >> optimization. On the other hand, these users of -static-libstdc++ are >> mixing shared and static libraries, which isn't a good idea in >> general anyway, is it? >> >> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 If you ask me, I totally agree. But I don't maintain any mingw target, thus, **if** the target maintainers want to do something like that I provided info about the correct way to do it. Paolo.
2011/9/25 Paolo Carlini <paolo.carlini@oracle.com>: > On 09/25/2011 05:14 PM, Cesar Strauss wrote: >> >> I quote my reasoning: On 09/20/2011 11:56 PM, Cesar Strauss wrote: >>> >>> On the one hand, according to comment 4 of [1], by using >>> --enable-fully-dynamic-string, all other users will miss a very good >>> optimization. On the other hand, these users of -static-libstdc++ are >>> mixing shared and static libraries, which isn't a good idea in >>> general anyway, is it? >>> >>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 > > If you ask me, I totally agree. But I don't maintain any mingw target, thus, > **if** the target maintainers want to do something like that I provided info > about the correct way to do it. > > Paolo. I see Cesar's point, and so my vote is for enabling it for w64 flavor only. We providing users the ability to build with static and want to avoid at least obvious issues here. I admit that people might mix here static and shared libraries, but that's in fact then more an issue of wrong use, which can be clarified by user-documentation for mingw-w64. Thanks Paolo for offering information for JonY for doing this the right way in libstdc++. Regards, Kai
On 9/25/2011 23:20, Paolo Carlini wrote: > On 09/25/2011 05:14 PM, Cesar Strauss wrote: >> I quote my reasoning: On 09/20/2011 11:56 PM, Cesar Strauss wrote: >>> On the one hand, according to comment 4 of [1], by using >>> --enable-fully-dynamic-string, all other users will miss a very good >>> optimization. On the other hand, these users of -static-libstdc++ are >>> mixing shared and static libraries, which isn't a good idea in >>> general anyway, is it? >>> >>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 > If you ask me, I totally agree. But I don't maintain any mingw target, > thus, **if** the target maintainers want to do something like that I > provided info about the correct way to do it. > > Paolo. > OK, I'll take some time to prepare the new patch, thanks for the help.
On 9/25/2011 11:14 AM, Cesar Strauss wrote: > On 09/25/2011 02:36 AM, JonY wrote: >> Ping, mingw.org OK with this? > > Please, enable this only for w64 flavor. We (mingw.org) are not > building our libstdc++ with this configure option, and there are no > plans to change it. > > I quote my reasoning: > > On 09/20/2011 11:56 PM, Cesar Strauss wrote: >> On the one hand, according to comment 4 of [1], by using >> --enable-fully-dynamic-string, all other users will miss a very good >> optimization. On the other hand, these users of -static-libstdc++ are >> mixing shared and static libraries, which isn't a good idea in >> general anyway, is it? >> >> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 Well, I disagree -- I think correctness (e.g. actually working, even if you are so gauche as to link statically) trumps working faster -- as a default setting. (And I'd rather see some actual numbers for comparison: how MUCH faster, under what workloads? Is it truly significant enough to put up with breakage when linking statically?) But...Cesar is mingw.org's gcc maintainer, not me. So what Cesar says, goes as far as mingw.org is concerned. I note one other comment in the referenced bugzilla thread, where Paolo mentions that the ABI will break for C++1x (libstdc++7?) anyway, and that in the "new" string implementation this issue will be not actually be an issue. Is that 2009 statement still operative? (I think we [mingw.org] still need to consider consolidating as many of the expected ABI changes as possible for the 4.7 release, since we already expect thiscall to become the default at that time, right? Even though 'switching' to --enable-fully-dynamic-string is no longer on the menu for i?86-pc-mingw32) -- Chuck
On 09/26/2011 02:34 AM, Charles Wilson wrote: > I note one other comment in the referenced bugzilla thread, where > Paolo mentions that the ABI will break for C++1x (libstdc++7?) anyway, > and that in the "new" string implementation this issue will be not > actually be an issue. Is that 2009 statement still operative? This for sure, it's impossible to implement the whole C++11 without breaking the ABI and it's in particular impossible to have a fully conforming reference counted <string>, we gonna have a new one anyway, similar to the current <ext/vstring.h>, which can't possibly be affected by those issues (by the way, the sooner we start testing that kind of code, the better) Anyway, about this specific issue I don't think I have much more to say, sorry. When you make up your mind just let me know, as a maintainer of the library I have no problems approving for 4.7 changes affecting only mingw, if the target maintainers ask. Paolo.
Index: libstdc++-v3/configure.ac =================================================================== --- libstdc++-v3/configure.ac (revision 178946) +++ libstdc++-v3/configure.ac (working copy) @@ -132,7 +132,15 @@ GLIBCXX_ENABLE_DEBUG([no]) GLIBCXX_ENABLE_PARALLEL([yes]) GLIBCXX_ENABLE_CXX_FLAGS -GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([no]) +case "$host" in + # Enable fully ynamic strings on mingw-w64 by default + i?86-w64-mingw* | x86_64-w64-mingw*) + GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([yes]) + ;; + *) + GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING([no]) + ;; +esac GLIBCXX_ENABLE_EXTERN_TEMPLATE([yes]) # Checks for operating systems support that doesn't require linking.