| 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:26 | Date Closed: | 2013-08-30 08:45:04 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_http_websocket |
| Versions: | 12 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | CentOS 6 gcc 4.4 | Attachments: | |
| 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. | ||