This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
- From: "ktietz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 11 Mar 2012 18:35:59 +0000
- Subject: [Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
- Auto-submitted: auto-generated
- References: <bug-52540-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
--- Comment #10 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-03-11 18:35:59 UTC ---
(In reply to comment #9)
> Then this is a very old issue, isn't it? Why nobody noticed it before? To be
> clear, in debug-mode we don't use extern templates only for basic_string
> (because _GLIBCXX_EXTERN_TEMPLATE becomes -1 when _GLIBCXX_DEBUG is defined),
> all the other facilities remain the same still use extern tamplate. This is in
> order to enable debug-mode checks also at -O0 for basic_string. Now, I don't
> see why a few less extern template can make a difference on mingw in terms of
> correctness of use_facet or anything else, but if that's really the case due to
> fundamental limitations somehwhere, we can trade it for the -O0 basic_string
> checks on the affected systems, I have no problems with that (note that,
> AFAICS, the problem will not go away with a new C++11 conforming string class,
> unless we decide to not export from the .so parts of basic_string)
I tested it by making sure that _GLIBCXX_EXTERN_TEMPLATE is defined to 1 even
for _GLIBCXX_DEBUG (and PROFILE) mode.
Indeed the test passes now without issue. The underlying issue here seems to
be that DLL-code and non-external code aren't sharing all underlying data. For
ELF this gets resolved, as ELF doesn't have final link for .so, but for PE it
gets finally linked on DLL generation.