C.2. Dynamically Linked Modules That Need External Libraries
Things get slightly more complicated when you want to build your module as a dynamic shared object (DSO) for loading at runtime. This is because not all Unix architectures allow you to link one shared object to another. Because both the module and the external library are shareable, this restriction causes LoadModule to fail at runtime with "symbol not found" errors.
Most Unix architectures don't suffer this problem, including all ELF-based systems. However, older systems that use the a.out binary architecture, including most BSD-derived systems, do suffer from this limitation. If this is the case with your system, you have the choice of statically linking the module with the httpd binary, as described in the previous section, or statically linking the whole external library into the DSO module.
Regardless of whether your system allows linking of DSOs to each other, its easiest to create modules that depend on external libraries using the APache eXtenSion (apxs) tool. Start out by running apxs with the -g and -n switches in order to create a skeleton build directory for your module:
% apxs -g -n compress Creating [DIR] compress Creating [FILE] compress/Makefile Creating [FILE] compress/mod_compress.c
Now edit the stub .c file to contain the handlers you need. In the case of mod_compress.c, we would add code to invoke libz 's file compression and decompression routines. To get the DSO module to link correctly, you must ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access