Hi,
On Tue, Oct 14, 2014 at 11:53:34AM -0700, Steve Langasek wrote:
> I have no idea what the recommendation on that wiki page is supposed to
> mean. "Symbol versioning" is something entirely different from symbols
> files, anyway. That page has AFAICS had zero peer review in Debian
> regarding its contents.
Sooo, were is the properly reviewed, comprehensive and agreed upon
documentation on symbol files best practices for C++ libs? ;)
> There are some practical problems regarding symbols files for C++ libraries,
> which make it debatable whether these are actually a good idea in the
> current implementation.
Yes.
> But I am not convinced this is actually a matter for libixion upstream to
> fix. I remember (but cannot currently find references to) discussions about
> the fact that g++ needs to output these weak symbols for destructors etc.,
> and that it's not possible to mask them in the exported ABI without adverse
> consequences. I think you'll want a plan for this MIR that doesn't rely on
> these weak symbols going away.
Yes, C++ symbols are a mess -- mostly because of things like smart pointers and
exceptions (oh, and nonstandardized name mangling). My personal opinion on that
is that a C++ library caring about its ABI should take care not to expose any
of that (and by expansion: that it only makes sense to care about symbol files
for C++, once you took care of that in the first place).
> Has the *soname* changed with every release? It's fine to say that the ABI
> is not stable yet. Symbols files are not about preventing ABI changes,
> they're about preventing ABI *breakages* to ensure that any ABI changes are
> done in an orderly fashion.
Its complicated. But yes, the soname so far changed with releases. In fact, we
can expect the library _name_ to change with upstream "updates". That makes the
ABI breaks extremely unlikely as linkers will unlikely get confused by a lib
with a different name. (And yeah: that brings its own range of troubles, and I
dont know why upstream thinks its a good idea.)
> As this is already an embedded code copy today and there are no other
> reverse-dependencies, I don't think it's a problem to continue this way
> through 14.10. Ideally we wouldn't have libixion in the 14.10 archive at
> all then, if we're arguing that nothing else should be using it; but that's
> not critical.
Yeah. The tragedy is that even LibreOffice doesnt need libixion, it only needs
liborcus. But the generic standalone liborcus that Debian builds also does
include the _optional_ libixion functionality (which LibreOffice internally
does not). As we need to MIR build-deps in Ubuntu, this means we MIR a library
that has no client at all: libixion is pulled into main by LibreOffice without
LibreOffice actually every using it.
The road to hell is paved with good intentions (well, and policies).
Anyway, Im happy with the conclusion to just use libs internally in LibreOffice
in these cases.
Best,
Bjoern
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
