This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3] Fix second half of libstdc++/6745
On Tuesday, November 19 2002, "Phil Edwards" wrote to "Jonathan Lennox, Paolo Carlini, libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org" saying:
> On Tue, Nov 19, 2002 at 03:44:41PM -0500, Jonathan Lennox wrote:
> > This would be an ABI change, though -- it would add two new exported symbols
> > to libstdc++. What's the policy on this? It wouldn't hurt old binaries
> > dynamically linking with new libstdc++, but the opposite wouldn't work.
>
> That's not a breaking change, though: the symbol wouldn't be exported,
> so new binaries wouldn't be looking for it in first place.
Just to clarify why this is so:
The only users of the template specializations of my hypothetical
__streambuf_is_stdin_and_tty function would be the explicit instantiations
of __copy_streambufs<char> and __copy_streambufs<wchar_t> in
libstdc++-v3/src/streambuf-inst.cc. Since these types are declared "extern
template", they won't be emitted in user code, and any instantiations of
__copy_streambufs for user types would pick up the generic (trivial) version
of __streambuf_is_stdin_and_tty from the header file. Thus, the symbols for
the explicit specializations don't need to be exported.
Is that right? It feels somewhat fragile to me. In particular, it's a more
intimate dependency on the GCC-specific "extern template" extension than I
believe libstdc++ currently requires -- right now, it's only an optimization,
not something necessary for correctness. (For example, currently, you can
copy libstdc++ header files to a local include directory and comment out the
"extern template" declarations, and get versions of the libstdc++ classes
with debugging information.)
--
Jonathan Lennox
lennox at cs dot columbia dot edu