symbols of spandsp0.0.6~pre18 and SONAME

[Diana Cionoiu]

  Hello Kilian,

Yate 2 has been more or less dropped for a while.

Diana

On 07/03/2011 04:21 PM, Kilian Krause wrote:
> 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).
>
>
>
> _______________________________________________
> Pkg-voip-maintainers mailing list
> Pkg-voip-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-voip-maintainers