[asterisk-dev] asterisk tests for libpri

[Kevin P. Fleming]

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.

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.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org