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)
]]]
--
Jun Omae <[email protected]> (大前 潤)
