https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
Bug 24196 depends on bug 24882, which changed state.
Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
Jackie Rosen changed:
What|Removed |Added
CC||jackie.rosen at hushmail dot
com
--- Comm
--- Comment #26 from steven at gcc dot gnu dot org 2010-06-01 20:50 ---
May become relevant to GCC itself again if GCC wants to link to a static
libstdc++
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #25 from davek at gcc dot gnu dot org 2010-03-20 19:46 ---
This was fixed on 2009-11-30 by r.154853, which enabled libstdc++ as a DLL on
windows platforms.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #24 from paolo dot carlini at oracle dot com 2009-10-25 05:50
---
The Snow Leopard case is different, apparently they decided to build the system
compiler with --enable-fully-dynamic-string and then that shows up everywhere,
see 41645. As far as we can understand so far, peo
--- Comment #23 from johnw at gnu dot org 2009-10-25 05:50 ---
I should also mention, this discrepancy only occurs when _GLIBCXX_DEBUG=1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #22 from johnw at gnu dot org 2009-10-25 05:43 ---
A little more data:
With the stock compiler, g++ 4.2.1:
vulcan /tmp $ otool -L bug
bug:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibili
--- Comment #21 from johnw at gnu dot org 2009-10-25 05:40 ---
I'm actually getting this same error on Snow Leopard (Mac OS X 10.6.0). It's
pretty easy to reproduce with Boost (1.40):
#include
#include
#include
int main()
{
std::ostringstream buf;
boost::variant data;
data =
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-06-29
15:12 ---
I think the best solution to this problem is to enable libstdc++ as a DLL, and
export _S_empty_rep from it. Then every C++ DLL and EXE will link against
libstdc++ and they'll all import the exact same i
--- Comment #19 from paolo dot carlini at oracle dot com 2009-04-25 19:16
---
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 implement
--- Comment #18 from ktietz at gcc dot gnu dot org 2009-04-25 19:10 ---
(In reply to comment #16)
> Ok. Hopefully, before the end of this week I can tell you something
> trustworthy
> about binary compatibility.
>
Have you found a solution for it? On w64 target 4.4 (and 4.5) the probl
--- Comment #17 from dannysmith at users dot sourceforge dot net
2006-07-06 01:06 ---
On mingw32 the testcase will succeed on trunk if libstdc++ (and libgcc) are
built as dlls. Wouldn't that be the preferred solution? It also solves very
similar problems with EH data.
Danny
--
--- Comment #16 from pcarlini at suse dot de 2006-05-17 10:09 ---
Ok. Hopefully, before the end of this week I can tell you something trustworthy
about binary compatibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #15 from dave dot korn at artimi dot com 2006-05-17 10:03
---
I'm new maintainer for Cygwin gcc. I'll be rolling a release with the patch
Paolo proposed rather than using the configure option, although if binary
compatibility problems do crop up I'll look at the second rout
--- Comment #14 from pcarlini at suse dot de 2005-10-07 17:05 ---
(In reply to comment #13)
> Both the simple testcase and the program I am working on work fine with your
> patch.
Thanks. Actually, I have to think a bit more about the idea. I'm not sure that
there are binary compatibili
--- Comment #13 from ptsekov at gmx dot net 2005-10-07 12:13 ---
Both the simple testcase and the program I am working on work fine with your
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #12 from pcarlini at suse dot de 2005-10-06 17:01 ---
I'm attaching a first draft implementing what I have in mind. Assuming testing
goes well, the issue of binary compatibility should be evaluated: whereas the
library-ABI is preserved, in general object code build with the c
--- Comment #11 from pcarlini at suse dot de 2005-10-06 17:00 ---
Created an attachment (id=9911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9911&action=view)
First draft vs 3_4-branch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #10 from pcarlini at suse dot de 2005-10-06 12:53 ---
(In reply to comment #9)
> I will test any patch that resolves the issue. In any case the final decision
> will be that of the Cygwin gcc maintainer. But what you suggests sounds better
> than just using --enable-fully-dyn
--- Comment #9 from ptsekov at gmx dot net 2005-10-06 12:50 ---
I will test any patch that resolves the issue. In any case the final decision
will be that of the Cygwin gcc maintainer. But what you suggests sounds better
than just using --enable-fully-dynamic-string.
--
http://gcc.g
--- Comment #8 from pcarlini at suse dot de 2005-10-06 11:50 ---
I'm thinking that another possibility would be avoiding only *part* of the
optimization scheme that relies on _S_empty_rep_storage, that is return to
the behavior pre-2003-06-13. The empty string object would be reference
c
--- Comment #7 from pcarlini at suse dot de 2005-10-05 10:20 ---
PS: if you are going to experiment with _GLIBCXX_FULLY_DYNAMIC_STRING defined
by default, I would suggest also testing the performance impact of the
following:
change the default constructor to allocate memory on the heap n
--- Comment #6 from pcarlini at suse dot de 2005-10-05 08:50 ---
(In reply to comment #5)
> Paolo, I guess it is obvious to anyone around that _S_empty_rep_storage is
> there to speed up things. What is not obvious to Cygwin users is that this
> optimization actually makes their programs
--- Comment #5 from ptsekov at gmx dot net 2005-10-05 08:36 ---
Paolo, I guess it is obvious to anyone around that _S_empty_rep_storage is
there to speed up things. What is not obvious to Cygwin users is that this
optimization actually makes their programs crash. And let me assure you th
--- Comment #4 from pcarlini at suse dot de 2005-10-04 20:53 ---
(In reply to comment #3)
> Is there any specific reason that _GLIBCXX_FULLY_DYNAMIC_STRING is not defined
> on Cygwin ?
Not having really looked into this issue, the reason is however obvious: the
use of _S_empty_rep_stora
--- Comment #3 from ptsekov at gmx dot net 2005-10-04 19:28 ---
Is there any specific reason that _GLIBCXX_FULLY_DYNAMIC_STRING is not defined
on Cygwin ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-04 19:10 ---
Maybe it is better just to support shared (dynamic) Libraries on win32 too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #1 from gerrit at gcc dot gnu dot org 2005-10-04 19:08 ---
Created an attachment (id=9877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9877&action=view)
Testcase which demostrates the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
28 matches
Mail list logo
