http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-01-17
Ever Confirmed|0 |1
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-17
17:32:04 UTC ---
(In reply to comment #4)
> I didn't know about --enable-symvers=gnu.
--enable-symvers=gnu is the default configuration (on GNU/Linux)
--enable-symvers=gnu-versioned-namespace is the alternative, which puts
std::foo in an inline namespace so it mangles as std::__7::foo but can be used
as std::foo.
> The two sets of printers can still share code. For example, we could move
> most of the code to libstdcxx/printers.py and have the v6 and v7 variants
> import that.
OK, that sounds like the best option for now.
> I am not sure what the best approach is for the current situation.
> What is the purpose of --enable-symvers=gnu?
In a future lib version we can preserve backwards compatibility for
std::__7::foo by keeping symbol that in the .so, but add an incompatible
std::__8::foo which is the default when users say std::foo.
> How different is the v7 library?
Currently not at all, IIRC.
> Are there other possible configurations (configure- or user-compile-time)
> that affect printers that we haven't already accounted for?
Not that I can think of.
(In reply to comment #5)
> i've another issue vith v7 and c++0x - std::list
That appears to be just v7 and -D_GLIBCXX_DEBUG, unrelated to c++0x
