[asterisk-dev] asterisk tests for libpri

[Shaun Ruffell]

On Tue, Mar 29, 2011 at 11:56:19AM -0500, Shaun Ruffell wrote:
> 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?
> 

After looking (I guess I should have looked before initially
responding), I see that there is an SONAME specified. But it's at 1.4
and I'm guessing the ABI is changing without changing the SONAME?

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