Re: Do symbols make sense for C++
"Bernhard R. Link" <firstname.lastname@example.org> writes:
> * Russ Allbery <email@example.com> [120127 22:30]:
>> This is probably the best summary of why a symbols file might be
>> useful. It helps catch cases where ABI compatibility is not maintained
>> without people being aware that this broke.
> On the other hand a symbols file can also make situations worse if the
> ABI changes and dpkg-gensymbols does not catch this case, as the
> dependencies are less strict then.
But this is true regardless; the same is true for shlibs. Either way, if
there was an incompatible change that the Debian maintainer didn't catch
that doesn't affect the exported symbols, you potentially lose. shlibs
does make it easier to just always bump the dependency to require a
matching upstream version, but you could in theory do the same thing with
>> I think this is probably the summary of my previous message: a lot of
>> those places don't seem as useful for C++ as for C, because ABI
>> compatibility is a lot more complex (and in some ways a lot harder to
>> maintain), so the equivalent of a shlibs bump is probably more
>> frequently the right thing to do.
> I think this argument can also mean that symbols files are more useful
> for C++ than for C: For C there are many ways to break the ABI
> incompatibly and compatibly without anything visible at symbol level.
> As C++ is more likely to show differences at symbol level in this cases
> the danger of cases where dpkg-symbols introduces wrong dependencies
> might be lower with C++.
It's true that C++ is much more likely to show symbol differences on at
least some types of changes (such as changing the function signature,
which with C++ is encoded in the symbol). However, C++ also introduces a
significant number of new ways to break compatibility that just don't
exist with C, some of which don't affect the symbols.
But, more to the point for practical concerns, there appears to be a truly
staggering amount of noise. What I'm seeing in these experiments is that
trying to track symbols for C++ libraries, at least for ones that aren't
using symbol export control, is that there are huge numbers of false
positives and spurious differences from changes in platform and compiler,
to the extent that one is awash in fixing symbol differences that don't
represent any interesting property of the library but are just odd
artifacts of how C++ is compiled.
I think, given this experience, that symbols for C++ libraries, at least
for the ones that I'm looking at, are a failed experiment, and I'm going
to back out of all of these changes and go back to just using shlibs.
That seems particularly indicated in this case, since upstream changes
SONAMEs for these libraries regularly and hence it's very rare for it to
be even possible to attempt running stable binaries with unstable
libraries or vice versa. There has not yet been a case where stable and
oldstable had the same SONAME for one of these libraries. That eliminates
much of the advantage of symbols; the remaining advantage is detecting ABI
breaks, but since upstream changes SONAME regularly, most of the damage
from ABI breaks would be limited in this case anyway.
Somewhat more controversially, so I'd like to get a debian-devel feeling
on this, I think the Lintian info tag for a library using shlibs instead
of symbols should be suppressed if the library is a C++ library (probably
most easily detected by seeing if it depends on libstdc++). There *are*
excellent tools from the KDE team available, but even with those tools,
this turned into something I wasn't willing to deal with, and I'm a fairly
experienced packager. I have a hard time imagining the average Debian
packager is going to be equipped to deal with this properly, and for most
C++ libraries just using shlibs and dh_makeshlibs -V to conservatively set
the dependencies is probably the best tradeoff of usability against
If packagers are willing to do more, more power to them! Some C++
libraries may be amenable to it. But a Lintian tag implies that packagers
who are not doing this are doing something (minorly) wrong, and I don't
think that's actually the case.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>