[asterisk-dev] Optional api and weak symbol problem

[Kevin P. Fleming]

On 11/03/2011 05:36 AM, Yaroslav Panych wrote:
> Greetings
>
> Recently(in the middle of July) I started to build and test Asterisk
> on Cygwin platform. As of October I had a little success(despite bugs
> I reported to JIRA and sent fixes): I eventually managed to build and
> run asterisk, and it even receive calls from some SIP softclients.
>
> Now I decided to regroup my work. So my first task is to build as much
> Asterisk's modules as it is possible on platform. And one of problems
> I faced is next:
> Cygwin, or more precisely Binary format of Windows Platform(PE), does
> not support runtime unresolved references and so called weak
> symbols(at least not in form it used in asterisk). Optional API is
> based on such thinks, so it is basically non-portable into
> Cygwin/Windows platform. So building process emits a lot of error
> messages about unresolved symbols. So part of modules which use
> optional API(Marked as Canuse something) is unbuildable now.(For
> instance chan_iax2 and chan_dundi requires symbols from res_crypto,
> which is not built because of lack of dependencies).
>
> 1. I think Optional API should be rewritten in order to conform one of
> supported platforms.

Cygwin has never been considered a 'supported platform' in the Asterisk 
community, by its development team, or anyone else that I know of.

> OR
> 2. As workaround, all optional dependencies on Cygwin platform should
> be converted to required dependencies(by configurator or conditional
> builds).

This is what needs to occur, but this is only one step: on Windows, it 
is also necessary to build any dependency modules *before* the dependent 
module, because at the time of linking the dependent module the linker 
has to be able to see the dependency modules. When this was last done 
for Asterisk, it resulted in some really complicated and 
hard-to-maintain additions to the build system. These are not avoidable, 
they are caused by the Windows linking mechanisms.

As far as disabling all optional API usage, all that is required is to 
modify the configure script to ensure that the tests that are run to 
determine whether the platform provides the necessary supporting 
features *fail*; if those tests fail, then the optional API mechanism 
will revert automatically to standard link-time dependencies.

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