Re: Do symbols make sense for C++
On Wed, Jan 25, 2012 at 10:53:04PM -0800, Russ Allbery wrote:
> I'm currently working on the Policy modification to document (and
> recommend) use of symbols instead of shlibs, but I'd only personally used
> symbols with C libraries. Today I decided that I should try adding a
> symbols file to a C++ library, particularly if I'm going to recommend
> everyone do it. I tried this exercise with xml-security-c, which is, I
> think, a reasonably typical C++ library. Not the sort of core C++ library
> that would sit at the center of the distribution, but a random software
> package that's in Debian because other things use it.
>
> The experience was rather interesting, and I ended up uploading the new
> version without a symbols file and continuing to just use shlibs. That's
> for the following reasons:
>
> 1. The generated symbols file was HUGE. Hundreds of lines. This is a
> marked difference from the typical C symbols file, which is of quite
> manageable size. Some of that is that the library provides a lot of
> different classes, but some of it is that C++ just generates a lot of
> exported symbols. There's no way that I could do what I would do with
> a C library and understand those symbols, why they're there, and
> whether they are likely to have changed between revisions.
>
> 2. Generating a reasonable symbols file was a pain. Generating an
> unreasonable symbols file that just contains all of the mangled symbols
> is largely mechanical and uninteresting, but that symbols file doesn't
> seem to me to convey useful information. So I did some scripting to
> translate the symbols back with c++filt, and add (c++) tags, and then
> try to understand what I was looking at and figure out whether I should
> sort the symbols list because the default sort is by mangled name,
> which is meaningless. This is a rather unappealing process. It's not
> particularly difficult, but it's very awkward and feels like it's
> missing vital tools.
>
> 3. The resulting symbols file is incomprehensible to someone without
> strong knowledge of C++. It's full of opaque entries that don't make
> sense to the non-C++ programmer, wihch I suspect is a substantial
> number of people who package C++ libraries for Debian. I know enough
> C++ from school that I can evaluate security fixes, make simple
> patches, and review upstream changes, and I think that's all that
> should be needed to package things for Debian. But I'm deeply
> uncomfortable producing a symbols file on my own that contains entries
> for things that I know nothing about and cannot evaluate when they've
> last changed, like "non-virtual thunk to FooClass::~FooClass@Base".
>
> 4. Once I had a symbols file that resulted in a successful build and that
> I could have uploaded, I started thinking about how I was going to
> maintain it. With a C program, I would change the symbols file
> versions when the underlying function implementation changes in a way
> that may not offer eqiuvalence, similar to bumping shlibs. I realized
> that I was going to have no idea when that happened, and the only way
> that I would maintain the symbols file would be to either trust
> upstream to maintain ABI equivalence and therefore only change the
> symbols file when upstream changes the SONAME, or not trust upstream to
> maintain ABI equivalence and therefore change all the versions with
> each new upstream release. That gives me exactly the same semantics as
> a shlibs file, so what's the point in having a symbols file?
>
> 5. The exported symbols of the library contained many symbols that
> obviously weren't really from that library, but instead were artifacts
> of the C++ compilation process, things like instantiations of
> std::vector. Do those go into the symbols file? Do they change from
> architecture to architecture? If they disappear again, is that
> actually an ABI break? How do I know? It's all very mysterious, and
> while shlibs provides the same semantics as just ignoring this, at
> least I'm not then including in the package data, generated by me,
> things that I'm just blindly ignoring.
6. Different levels of optimizations lead to different exported symbols,
depending on whether some things are inlined or not. Different
architectures may also have different exported symbols.
Mike
Reply to: