[asterisk-dev] [Code Review] ADSI and Crypto backwards compatibility with 1.6.2

[Tilghman Lesher]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/876/
-----------------------------------------------------------

(Updated 2010-08-26 15:07:41.809264)


Review request for Asterisk Developers.


Summary
-------

In 1.6.2 and previous, res_adsi and res_crypto used stub files to allow them not to be loaded.  We got rid of the stubs in favor of the optional_api approach.  Now people who are upgrading, who previously noload'ed those modules AND are on a platform which does not support optional_api (i.e. gcc 4.1) (e.g. RHEL, Centos 5) are complaining that the easy upgrade path is broken.

This patch forces those broken platforms to automatically load the dependencies, when required by a loaded module.


This addresses bug 17707.
    https://issues.asterisk.org/view.php?id=17707


Diffs (updated)
-----

  /branches/1.8/apps/app_adsiprog.c 283524 
  /branches/1.8/apps/app_followme.c 283524 
  /branches/1.8/apps/app_getcpeid.c 283524 
  /branches/1.8/apps/app_queue.c 283524 
  /branches/1.8/apps/app_speech_utils.c 283524 
  /branches/1.8/apps/app_stack.c 283524 
  /branches/1.8/apps/app_voicemail.c 283524 
  /branches/1.8/channels/chan_agent.c 283524 
  /branches/1.8/channels/chan_dahdi.c 283524 
  /branches/1.8/channels/chan_iax2.c 283524 
  /branches/1.8/channels/chan_mgcp.c 283524 
  /branches/1.8/channels/chan_sip.c 283524 
  /branches/1.8/funcs/func_aes.c 283524 
  /branches/1.8/include/asterisk/module.h 283524 
  /branches/1.8/main/loader.c 283524 
  /branches/1.8/pbx/pbx_dundi.c 283524 
  /branches/1.8/pbx/pbx_loopback.c 283524 
  /branches/1.8/pbx/pbx_realtime.c 283524 

Diff: https://reviewboard.asterisk.org/r/876/diff


Testing
-------

noloaded modules on a Centos 5 machine, verified they loaded when a dependent module was loaded, either at boot time, or later, at CLI request (i.e. the 'module load' command).


Thanks,

Tilghman