symbols of spandsp0.0.6~pre18 and SONAME

[Steve Underwood]

Hi Killian,

On 07/03/2011 06:20 PM, Kilian Krause wrote:
> Hi Steve,
>
> 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.

The bitstream_xxx2 functions were kind of interim things, before I had 
really settled the API. The current bitstream functions should be stable.

make_tone_gen_descriptor was changed to improve consistency. I didn't 
think anyone would be making direct use of it.

make_tone_gen_descriptor was an inconsistent name. Since it was part of a module that was not really functional I felt free to change it.


The T.4 functions aren't generally used directly, so I felt OK improving 
consistency there.

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.
>
> 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.

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

Steve