On Thu, May 24, 2018 at 11:28 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Thu, May 24, 2018 at 11:23 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
>> On Thu, May 24, 2018 at 11:06 AM, Micha Lenk <mi...@lenk.info> wrote:
>>>
>>> On 05/24/2018 10:41 AM, Yann Ylavic wrote:
>>>
>>>> Btw, as Jacob noted, the attached patch seems to work for me (even
>>>> without the above option).
>>>
>>> Yes, for me too, except that the linker problem with undefined symbols now
>>> seems to shift to the modules. I had to disable a few modules
>>> (--enable-mods-static=most --disable-apreq --disable-proxy-fcgi
>>> --disable-session-cookie --disable-session-dbd --disable-dav) to finally get
>>> to a successful build.
>>
>> Oh indeed, the correct order seems to be:
>>
>> PROGRAM_DEPENDENCIES = \
>> $(MPM_LIB) \
>> $(BUILTIN_LIBS) \
>> server/libmain.la \
>> os/$(OS_DIR)/libos.la
>
> Argh no, it now fails with --enable-mods-shared=...
Looks like the right order to me, however it fails with shared modules
because "server/core.c" (in libmain) uses ap_set_etag() function from
"modules/http/http_etag.c" (in BUILTIN_LIBS's libmod_http).
I think "core" shouldn't depend on a module (even builtin), for
instance ap_set_{last_modified,accept_range,content_length,...} also
used by the core are defined in "server/protocol.c".
WDYT?
