On 5. 5. 26 08:44, Jun Omae wrote:
On 2026/05/04 5:02, Timofei Zhakov wrote:
On Sun, May 3, 2026 at 7:49 PM Jun Omae<[email protected]> wrote:
Hi,
On 2026/04/30 0:02, Timofei Zhakov wrote:
Hello all,
There is a somewhat minimal untested support for compiling the modules
for Apache Httpd in cmake. However, I found that the Unix version
works in a fundamentally different way than Windows (that I was
testing on initially); It appears there is no libhttpd in its package.
The recommended way to compile is to use the apxs tool [1]. 'make'
does just call it. We could use it in cmake as well, but I believe it
wouldn't be the optimal way in cmake. It would not respect the user
specified compiler and other configurations. I rather think we should
work around it and link all the required libs manually.
Does anyone know where (and why) it puts all that code from libhttpd
on a Unix build? I'm confused a little bit...
[1]https://httpd.apache.org/docs/2.4/programs/apxs.html
Could you please try attached patch for building Apache modules using
apxs via cmake?
I can confirm that it works.
I see that you used it to get the flags rather than to let it build
the module. Because this was what made me confused in the first place.
The documentation mentions that you can call it like 'apxs -i -a -c
mod_foo.c' so it makes a freshly built mod with everything set up.
Slight note about this...
[[[
+ find_program(APXS_EXECUTABLE
+ NAMES apxs2 apxs
+ PATH /usr/local/apache2/bin /usr/local/apache/bin /usr/bin
/usr/sbin)
]]]
...it doesn't really make that much of a difference but I think it's
more prefered to rely on cmake's standard paths (like let it search in
$PATH and other system specific places). There is also a PATH_SUFFIXES
variable for find_program to customise unusual locations like
/usr/local/apache/bin. Although in this exact case it wouldn't work
because it's not under <prefix>/<bin>.
Basically because cmake searches many potential places for programs to
be (see NO_DEFAULT_PATH section of find_program documentation), the
'/usr/bin /usr/sbin' part is extra.
Or I guess if this part is taken from autoconf it's fine...
Right. I've ported the part from build/ac-macros/apache.m4.
Also have you tested the Mac OS case? Can it by any chance work
out-of-box with apxs settings or the "-Wl,-undefined,dynamic_lookup"
flags are mandatory? I don't have an environment to test it. It would
be great if somebody who does could take a look at it.
I confirmed that it works on macOS as well after the last post.
Without the "-Wl,-undefined,dynamic_lookup" flags, the link of mod_*.so
files fails like the following.
[[[
Undefined symbols for architecture x86_64:
"_ap_add_input_filter", referenced from:
_proxy_request_fixup in mirror.c.o
_merge_xml_filter_insert in mod_dav_svn.c.o
"_ap_add_output_filter", referenced from:
_proxy_request_fixup in mirror.c.o
_proxy_request_fixup in mirror.c.o
...
(snip)
...
"_dav_xmlns_add", referenced from:
_db_define_namespaces in deadprops.c.o
_db_define_namespaces in deadprops.c.o
_db_define_namespaces in deadprops.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
]]]
Yes, the '-undefined dynamic_lookup' flag is needed because the macOS
linker expects to see all symbols defined when linking a shared library.
But Apache modules use the module API exported from httpd, which is only
available once the module is loaded at runtime. Linking the module to
httpd would create a circular dependency.
-- Brane
