symbols of spandsp0.0.6~pre18 and SONAME

[Kilian Krause]

Hi Steve,

On Sun, Jul 03, 2011 at 08:45:11PM +0800, Steve Underwood wrote:
> On 07/03/2011 06:20 PM, Kilian Krause wrote:
> >
> >while trying to update the spandsp package in Debian from 0.0.6~pre12 to
> >0.0.6~pre18 we've found that there is a number of symbols missing:
> >- bitstream_flush2 at Base
> >- bitstream_get2 at Base
> >- bitstream_put2 at Base
> >- make_tone_gen_descriptor at Base
> >- modem_echo_can_create at Base
> >- t4_get_transfer_statistics at Base
> >- t4_tx_set_min_row_bits at Base
> >- v22bis_current_bit_rate at Base
> Through the 0.0.6 series I have been trying to keep things fairly
> consistent, but I took the liberty to modify incomplete modules,
> which were not fully functional, since I didn't expect anyone would
> be using them.

that's great news! ;-)


[interesting list with internal deleted]
> 
> The V.22bis modem isn't as stable I'd like, so I don't consider it
> production grade. That made it a candidate for change.

If you mean that "isn't stable" also means it's not being used by other
programs we maintain (currently only asterisk and YATE 2 which will be
bumped to 3 in the near future) that means we can ignore this I guess.

> >
> >While trying to shorten the list to only the officially exported ones using
> >CFLAGS=-fvisibility=hidden -fvisibility-inlines-hidden
> >the list of symbols went down to zero.
> >
> >What's your recommended way of identifying the "official" ABI so that we can
> >update our automatic symbols tracking to make sure our packages do export
> >the same ABI throughout all versions using the same package name (and
> >updating that once the ABI is broken)?
> Since I usually make en effort to keep well used APIs stable, and
> feel free to take liberties with things which are works in progress,
> I am not sure. There will certainly be some minor breakage in the
> FAX APIs soon, and I am preparing to add functionality which doesn't
> quite fit without some changes. The version will be clearly
> different when I start releasing test versions of that stuff.
> 
> A serious problem with updates is people love to expose the
> internals of the spandsp, and statically allocate the major
> structures. I can't keep those structures 100% stable, and they do
> change in size a little now and then. This can really screw up
> applications if you only update the spandsp .so library.

Why not use "static" on the functions that are supposed to remain internal
only?

> Do you do some kind of scan on the symbols in the .so's you produce,
> and track changes to those?

Exactly that. We produce a version-based table of symbols that are exposed
by a lib so we can track whenever the ABI is short on some function we had
in the previous version. Added functions in the ABI are not so problematic
as they don't taint our legacy compatibility (and all subsequent builds will
be based on the new library version with enlarged ABI anyway).

-- 
Best regards,
Kilian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20110703/1d9313c5/attachment.pgp>