Re: libkpathsea3 incompatibility problem
Paul Hampson writes:
> I'm inclined towards #1, since I don't like so version creep if we can
> avoid it... Is upstream going to support a shared libkpathsea3 any
> time soon? (IE Will they ever stop breaking the interface?)
> On the other hand, if we could convince them to use whatever so version
> we're upto when they decide to lock down the interface, then creep
> ahead!
> Oh, BTW, are they breaking the API here? Or is it something else
> happening so that a simple recompile _will_ fix those packages?
> eg API extension (which I understood to not cause segfaults)
Perhaps I should add a few notes on what upstream thinks it's doing.
Kpathsea evolved out of a set of utility functions without ever being
designed as a standalone library. This shows in a number of ways: (i)
there is no clear separation between internal and external interfaces,
(ii) the interfaces do not restrict themselves to simple namespace,
(iii) neither do the headers, (iv) the ABI exposes opaque datatypes,
(v) the sources are intimately intertwined with the web2c sources.
As a result, kpathsea doesn't function nearly as well as it should
when treated as standalone library. The best solution for a security
issue required adding members to a structure. The structure in
question is stored in an array that programs address through an
index. So the ABI changed in an incompatible way. The API (to the
extent that it is defined) remained the same.
Really solving all these problem with kpathsea requires rewriting
large parts of it, and involves changes to be ABI and API. So the
answer to "will they ever stop breaking the interface" is (hopefully)
yes, but it will involve a transition to a new interface.
The good news is that upstream kpathsea now uses libtool instead of
its home-grown hack, which might make things easier for you, if you
insist on making it a shared library despite contrary advise. The bad
news is that the API was changed (again) by adding some new functions.
--
Olaf Weber
(This space left blank for technical reasons.)
Reply to: