[asterisk-dev] asterisk tests for libpri

[Shaun Ruffell]

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

Perhaps I'm not following, but could libpri specify a soname for each
particular ABI supported by the binary?  Then asterisk could link to the
version of libpri that has the features it needs, but multiple versions
of libpri with different ABIs could exist on the host system?

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org