You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2008/06/07 00:32:33 UTC
svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h
modules/filters/mod_request.h
Author: wrowe
Date: Fri Jun 6 15:32:32 2008
New Revision: 664167
URL: http://svn.apache.org/viewvc?rev=664167&view=rev
Log:
No. You cannot rely on mod_foo.h magic from the
various subdirectories if you will consume it in
the core (server/*.c). server/request.c needs
mod_request (similar to mod_core.h) so this never
belonged in the subdir.
Added:
httpd/httpd/trunk/include/mod_request.h
- copied unchanged from r664156, httpd/httpd/trunk/modules/filters/mod_request.h
Removed:
httpd/httpd/trunk/modules/filters/mod_request.h
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h modules/filters/mod_request.h
Posted by Sander Temme <sc...@apache.org>.
On Jun 7, 2008, at 10:06 PM, Sander Temme wrote:
> I'll revert tonight if I don't fall asleep first.
Not reverted, but should now be fixed. Trunk now builds again.
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h modules/filters/mod_request.h
Posted by Sander Temme <sc...@apache.org>.
On Jun 7, 2008, at 11:58 AM, William A. Rowe, Jr. wrote:
> So I did, thanks for the pointer! However, modules/http/ might
> contain
> includes in the future which aren't consumed by the core, so it isn't
> harmful. In fact, the includes recently moved into core include/
> should
> probably be refactored into those bits which are relevant to core
> server/
> and those which should have always been private, before a 2.4 or 3
> ships.
>
> Suppose we should leave that as-is, for now?
If you want this, the search for .h files in modules/http should soft-
fail. What's in there now breaks the build.
I'll revert tonight if I don't fall asleep first.
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h
modules/filters/mod_request.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> The reason why I noticed this at all is an error message emitted by make
> which says that ls cannot find any *.h files in the modules/http directory.
> And if we add *.h files back to modules/http, the question is whether
> its functions need to be added to exports.c. If yes I would say that these
> headers then belong in include/, if not then the patch needs to be
> applied anyway.
in that case I'm entirely happy with reverting the modules/http/ from our
-I list, would you like to patch first or should I?
Bill
ps. your lack of a commit in the next 18 hours means I will ;-)
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h
modules/filters/mod_request.h
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/07/2008 08:58 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>>
>>
>> On 06/07/2008 03:57 AM, William A. Rowe, Jr. wrote:
>>> Ruediger Pluem wrote:
>>>>
>>>> server/.libs/libmain.a(exports.o):(.data+0x598): undefined reference
>>>> to `ap_parse_request_form'
>>>
>>> shouldn't have, your exports.c is stale.
>>>
>>>
>>
>> It wasn't stale, but r664227 fixed this. Now it works again. Thanks.
>> But as modules/http does not contain *.h files any longer I guess you
>> missed the following patch:
>
> So I did, thanks for the pointer! However, modules/http/ might contain
> includes in the future which aren't consumed by the core, so it isn't
> harmful. In fact, the includes recently moved into core include/ should
> probably be refactored into those bits which are relevant to core server/
> and those which should have always been private, before a 2.4 or 3 ships.
>
> Suppose we should leave that as-is, for now?
The reason why I noticed this at all is an error message emitted by make
which says that ls cannot find any *.h files in the modules/http directory.
And if we add *.h files back to modules/http, the question is whether
its functions need to be added to exports.c. If yes I would say that these
headers then belong in include/, if not then the patch needs to be applied anyway.
Regards
Rüdiger
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h
modules/filters/mod_request.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
>
> On 06/07/2008 03:57 AM, William A. Rowe, Jr. wrote:
>> Ruediger Pluem wrote:
>>>
>>> server/.libs/libmain.a(exports.o):(.data+0x598): undefined reference
>>> to `ap_parse_request_form'
>>
>> shouldn't have, your exports.c is stale.
>>
>>
>
> It wasn't stale, but r664227 fixed this. Now it works again. Thanks.
> But as modules/http does not contain *.h files any longer I guess you
> missed the following patch:
So I did, thanks for the pointer! However, modules/http/ might contain
includes in the future which aren't consumed by the core, so it isn't
harmful. In fact, the includes recently moved into core include/ should
probably be refactored into those bits which are relevant to core server/
and those which should have always been private, before a 2.4 or 3 ships.
Suppose we should leave that as-is, for now?
Bill
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h
modules/filters/mod_request.h
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/07/2008 03:57 AM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>>
>> server/.libs/libmain.a(exports.o):(.data+0x598): undefined reference
>> to `ap_parse_request_form'
>
> shouldn't have, your exports.c is stale.
>
>
It wasn't stale, but r664227 fixed this. Now it works again. Thanks.
But as modules/http does not contain *.h files any longer I guess you
missed the following patch:
Index: server/Makefile.in
===================================================================
--- server/Makefile.in (Revision 664295)
+++ server/Makefile.in (Arbeitskopie)
@@ -30,7 +30,7 @@
util.lo: test_char.h
-EXPORT_DIRS = $(top_srcdir)/include $(top_srcdir)/os/$(OS_DIR) $(top_srcdir)/modules/http
+EXPORT_DIRS = $(top_srcdir)/include $(top_srcdir)/os/$(OS_DIR)
EXPORT_DIRS_APR = $(APR_INCLUDEDIR) $(APU_INCLUDEDIR)
# If export_files is a dependency here, but we remove it during this stage,
Regards
Rüdiger
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h
modules/filters/mod_request.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> server/.libs/libmain.a(exports.o):(.data+0x598): undefined reference to
> `ap_parse_request_form'
shouldn't have, your exports.c is stale.
Re: svn commit: r664167 - in /httpd/httpd/trunk: include/mod_request.h
modules/filters/mod_request.h
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/07/2008 12:32 AM, wrowe@apache.org wrote:
> Author: wrowe
> Date: Fri Jun 6 15:32:32 2008
> New Revision: 664167
>
> URL: http://svn.apache.org/viewvc?rev=664167&view=rev
> Log:
> No. You cannot rely on mod_foo.h magic from the
> various subdirectories if you will consume it in
> the core (server/*.c). server/request.c needs
> mod_request (similar to mod_core.h) so this never
> belonged in the subdir.
>
> Added:
> httpd/httpd/trunk/include/mod_request.h
> - copied unchanged from r664156, httpd/httpd/trunk/modules/filters/mod_request.h
> Removed:
> httpd/httpd/trunk/modules/filters/mod_request.h
>
>
It seems that this broke trunk:
server/.libs/libmain.a(exports.o):(.data+0x588): undefined reference to `ap_keep_body_filter'
server/.libs/libmain.a(exports.o):(.data+0x58c): undefined reference to `ap_kept_body_filter'
server/.libs/libmain.a(exports.o):(.data+0x590): undefined reference to `ap_request_insert_filter'
server/.libs/libmain.a(exports.o):(.data+0x594): undefined reference to `ap_request_remove_filter'
server/.libs/libmain.a(exports.o):(.data+0x598): undefined reference to `ap_parse_request_form'
collect2: ld returned 1 exit status
make[1]: *** [httpd] Fehler 1
make: *** [all-recursive] Fehler 1
I guess because mod_request unlike core is a module that is not always be there and not always statically
linked.
Regards
Rüdiger