Re: Symbols and C++ inline constructor
Thomas Weber <tweber@debian.org> writes:
> On Fri, Jan 06, 2012 at 05:14:32PM -0800, Russ Allbery wrote:
>> If it's a private symbol not intended to be used by clients and that
>> wouldn't naturally be used by clients, you can mark it optional in the
>> symbols file (symbol tag optional), and then the symbols generation
>> won't care if it appears and disappears.
> This doesn't answer my question, does it? I mean, your statement is true
> for whatever symbol that appears in the symbol file. My question is
> about inlined class methods specifically and the fact that the compiler
> might change its opinion about them with even minor version bumps.
The question I think we have to ask here is whether the disappearance of
the declared-inline constructor from the exported symbols of the library
would ever break a package that was linked against it. My guess is no; my
guess is that while the compiler may choose whether or not to provide a
non-inline version of the symbol in the library, software built against
the library will always inline the constructor and not generate a
reference to the symbol. That was the assumption under which I suggested
using optional. But I don't know enough about C++ to be sure that I'm
right about this.
If it is the case that binaries linked against the library may declare a
reference to that symbol, then the symbol is indeed part of the ABI, and
the build failing because the symbol disappeared indicates a real bug in
the package. If the symbol randomly appears and disappears but is needed
by clients, that would be a real bug in g++ so far as I can tell, since it
makes it impossible to safely maintain the library ABI. But this seems
unlikely to me, since this would be a rather huge thing for the g++
developers to miss.
If the behavior is just different on different architectures but
consistent on an architecture, the right solution may be to use symbol
tags to provide an architecture list rather than marking it optional, so
that we ensure the symbol continues to be present on those architectures.
> One of the things that I find frustrating is the total lack of reliable
> and complete documentation about symbols; yet library maintainers are
> expected to keep the symbols file sane.
> Example from dpkg-gensymbols (5):
> "For example, most of C++ template instantiations fall into this
> category" (it's talking about optional symbols here).
> So, which template instantiations are *not* safe to be tagged as
> optional? This is a different question, but I have quite some template
> instantiations in the symbol file as well.
symbols was originally developed for C libraries, and C++ really wasn't
supported originally. I think you're still seeing the remnants of that.
Part of the problem is that the behavior of C++ is obscure, since C++ is a
*far* more complex language, and I don't think that the people who have
worked on this support are necessarily C++ experts. What would be very
helpful would be documentation written by someone who *is* a C++ expert
and who understands how library and symbol exports work with C++.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: