http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
Pawel Sikora changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #17 from Pawel Sikora 2012-03-06 21:04:40
UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > i've found the core issue for problem mentioned in comment 12.
> > the --disable-nls configure option causes missing x64 .dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #16 from joseph at codesourcery dot com 2012-03-06 20:19:24 UTC ---
I think --disable-nls should be purely a *host* configure option - it's a
bug if it affects anything at all about libstdc++.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #15 from Jonathan Wakely 2012-03-06
18:43:19 UTC ---
(In reply to comment #14)
> i've found the core issue for problem mentioned in comment 12.
> the --disable-nls configure option causes missing x64 .dll exports
> but this is imho a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
Pawel Sikora changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #12 from Pawel Sikora 2012-03-04 19:36:30
UTC ---
with current 4.6.4 i've noticed a new undefined reference
during boost_rexeg.dll linking:
(...)
Creating library file:
bin.v2/libs/regex/build/gcc-mingw-4.6.4/release/inlining-on/targ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #11 from Pawel Sikora 2012-01-10 19:56:08
UTC ---
(In reply to comment #10)
> Thanks guys. This looks good, and is in trunk.
>
> Pawel, thanks for noticing this. Please note that namespace versioning was
> updated for 4.7.x to bring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #10 from Benjamin Kosnik 2012-01-09
23:42:01 UTC ---
Thanks guys. This looks good, and is in trunk.
Pawel, thanks for noticing this. Please note that namespace versioning was
updated for 4.7.x to bring this experimental feature up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #9 from Benjamin Kosnik 2012-01-09
23:39:30 UTC ---
Author: bkoz
Date: Mon Jan 9 23:39:22 2012
New Revision: 183043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183043
Log:
2012-01-09 Kai Tietz
PR libstc++/51673 par
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #8 from Kai Tietz 2011-12-28 21:24:25
UTC ---
(In reply to comment #7)
> please apply following obvious patch:
>
> --- gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver.orig
>
> 2011-12-28 12:43:50.0 +01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #7 from Pawel Sikora 2011-12-28 19:51:55
UTC ---
please apply following obvious patch:
--- gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver.orig
2011-12-28 12:43:50.0 +0100
+++ gcc-4.6.0/libstdc++-v3/con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #6 from Pawel Sikora 2011-12-28 16:06:47
UTC ---
btw, i've tested the default allocator with std::__7 and the i686-pc-mingw32
toolchain works fine while the x86_64-pc-mingw32 reports undefined reference to
.text$_ZN9__gnu_cxx3__713ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #4 from Pawel Sikora 2011-12-27 09:32:11
UTC ---
i'm using the mt allocator for large std containers with small fixed-size
objects. the mt's flexible pool configuration and alloc/free speed are
an advantage over the simple new (malloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #3 from Paolo Carlini 2011-12-24
14:37:23 UTC ---
I don't have a strong opinion, but it's a bit hard to make a choice: the legacy
HP/SGI pool still makes sense; mt too, has some problems, but we spent quite a
bit of time on it, works
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #2 from Jonathan Wakely 2011-12-24
14:11:00 UTC ---
Do we want to define mt_allocator in v7?
Is it worth keeping all the ext allocators in the library forever?
If not, we could conditionally define them only when configured for v6, w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
Paolo Carlini changed:
What|Removed |Added
CC||bkoz at gcc dot gnu.org,
18 matches
Mail list logo
