[asterisk-dev] Optional api and weak symbol problem

[Kevin P. Fleming]

On 11/03/2011 05:41 PM, Yaroslav Panych wrote:
> Thanks for answer Kevin
>
> 2011/11/4 Kevin P. Fleming<kpfleming at digium.com>:
>> Cygwin has never been considered a 'supported platform' in the Asterisk
>> community, by its development team, or anyone else that I know of.
>
> Sorry, but first two comments of issue
> https://issues.asterisk.org/jira/browse/ASTERISK-18102 claims other:
> First claims, "Cygwin is unsupported" and issue was closed;
> Second comment reopens issues, and there is only one reason to do it -
> Cygwin is still supported.
> And even third comment indicates this, because there is no reason to
> demand patch for unsupported platform.(And patch was sent, it
> perfectly fits for while 1.8 branch).
> Since issue is still no rejected because of "unsupported platform"
> What I understood wrong?
>
> So:
> While there are any opened Cygwin related issues with patch demand in
> JIRA, Cygwin is considered supported.
> In any case, there is a lot of Cygwin and MinGW hacks in Asterisks
> sources and build system, so Cygwin is dtill considered supported.
> I don't think my conclusions are wrong.

Your conclusions are wrong. The Asterisk development team spends *zero* 
time on Cygwin and MinGW support. If a community developer provides 
patch(es), and other community members test them and report that they 
work (for some value of 'work') then they might get merged. The support 
they provide could easily get broken by the addition of new modules, 
build system changes, or changes in Cygwin or MinGW, and if Asterisk 
stops building on those platforms, it will be up to the community to 
both notice the problem and fix it. The automated build system that we 
use for building Asterisk release branches and running the testsuite 
doesn't have any Windows systems in it.

In other words, it is not considered a 'supported' platform, because if 
it gets broken, that won't stop releases being made or other patches 
being merged.

>
>> 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.
>
> I know how works dependency mechanism(and it work in the same way on
> all platforms, no only on Windows), and I'm sure asterisk developers
> know that. BUT: since menuselect allows to include module without
> resolved dependencies, it means it is intended to be so. So there is
> no any necessity to build something before something other unless it
> stated as required. Since res_crypto is not stated as required for
> chan_iax2, chan_iax2 MUST be buildable without it(if it is not, this
> means a bug in those modules or in whole package, isn't it?).
> In any case all this half-working mechanisms should be reworked.

Your conclusions are again completely wrong. The dependency system *can* 
convert to 'required dependencies', and the configure script and 
Makefiles have the ability to do that on platforms that don't provide 
the linker mechanisms required for weak linking of symbols.

On Windows, it is absolutely important that modules be built in a 
particular order. On Windows, it won't be possible to build chan_iax2 
*without* linking it to res_crypto, and res_crypto.dll *MUST* be built 
before chan_iax2.dll is built, because the Windows linker will need to 
be able to refer to res_crypto.dll (and related files) in order to link 
chan_iax2.dll.

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