[asterisk-dev] Makefile Help

[Sean Kelly]

Hi all,

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.

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:

a) Moved the core code for the module to an external c file in
apps/mydir/core_mymodule.c

b) Modified the apps/Makefile to build the external core code and the
shared object for Asterisk

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.

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):
----------
mydir/core_mymodule.o: mydir/core_mymodule.c
        $(CC) -fPIC -Wl, -E -c $< -o $@
        #$(CC) -fPIC -Wl, -c $< -o $@

app_mymodule.so: app_mymodule.o mydir/core_mymodule.o mydir/lib/libfftw3.a
        $(LD) $(SOLINK) $(_ASTLDFLAGS) $(ASTLDFLAGS) -E -o $@ $(LIBS) $<
----------

(*** 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)

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.

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.

If I run `nm apps/app_mymodule.so`, here's what it shows:
----------
0000000000200cd0 a _DYNAMIC
0000000000200e08 a _GLOBAL_OFFSET_TABLE_
0000000000000be0 r __PRETTY_FUNCTION__.14715
                 U __ast_verbose
0000000000200ef8 A __bss_start
0000000000200e80 d __mod_info
0000000000000780 t __reg_module
0000000000000860 t __register_file_version
0000000000000770 t __unreg_module
0000000000000850 t __unregister_file_version
0000000000200ef8 A _edata
0000000000200f68 A _end
0000000000200cc0 d app
                 U ast_module_register
                 U ast_module_unregister
                 U ast_options
                 U ast_register_application2
                 U ast_register_file_version
                 U ast_unregister_application
                 U ast_unregister_file_version
                 U ast_verbose_get_by_module
0000000000200cc8 d descrip
00000000000007a0 T load_module
                 U mymodule_exec
                 U option_verbose
                 U sprintf
0000000000200f00 b synopsis
0000000000000790 T unload_module
----------

mymodule_exec is Undefined! Yet if I `nm apps/mydir/core_mymodule.o`, I get:
----------
(...)
0000000000000420 T mymodule_exec
(...)
----------

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.

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!

Thanks in advance,
- Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120802/bc87c4a4/attachment.htm>