2011/10/13 Paolo Carlini :
>>
>> Ping, did this go in trunk already?
>
> I would be surprised to see this happening if nobody like you or Kai actually
> does the commit ;)
>
> P
I will take care to apply it.
Kai
On Thu, Oct 13, 2011 at 9:47 AM, Paolo Carlini wrote:
>>
>> Ping, did this go in trunk already?
>
> I would be surprised to see this happening if nobody like you or Kai actually
> does the commit ;)
>
> P
>
Does Jon have commit access?
>
> Ping, did this go in trunk already?
I would be surprised to see this happening if nobody like you or Kai actually
does the commit ;)
P
On 10/8/2011 23:50, Kai Tietz wrote:
> 2011/10/8 Paolo Carlini:
>> Hi,
>>
>>> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
>>> attached.
>>
>> Patch is still ok with me, if Kai is ok with it (remember for next time:
>> regenerated files are not posted, are just a distracti
2011/10/8 Paolo Carlini :
> Hi,
>
>> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
>> attached.
>
> Patch is still ok with me, if Kai is ok with it (remember for next time:
> regenerated files are not posted, are just a distraction)
>
> Paolo
Ok, by me, too.
Thanks,
Kai
Hi,
> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
> attached.
Patch is still ok with me, if Kai is ok with it (remember for next time:
regenerated files are not posted, are just a distraction)
Paolo
>
Ok, fixed it, I made a very dumb mistake in configure.host, new patch
attached.
Changelog:
2011-10-08 Jonathan Yong
* configure.host: Use config/os/mingw32-w64 instead of
config/os/mingw32 if vendor key is "w64".
* config/os/mingw32-w64: Duplicate from config/os/mingw32
On 10/1/2011 22:31, JonY wrote:
> On 10/1/2011 19:16, Paolo Carlini wrote:
>> Hi,
>>
>>> Thanks, but I am having problems sending a proper diff with the
>>> regenerated files, they have a lot of unrelated, even if I made sure I
>>> am using autoconf 2.64 and automake 1.11.1.
>>
>> To be clear, rege
2011/10/1 Pedro Alves :
> On Saturday 01 October 2011 12:15:42, JonY wrote:
>> On 10/1/2011 18:33, Pedro Alves wrote:
>> > On Saturday 01 October 2011 07:03:35, JonY wrote:
>> >> Hi,
>> >>
>> >> I followed Paolo's suggestion with the os_defines.h trick. I duplicated
>> >> os/mingw32/ to os/mingw32-
On 10/1/2011 19:16, Paolo Carlini wrote:
> Hi,
>
>> Thanks, but I am having problems sending a proper diff with the
>> regenerated files, they have a lot of unrelated, even if I made sure I
>> am using autoconf 2.64 and automake 1.11.1.
>
> To be clear, regenerated files should **not** be part of
On Saturday 01 October 2011 12:15:42, JonY wrote:
> On 10/1/2011 18:33, Pedro Alves wrote:
> > On Saturday 01 October 2011 07:03:35, JonY wrote:
> >> Hi,
> >>
> >> I followed Paolo's suggestion with the os_defines.h trick. I duplicated
> >> os/mingw32/ to os/mingw32-w64/ for this to work, since the
Hi,
> Thanks, but I am having problems sending a proper diff with the
> regenerated files, they have a lot of unrelated, even if I made sure I
> am using autoconf 2.64 and automake 1.11.1.
To be clear, regenerated files should **not** be part of the patch submitted
for review, but should definit
On 10/1/2011 18:33, Pedro Alves wrote:
> On Saturday 01 October 2011 07:03:35, JonY wrote:
>> Hi,
>>
>> I followed Paolo's suggestion with the os_defines.h trick. I duplicated
>> os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
>> built-in defines to tell the 2 apart unless y
On 10/1/2011 18:08, Paolo Carlini wrote:
> On 10/01/2011 11:48 AM, JonY wrote:
>> On 10/1/2011 17:15, Paolo Carlini wrote:
>>> On 10/01/2011 08:03 AM, JonY wrote:
Hi,
I followed Paolo's suggestion with the os_defines.h trick. I duplicated
os/mingw32/ to os/mingw32-w64/ for this
On Saturday 01 October 2011 07:03:35, JonY wrote:
> Hi,
>
> I followed Paolo's suggestion with the os_defines.h trick. I duplicated
> os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
> built-in defines to tell the 2 apart unless you include some headers
> like _mingw.h.
Are
On 10/01/2011 11:48 AM, JonY wrote:
On 10/1/2011 17:15, Paolo Carlini wrote:
On 10/01/2011 08:03 AM, JonY wrote:
Hi,
I followed Paolo's suggestion with the os_defines.h trick. I duplicated
os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
built-in defines to tell the 2 ap
On 10/1/2011 17:15, Paolo Carlini wrote:
> On 10/01/2011 08:03 AM, JonY wrote:
>> Hi,
>>
>> I followed Paolo's suggestion with the os_defines.h trick. I duplicated
>> os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
>> built-in defines to tell the 2 apart unless you include s
On 10/01/2011 08:03 AM, JonY wrote:
Hi,
I followed Paolo's suggestion with the os_defines.h trick. I duplicated
os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
built-in defines to tell the 2 apart unless you include some headers
like _mingw.h.
Patch attached, comments?
On Sat, Oct 1, 2011 at 9:03 AM, JonY wrote:
> Hi,
>
> I followed Paolo's suggestion with the os_defines.h trick. I duplicated
> os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
> built-in defines to tell the 2 apart unless you include some headers
> like _mingw.h.
>
> Patch
Hi,
I followed Paolo's suggestion with the os_defines.h trick. I duplicated
os/mingw32/ to os/mingw32-w64/ for this to work, since there aren't any
built-in defines to tell the 2 apart unless you include some headers
like _mingw.h.
Patch attached, comments?
Index: configure.host
=
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
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 reason
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
>>> opt
2011/9/25 Paolo Carlini :
> 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
>>> optimizatio
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-li
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.
>> Otherw
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/ heade
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!):
#ifnde
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 _GLIBC
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
> #defin
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/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
于 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 st
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:
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 n
On 9/20/2011 10:12 AM, Kai Tietz wrote:
> 2011/9/20 Charles Wilson :
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"
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.
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 thiscal
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
于 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
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
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/co
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
> ==
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
===
43 matches
Mail list logo
