Hi all,<br><br>I've been running into a wall here, and now the issue is becoming increasingly difficult to search for on the Net. I was hoping perhaps someone here might have some insight into this.<br><br>So I am working on an application module: apps/app_mymodule.c; In order to facilitate building the core code for this module both independently (for external function and regression testing) and as a part of the normal asterisk build/deploy process, I have:<br>
<br>a) Moved the core code for the module to an external c file in apps/mydir/core_mymodule.c<br><br>b) Modified the apps/Makefile to build the external core code and the shared object for Asterisk<br><br>Complicating matters, core_mymodule.c also requires an external library for libfftw which I've attempted a couple different ways (static vs. dynamic linking), but have settled on static for now as it seems to be a bit more straightforward. To force matters on this front, I have copied libfftw3.a to apps/mydir/lib/ along with its companion .la file to ensure that the linker sees only what is needed.<br>
<br>So here's what I've appended to the end of apps/Makefile; keep in mind, this represents several dozen permutations to get this thing as close as I can through trial and error (and a LOT of scanning man pages and help forums on the Net):<br>
----------<br>mydir/core_mymodule.o: mydir/core_mymodule.c<br> $(CC) -fPIC -Wl, -E -c $< -o $@<br> #$(CC) -fPIC -Wl, -c $< -o $@<br>
<br>app_mymodule.so: app_mymodule.o mydir/core_mymodule.o mydir/lib/libfftw3.a<br> $(LD) $(SOLINK) $(_ASTLDFLAGS) $(ASTLDFLAGS) -E -o $@ $(LIBS) $<<br>----------<br>
<br>(*** Note that all the source code compiles and works just fine if I cram it into one big source file, but that prohibits me from building it properly as a standalone application)<br><br>If I run `make` normally from the Asterisk top level directory, it successfully compiles mydir/core_mymodule.c and sotres the result in a matching .o file. It does the same for apps/app_mymodule.c, and then creates the shared object from that. But what I end up with is a shared object that Asterisk cannot load because of an undefined mymodule_exec function.<br>
<br>The top level module source file is just a stub that has a call to ast_register_application() inside f.load_module() with the function name "mymodule_exec" passed to it. f.mymodule_exec() is declared in a header file and defined in mydir/core_mymodule.c.<br>
<br>If I run `nm apps/app_mymodule.so`, here's what it shows:<br>----------<br>
0000000000200cd0 a _DYNAMIC<br>0000000000200e08 a _GLOBAL_OFFSET_TABLE_<br>0000000000000be0 r __PRETTY_FUNCTION__.14715<br> U __ast_verbose<br>0000000000200ef8 A __bss_start<br>0000000000200e80 d __mod_info<br>
0000000000000780 t __reg_module<br>0000000000000860 t __register_file_version<br>0000000000000770 t __unreg_module<br>0000000000000850 t __unregister_file_version<br>0000000000200ef8 A _edata<br>0000000000200f68 A _end<br>
0000000000200cc0 d app<br> U ast_module_register<br> U ast_module_unregister<br> U ast_options<br> U ast_register_application2<br> U ast_register_file_version<br>
U ast_unregister_application<br> U ast_unregister_file_version<br> U ast_verbose_get_by_module<br>0000000000200cc8 d descrip<br>00000000000007a0 T load_module<br> U mymodule_exec<br>
U option_verbose<br> U sprintf<br>0000000000200f00 b synopsis<br>0000000000000790 T unload_module<br>----------<br>
<br>mymodule_exec is Undefined! Yet if I `nm apps/mydir/core_mymodule.o`, I get:<br>----------<br>(...)<br>
0000000000000420 T mymodule_exec<br>(...)<br>----------<br>
<br>It defines it just fine as a part of the "Text" (code) block, so it's definitely there, but for some reason is not brought in.<br><br>It appears that the only symbols defined in the shared object are those that appeared in the app_mymodule.c file, and that *nothing* from either core_mymodule.o or libfftw3.a were actually imported into the shared object by the linker. Any ideas why? It seems so simple, but this has been kicking my butt!<br>
<br>Thanks in advance,<br>- Sean<br><br>