[asterisk-dev] asterisk tests for libpri

[Tzafrir Cohen]

On Tue, Mar 29, 2011 at 11:20:27AM -0500, Kevin P. Fleming wrote:
> On 03/29/2011 10:03 AM, Richard Mudgett wrote:
>>> There are a number of build-time tests in the Asterisk configure
>>> scripts
>>> for features in libpri. Here is a list of them:
>>>
>>> Name: Function tested: First appeared in:
>>> PRI_DISPLAY_TEXT pri_display_text -
>>> PRI_MWI pri_mwi_indicate 1.4.12-beta1
>>> PRI_MCID pri_mcid_enable 1.4.12-beta1
>>> PRI_CALL_WAITING pri_connect_ack_enable 1.4.12-beta1
>>> PRI_AOC_EVENTS pri_aoc_events_enable 1.4.12-beta1
>>> PRI_TRANSFER pri_transfer_enable 1.4.12-beta1
>>> PRI_CCSS pri_cc_enable 1.4.12-beta1
>>> PRI_HANGUP_FIX pri_hangup_fix_enable 1.4.11
>>> PRI_SUBADDR pri_sr_set_called_subaddress 1.4.11
>>> PRI_CALL_HOLD pri_hold_enable 1.4.11
>>> PRI_CALL_REROUTING pri_reroute_enable 1.4.11
>>> PRI_SETUP_KEYPAD pri_sr_set_keypad_digits 1.4.11
>>> PRI_SERVICE_MESSAGES pri_maintenance_service 1.4.11
>>> PRI_REVERSE_CHARGE pri_sr_set_reversecharge 1.4.11
>>> PRI_PROG_W_CAUSE pri_progress_with_cause 1.4.8
>>> PRI_INBANDDISCONNECT pri_set_inbanddisconnect 1.4.6
>>>
>>> There are a number of places where the results of those tests are used
>>> to conditionally build code. E.g.:
>>>
>>> #ifdef PRI_MWI
>>> some code that may use pri_mwi_indicate()
>>> #endif
>>>
>>> This works well as long as we stay on the same system. But what
>>> happens
>>> if the same Asterisk (or rather: chan_dahdi.so) binary is then copied
>>> over to a system with libpri 1.4.11 (or older)?
>>
>> It depends.
>>
>> If chan_dahdi is from:
>> Asterisk v1.4 or v1.6.2 then nothing because those versions of Asterisk do not know how to use the new features.
>> Asterisk v1.8 or trunk then you will get unresolved externals because that version knows how to use the new features.
>>
>> Building chan_dahdi with a particular version of libpri means that chan_dahdi expects that version of libpri as a minimum.
>
> Exactly. Tzafrir and I have had this discussion before (in other  
> contexts), and it is impractical to try to build library interfaces in  
> such a way that code compiled against a newer version of the library  
> (and taking advantage of new interfaces in that version) will fail  
> gracefully when run against an older version of the library. It is  
> possible, but it causes the library interface to have to be designed in  
> a very different way, and to my knowledge there aren't any mainstream  
> libraries that provide this sort of guarantee.

I was also surprised to see that the configure script tests 6 times for
features that were added in tag 1.4.12-beta1 and 7 times for features
added in tag 1.4.11 .

Maybe some of those could be removed to slightly reduce the run time of
the configure script?

>
> If this sort of use case really exists, the most effective way to handle  
> it is to link libpri into chan_dahdi/sig_pri statically, so that it is  
> not possible for them to end up mismatched.

Which means: when upgrading the version of libpri in a repository, be
sure to rebuild asterisk right afterwards, and explicitly requier a
newer version of the binary version.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir