Patchwork --enable-dynamic-string default for mingw-w64

login
register
mail settings
Submitter JonY
Date Sept. 19, 2011, 10:43 p.m.
Message ID <4E77C57F.40808@users.sourceforge.net>
Download mbox | patch
Permalink /patch/115398/
State New
Headers show

Comments

JonY - Sept. 19, 2011, 10:43 p.m.
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?
Kai Tietz - Sept. 20, 2011, 5:59 a.m.
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
JonY - Sept. 20, 2011, 1:20 p.m.
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?
Charles Wilson - Sept. 20, 2011, 1:52 p.m.
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.
Kai Tietz - Sept. 20, 2011, 2:12 p.m.
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
xunxun - Sept. 20, 2011, 2:15 p.m.
于 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.
JonY - Sept. 20, 2011, 2:55 p.m.
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.
Pedro Alves - Sept. 20, 2011, 3:03 p.m.
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?
Charles Wilson - Sept. 20, 2011, 3:29 p.m.
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
Cesar Strauss - Sept. 21, 2011, 2:56 a.m.
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
xunxun - Sept. 21, 2011, 9:08 a.m.
于 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...  )
JonY - Sept. 23, 2011, 9:39 a.m.
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?
Paolo Carlini - Sept. 23, 2011, 1:46 p.m.
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.
JonY - Sept. 23, 2011, 1:59 p.m.
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.
Paolo Carlini - Sept. 23, 2011, 1:59 p.m.
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.
Paolo Carlini - Sept. 23, 2011, 2:15 p.m.
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.
JonY - Sept. 25, 2011, 5:36 a.m.
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?
Cesar Strauss - Sept. 25, 2011, 3:14 p.m.
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
Paolo Carlini - Sept. 25, 2011, 3:20 p.m.
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.
Kai Tietz - Sept. 25, 2011, 4:36 p.m.
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
JonY - Sept. 25, 2011, 11:20 p.m.
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.
Charles Wilson - Sept. 26, 2011, 12:34 a.m.
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
Paolo Carlini - Sept. 26, 2011, 1:06 a.m.
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.

Patch

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.