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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Jan 14, 2011 at 4:29 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> 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.
>

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47865


-- 
H.J.