[v3] libstdc++/36104 namespace versioning, revisited

[Benjamin Kosnik]

This patch makes --gnu-versioned-namespace work again, ie fixes
libstdc++/36104. Using this configure flag results in a libstdc++.so
binary that is incompatible with the current ABI, but potentially useful
in that all exported symbols are prefixed with a version _6, via
judicious use of inline namespaces.

This approach is first described here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html

There are some QoI issues remaining. Since this patch is already quite
large I'll do them as follow ups. Known issues:

1) the exports file has not been updated!! Amazingly, it still works
after 3+ years of bitrot. I mean to do this, and look at typeinfo
exports and VTT exports in a more systematic way. 

Actually, it looks like some issues (quality tests fail) with hash
exports for debug mode. 

2) c++config.h, and combined modes (ie debug and parallel, versioned
and anything) are not super consistent at the moment. I'm hoping to make
this more clear, clean up the header file, and add docs.

3) some of the headers move around.
Now, libsupc++ header files that are not public are in nested
directory named bits and marked as private in a consistent manner as:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01498.html

It's my belief that all libstdc++ includes for 4.6.0 are in a consistent
state now. Check the install directory and let me know if anything
looks fishy.

4) what header files are installed when libstdc++ is configured as
hosted vs. freestanding does not change. Should it? This provides
infrastructure (ie a bits subdir for libsupc++ includes) such that it
may be possible to do this with more granularity (ie, correctly) in the
future. I'm surprised to see things like bits/atomic_word.h as header
deps for some libsupc++ includes. But I didn't want to try and solve
this problem today, and this patch makes no substantive changes in this
area.

5) docs for headerfile moves, namespace association to inline
namespaces are not finished.

It was fun to do this again (even with the all the strange build
hacking). This is a pretty elegant idea, and it's actually not that
hard to keep track of things this way.

tested x86_64/linux

-benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20110114-3.patch
Type: text/x-patch
Size: 96183 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20110115/fe220016/attachment.bin>