Summary:ASTERISK-22296: ARI fails to find symbols for res_http_websockets
Reporter:Matt Jordan (mjordan)Labels:Asterisk12
Date Opened:2013-08-14 12:01:26Date Closed:2013-08-30 08:45:04
Versions:12 Frequency of
Environment:CentOS 6 gcc 4.4Attachments:
Description:When running on a CentOS 6 VM using gcc 4.4, ARI fails to use the {{res_http_websockets}} module. When it attempts to use the function
{{int AST_OPTIONAL_API_NAME(ast_websocket_set_nonblock)(struct ast_websocket *session)}} in {{ari_websockets.c}}, it simply returns {{-1}}.

Note that gcc 4.4 stated that it did not support the extensions that optional API depends on.
Comments:By: John Hardin (jhardin) 2013-08-20 10:16:56.386-0500

gcc 4.4 supports weakrefs, which the optional api's depend on, but in ari_websocket.c, the call to ast_websocket_set_nonblock() always executes the stub instead of the one from res_http_websocket.c. After upgrading to gcc 4.6.3, the problem went away.

By: David M. Lee (dlee) 2013-08-23 13:23:49.626-0500

This appears to be an issue with the order in which modules are loaded with dlopen().

When Asterisk loads modules, it first goes through and calls {{dlopen()}} to load all the modules that it knows that it needs. Then, in a second phase, it initializes them in the order specified by the module's {{load_pri}}.

Optional API functions are resolved in {{\_\_constructor\_\_}} functions, which are executed during the {{dlopen()}}.

If res_ari.so happens to be loaded before res_http_websocket.so, then the {{ast_websocket_*()}} functions will be stubbed out.

I'm going to see if there's a not-awful way to get optional API function references to refresh as modules are loaded and unloaded.