You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jun Omae <ju...@gmail.com> on 2026/05/03 17:49:53 UTC
Re: Apache modules on Unix (w/cmake)
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 think it is needed to use add_library(... INTERFACE ...) for the Apache
modules. I confirmed quickly that the built modules work with Apache on
Ubuntu and Windows.
Also, I'd suggest to use LF rather than CRLF for newlines in
build/cmake/FindHttpd.cmake.
--
Jun Omae <ju...@gmail.com> (大前 潤)
Re: Apache modules on Unix (w/cmake)
Posted by Branko Čibej <br...@apache.org>.
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<ju...@gmail.com> 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
Re: Apache modules on Unix (w/cmake)
Posted by Timofei Zhakov <ti...@chemodax.net>.
On Tue, May 5, 2026 at 8:44 AM Jun Omae <ju...@gmail.com> wrote:
>
> On 2026/05/04 5:02, Timofei Zhakov wrote:
> > On Sun, May 3, 2026 at 7:49 PM Jun Omae <ju...@gmail.com> 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 <br...@apache.org> 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
Re: Apache modules on Unix (w/cmake)
Posted by Jun Omae <ju...@gmail.com>.
On 2026/05/04 5:02, Timofei Zhakov wrote:
> On Sun, May 3, 2026 at 7:49 PM Jun Omae <ju...@gmail.com> 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 <ju...@gmail.com> (大前 潤)
Re: Apache modules on Unix (w/cmake)
Posted by Timofei Zhakov <ti...@chemodax.net>.
On Sun, May 3, 2026 at 7:49 PM Jun Omae <ju...@gmail.com> 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...
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 think it is needed to use add_library(... INTERFACE ...) for the Apache
> modules. I confirmed quickly that the built modules work with Apache on
> Ubuntu and Windows.
Yes, I think this would be more precise.
> Also, I'd suggest to use LF rather than CRLF for newlines in
> build/cmake/FindHttpd.cmake.
Perhaps this file is missing svn:eol-style that's why...
> --
> Jun Omae <ju...@gmail.com> (大前 潤)
I think now I get more understanding about how it resolves runtime
libraries... I checked the compiled object and the default modules I
have installed on my system with 'ld' and it shows a bunch of
'undefined reference' errors. Which means that httpd deals with
resolving those functions and symbols at runtime when the DSO is
loaded. It's possible that they all are defined in the service binary
itself.
--
Timofei Zhakov