On Tue, May 5, 2026 at 8:44 AM Jun Omae <[email protected]> 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>/<TRhabin>. > > > > 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) > ]]] > ...and... > On Tue, May 5, 2026 at 8:55 AM Branko Čibej <[email protected]> wrote: > 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.
Good, thanks for explaining. I'm +1 to commit this patch. I also think it'd be great to nominate it for a backport to 1.15.x. -- Timofei Zhakov
