You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/06/05 16:23:37 UTC
It's time to get 2.03-dev out
Folks,
Please test current cvs and report/fix any build problems; I plan
to start the release process in a few days. Below is the list of
known outstanding bugs from the STATUS file- I don't plan to
have fixes for these included in 2.03-dev. Patches for the docs
and/or tests would be ideal at this point, otherwise it may need
to wait until 2.04-dev in 2-3 months (which will likely be the final
developer release of libapreq2).
BUGS:
- Strange bug when ssl is enabled & lots of fields are present: see
http://marc.theaimsgroup.com/?t=107766265600001&r=1&w=2
- Fix build automake/libtool/autoconf build system so it works
properly on OSX & AIX. FreeBSD cannot build httpd-apreq2 either,
but there are too many problems with the current (May 2004)
ports of the auto* tools for us to accomodate FreeBSD (yet).
- The current API does not handle failed query_string parsing
adequately (apreq_request does log an error message, but
there's no status code in the struct for users to interrogate).
--
Joe Schaefer
Re: [apreq-2] APREQ_DECLARE_PARSER on Win32
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> If one uses
> ===========================================================
> Index: src/apreq_params.h
> ===================================================================
> RCS file: /home/cvs/httpd-apreq-2/src/apreq_params.h,v
> retrieving revision 1.28
> diff -u -r1.28 apreq_params.h
> --- src/apreq_params.h 4 Jun 2004 22:02:11 -0000 1.28
> +++ src/apreq_params.h 5 Jun 2004 17:28:49 -0000
> @@ -232,14 +232,24 @@
> /**
> * Declares a API parser.
> */
> +#ifndef WIN32
> #define APREQ_DECLARE_PARSER(f) APREQ_DECLARE(apr_status_t) \
> (f) APREQ_PARSER_ARGS
> +#else
> +#define APREQ_DECLARE_PARSER(f) APREQ_DECLARE_NONSTD(apr_status_t) \
> + (f) APREQ_PARSER_ARGS
> +#endif
>
> /**
> * Declares an API hook.
> */
> +#ifndef WIN32
> #define APREQ_DECLARE_HOOK(f) APREQ_DECLARE(apr_status_t) \
> (f) APREQ_HOOK_ARGS
> +#else
> +#define APREQ_DECLARE_HOOK(f) APREQ_DECLARE_NONSTD(apr_status_t) \
> + (f) APREQ_HOOK_ARGS
> +#endif
>
> /**
> * Singly linked list of hooks.
> ======================================================================
[...]
> (ie, APREQ_DECLARE without __stdcall) then things build OK
> and all tests pass.
+1 - please apply.
--
Joe Schaefer
[apreq-2] APREQ_DECLARE_PARSER on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
Win32 gets confused with the APREQ_DECLARE_PARSER(f) define
in src/apreq_params.h - I think this is related to __stdcall
appearing in
#define APREQ_DECLARE(d) __declspec(dllexport) d __stdcall
of src/apreq.h. If one uses
===========================================================
Index: src/apreq_params.h
===================================================================
RCS file: /home/cvs/httpd-apreq-2/src/apreq_params.h,v
retrieving revision 1.28
diff -u -r1.28 apreq_params.h
--- src/apreq_params.h 4 Jun 2004 22:02:11 -0000 1.28
+++ src/apreq_params.h 5 Jun 2004 17:28:49 -0000
@@ -232,14 +232,24 @@
/**
* Declares a API parser.
*/
+#ifndef WIN32
#define APREQ_DECLARE_PARSER(f) APREQ_DECLARE(apr_status_t) \
(f) APREQ_PARSER_ARGS
+#else
+#define APREQ_DECLARE_PARSER(f) APREQ_DECLARE_NONSTD(apr_status_t) \
+ (f) APREQ_PARSER_ARGS
+#endif
/**
* Declares an API hook.
*/
+#ifndef WIN32
#define APREQ_DECLARE_HOOK(f) APREQ_DECLARE(apr_status_t) \
(f) APREQ_HOOK_ARGS
+#else
+#define APREQ_DECLARE_HOOK(f) APREQ_DECLARE_NONSTD(apr_status_t) \
+ (f) APREQ_HOOK_ARGS
+#endif
/**
* Singly linked list of hooks.
======================================================================
so as to use APREQ_DECLARE_NONSTD:
#define APREQ_DECLARE(d) __declspec(dllexport) d
(ie, APREQ_DECLARE without __stdcall) then things build OK
and all tests pass.
--
best regards,
randy
Re: [PATCH] Re: It's time to get 2.03-dev out
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Mon, 7 Jun 2004, Joe Schaefer wrote:
>[ ... ]
>
>
>>Try current cvs- I just changed that test to use
>>slurp() instead.
>>
>>
>
>That works for me (mod_perl-1.9915, Apache/2.0.49,
>Win32 Perl-5.8.0).
>
My system's happy too now. (1.99_15-dev / 2.0.49 / 5.8.4.)
Thanks, Joe!
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [PATCH] Re: It's time to get 2.03-dev out
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 7 Jun 2004, Joe Schaefer wrote:
[ ... ]
> Try current cvs- I just changed that test to use
> slurp() instead.
That works for me (mod_perl-1.9915, Apache/2.0.49,
Win32 Perl-5.8.0).
--
best regards,
randy
Re: [PATCH] Re: It's time to get 2.03-dev out
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 7 Jun 2004, Steve Hay wrote:
>
>
>>Joe Schaefer wrote:
>
> [ ... ]
>
>>>It's likely due to a recent API change in mp2's APR::Bucket
>>>(IIRC the return value of $b->read() used to be a status code).
>>>What version of mp2 are you using?
>>>
>>
>>1.99_15-dev from a week or two ago, the Changes for which
>>does indeed include:
>>
>>APR::Bucket: [Stas]
>> - read() now returns read data and throws APR::Error exception (not
>>returning rc)
>>
>>So the test will have to check which version of mp2 is being used? In
>>the long term, you obviously want to use the new syntax, but clearly not
>>many people are using it yet...
I'm still trying to find the best solution. I think I'm going back to the
$b->read(my $buffer)
syntax, but use the exception in the void context approach. so please don't
rush changing things, just yet.
I wish I was getting feedback on those API changes, when I propose them.
Without such I just talk to myself, so some of the API go back and forth as I
write new code and find the changes to be not so good.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Re: It's time to get 2.03-dev out
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> After upgrading my mod_perl to a more recent dev version, I
> also find this failure. Does the following work?
Try current cvs- I just changed that test to use slurp() instead.
--
Joe Schaefer
Re: [PATCH] Re: It's time to get 2.03-dev out
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 7 Jun 2004, Steve Hay wrote:
> Joe Schaefer wrote:
[ ... ]
> >It's likely due to a recent API change in mp2's APR::Bucket
> >(IIRC the return value of $b->read() used to be a status code).
> >What version of mp2 are you using?
> >
> 1.99_15-dev from a week or two ago, the Changes for which
> does indeed include:
>
> APR::Bucket: [Stas]
> - read() now returns read data and throws APR::Error exception (not
> returning rc)
>
> So the test will have to check which version of mp2 is being used? In
> the long term, you obviously want to use the new syntax, but clearly not
> many people are using it yet...
After upgrading my mod_perl to a more recent dev version, I
also find this failure. Does the following work?
=================================================================
Index: glue/perl/t/response/TestApreq/request.pm
===================================================================
RCS file: /home/cvs/httpd-apreq-2/glue/perl/t/response/TestApReq/request.pm,v
retrieving revision 1.7
diff -u -r1.7 request.pm
--- glue/perl/t/response/TestApreq/request.pm 28 Feb 2004 05:16:11 -0000 1.7
+++ glue/perl/t/response/TestApreq/request.pm 8 Jun 2004 04:13:09 -0000
@@ -7,6 +7,7 @@
use Apache::RequestIO;
use Apache::Request ();
use Apache::Connection;
+require mod_perl;
sub handler {
my $r = shift;
@@ -26,7 +27,13 @@
# unlink("/home/joe/tmp/foo");
my $bb = $upload->bb;
while (my $b = $bb->first) {
- $b->read(my $buffer);
+ my $buffer;
+ if ($mod_perl::VERSION < 1.9915) {
+ $b->read($buffer);
+ }
+ else {
+ $buffer = $b->read();
+ }
$r->print($buffer);
$b->remove;
}
===================================================================
--
best regards,
randy
Re: [PATCH] Re: It's time to get 2.03-dev out
Posted by Steve Hay <st...@uk.radan.com>.
Joe Schaefer wrote:
>Steve Hay <st...@uk.radan.com> writes:
>
>[...]
>
>
>
>>I'm struggling to find the necessary docs to look at. I think $b here
>>is an APR::Brigade,
>>
>>
>
>No, $b is an APR::Bucket; $bb is an APR::Brigade.
>
That makes sense, then.
>
>
>
>>Maybe APR::Bucket? That has a read() which takes an optional "mode"
>>parameter (numeric?), and /returns/ the data read, so I tried this:
>>
>> my $buffer = $b->read();
>>
>>and now it's all OK.
>>
>>So the following patch fixes this for me, but I'm very confused how
>>nobody else could have noticed this?
>>
>>
>
>It's likely due to a recent API change in mp2's APR::Bucket
>(IIRC the return value of $b->read() used to be a status code).
>What version of mp2 are you using?
>
1.99_15-dev from a week or two ago, the Changes for which does indeed
include:
APR::Bucket: [Stas]
- read() now returns read data and throws APR::Error exception (not
returning rc)
So the test will have to check which version of mp2 is being used? In
the long term, you obviously want to use the new syntax, but clearly not
many people are using it yet...
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [PATCH] Re: It's time to get 2.03-dev out
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Steve Hay <st...@uk.radan.com> writes:
[...]
> I'm struggling to find the necessary docs to look at. I think $b here
> is an APR::Brigade,
No, $b is an APR::Bucket; $bb is an APR::Brigade.
> Maybe APR::Bucket? That has a read() which takes an optional "mode"
> parameter (numeric?), and /returns/ the data read, so I tried this:
>
> my $buffer = $b->read();
>
> and now it's all OK.
>
> So the following patch fixes this for me, but I'm very confused how
> nobody else could have noticed this?
It's likely due to a recent API change in mp2's APR::Bucket
(IIRC the return value of $b->read() used to be a status code).
What version of mp2 are you using?
--
Joe Schaefer
[PATCH] Re: It's time to get 2.03-dev out
Posted by Steve Hay <st...@uk.radan.com>.
Joe Schaefer wrote:
>Please test current cvs and report/fix any build problems;
>
I have the Perl glue apreq/request.t tests 2-3 failing on Win32. Here's
the output under "t/TEST -v" after changing the $value to just "my
$value = 'DataUpload';":
# testing : basic upload
# expected: DataUpload
# Failed test 2 in t\apreq\request.t at line 27
# Failed test 3 in t\apreq\request.t at line 33
# received: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
# <html><head>
# <title>500 Internal Server Error</title>
# </head><body>
# <h1>Internal Server Error</h1>
# <p>The server encountered an internal error or
# misconfiguration and was unable to complete
# your request.</p>
# <p>Please contact the server administrator,
# you@example.com and inform them of the time the error occurred,
# and anything you might have done that may have
# caused the error.</p>
# <p>More information about this error may be available
# in the server error log.</p>
# </body></html>
not ok 2
# testing : basic upload length
# expected: 10
# received: 0
not ok 3
All I have in the error log (after the server startup messages) is this:
[Mon Jun 07 12:41:24 2004] [debug] mod_apreq.c(258): [client 127.0.0.1]
prefetching 65536 bytes
[Mon Jun 07 12:41:24 2004] [error] [client 127.0.0.1] Use of
uninitialized value in subroutine entry at
C:\\Temp\\httpd-apreq-2\\glue\\perl\\t\\response/TestApReq/request.pm
line 29.\n
The "use warnings FATAL => 'all';" line turns that warning into the 500
Server Error seen above. However, simply commenting out that FATAL
warnings line (in the hope that the warning is harmless) doesn't fix
it. Evidently the warning is not harmless; the output is now:
# Failed test 2 in t\apreq\request.t at line 27
# Failed test 3 in t\apreq\request.t at line 33
# testing : basic upload
# expected: DataUpload
# received:
not ok 2
# testing : basic upload length
# expected: 10
# received: 0
not ok 3
Line 29 of glue/perl/t/response/TestApReq/request.pm (where the warning
came from) is:
$b->read(my $buffer);
I tried initialising my $buffer to an empty string before the read()
call, like this:
my $buffer = '';
$b->read($buffer);
but now it complains:
[Mon Jun 07 12:47:37 2004] [error] [client 127.0.0.1] Argument "" isn't
numeric in subroutine entry at
C:\\Temp\\httpd-apreq-2\\glue\\perl\\t\\response/TestApReq/request.pm
line 30.\n
I'm struggling to find the necessary docs to look at. I think $b here
is an APR::Brigade, but where does that get its read() method from?
Maybe APR::Bucket? That has a read() which takes an optional "mode"
parameter (numeric?), and /returns/ the data read, so I tried this:
my $buffer = $b->read();
and now it's all OK.
So the following patch fixes this for me, but I'm very confused how
nobody else could have noticed this?
Index: glue/perl/t/response/TestApReq/request.pm
===================================================================
RCS file:
/home/cvspublic/httpd-apreq-2/glue/perl/t/response/TestApReq/request.pm,v
retrieving revision 1.7
diff -u -r1.7 request.pm
--- glue/perl/t/response/TestApReq/request.pm 28 Feb 2004 05:16:11
-00001.7
+++ glue/perl/t/response/TestApReq/request.pm 7 Jun 2004 12:03:46 -0000
@@ -26,7 +26,7 @@
# unlink("/home/joe/tmp/foo");
my $bb = $upload->bb;
while (my $b = $bb->first) {
- $b->read(my $buffer);
+ my $buffer = $b->read();
$r->print($buffer);
$b->remove;
}
End of Patch.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: It's time to get 2.03-dev out
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Martin Nilsson <ma...@gneto.com> writes:
> I have to comment out the versioning checks in buildconf when running
> on FreeBSD where the libtool/autoconf/automake tools are named after
> their version.
Sorry, I don't know how to resolve this issue. Hopefully the FreeBSD
port of these tools will eventually include appropriate symlinks or some
other work-around.
> I have to change AM_PROG_LIBTOOL in configure.ac to AC_PROG_LIBTOOL to
> make it work otherwise I get:
>
> platon# aclocal14
> aclocal: configure.ac: 19: macro `AM_PROG_LIBTOOL' not found in library
>
> Now buildconf works but configure does not:
You also need to modify the aclocal call in buildconf, because libtool.m4
isn't where aclocal expects to find it. Someone has been kind enough
to provide me with a FreeBSD shell, and we learned that passing the
directory name (/usr/share/aclocal?) to aclocal with "-I" seems to fix
this (along with using gmake instead of make). However, we got stuck
getting Apache::Test to compile the c-modules correctly and bring up an
httpd daemon to test.
If there's a simple way to resolve these FreeBSD build issues, I'd love
to include that in 2.03-dev.
--
Joe Schaefer
Re: It's time to get 2.03-dev out
Posted by Martin Nilsson <ma...@gneto.com>.
Joe Schaefer wrote:
> Folks,
>
> Please test current cvs and report/fix any build problems;
I have to comment out the versioning checks in buildconf when running on
FreeBSD where the libtool/autoconf/automake tools are named after their
version.
I have to change AM_PROG_LIBTOOL in configure.ac to AC_PROG_LIBTOOL to
make it work otherwise I get:
platon# aclocal14
aclocal: configure.ac: 19: macro `AM_PROG_LIBTOOL' not found in library
Now buildconf works but configure does not:
checking whether ln -s works... yes
./ltconfig: ./ltconfig: No such file or directory
configure: error: libtool configure failed
I'm using:
libtool 1.4.3
autoconf 2.53
automake 1.4-p6
/Martin
Re: It's time to get 2.03-dev out
Posted by "Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov>.
Joe Schaefer wrote:
> That should be "mod_apreq.so" in both places. No clue what's
> causing this misbehavior.
Must be libtool, don't you think? Are you using a different version than me?
I'm using 1.4.2. I can try installing a different version to see if that
fixes the build problem.
FYI, I manually copied mod_apreq to mod_apreq.so and then did "make test"
again. The tests almost all failed.
----
/usr/wwwserver/apache.2.0.49/bin/httpd -d /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t -f /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/conf/httpd.conf -D APACHE2
using Apache/2.0.49 (prefork MPM)
waiting 60 seconds for server to start: ..
waiting 60 seconds for server to start: ok (waited 1 secs)
server localhost.localdomain:8529 started
t/apreq/big_input....FAILED tests 1-21
Failed 21/21 tests, 0.00% okay
t/apreq/cookie.......FAILED tests 6-7
Failed 2/7 tests, 71.43% okay
t/apreq/inherit......FAILED tests 1-4
Failed 4/4 tests, 0.00% okay
t/apreq/request......FAILED tests 1-3
Failed 3/3 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/apreq/big_input.t 21 21 100.00% 1-21
t/apreq/cookie.t 7 2 28.57% 6-7
t/apreq/inherit.t 4 4 100.00% 1-4
t/apreq/request.t 3 3 100.00% 1-3
[warning] server localhost.localdomain:8529 shutdown
[ error] error running tests (please examine t/logs/error_log)
[ error] oh nuts, server dumped core
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1103
[ error] oh gosh, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1107
[ error] oh crap, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1108
[ error] oh nuts, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1109
[ error] oh dangit, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1110
[ error] oh crap, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1113
[ error] oh dangnabit, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1114
[ error] oh crap, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1115
[ error] oh golly, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1116
[ error] oh shucks, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1117
[ error] oh dangit, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1118
[ error] oh jeez, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1119
[ error] oh nuts, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1120
[ error] oh golly, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1121
[ error] oh golly, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1122
[ error] oh darn, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1123
[ error] oh dangnabit, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1124
[ error] oh gosh, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1125
[ error] oh crap, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1126
[ error] oh crap, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1127
[ error] oh golly, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1128
[ error] oh crap, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1131
[ error] oh shucks, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1132
[ error] oh shucks, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1135
[ error] oh shucks, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1138
[ error] oh crap, server dumped core again
[ error] for stacktrace, run: gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1139
make[1]: *** [run_tests] Error 1
make[1]: Leaving directory `/Home/home2/sabol/work/httpd-apreq-2/glue/perl'
make: *** [perl_test] Error 2
----
Here's glue/t/error_log:
----
[Tue Jun 08 01:38:18 2004] [info] mod_unique_id: using ip addr 128.183.17.216
[Tue Jun 08 01:38:19 2004] [info] mod_unique_id: using ip addr 128.183.17.216
[Tue Jun 08 01:38:19 2004] [notice] Apache/2.0.49 (Unix) mod_perl/1.99_13 Perl/v5.6.1 configured -- resuming normal operations
[Tue Jun 08 01:38:19 2004] [info] Server built: May 7 2004 10:24:41
[Tue Jun 08 01:38:19 2004] [debug] prefork.c(955): AcceptMutex: sysvsem (default: sysvsem)
[Tue Jun 08 01:38:20 2004] [error] server reached MaxClients setting, consider raising the MaxClients setting
[Tue Jun 08 01:38:21 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:21 2004] [notice] child pid 1103 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:23 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:23 2004] [notice] child pid 1107 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:25 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:25 2004] [notice] child pid 1108 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:27 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:27 2004] [notice] child pid 1109 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:29 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:29 2004] [notice] child pid 1110 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:31 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:31 2004] [notice] child pid 1113 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:33 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:33 2004] [notice] child pid 1114 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:35 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:35 2004] [notice] child pid 1115 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:37 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:37 2004] [notice] child pid 1116 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:39 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:39 2004] [notice] child pid 1117 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:41 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:41 2004] [notice] child pid 1118 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:43 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:43 2004] [notice] child pid 1119 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:45 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:45 2004] [notice] child pid 1120 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:47 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:47 2004] [notice] child pid 1121 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:49 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:49 2004] [notice] child pid 1122 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:51 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:51 2004] [notice] child pid 1123 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:53 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:53 2004] [notice] child pid 1124 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:55 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:55 2004] [notice] child pid 1125 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:57 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:57 2004] [notice] child pid 1126 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:38:59 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:38:59 2004] [notice] child pid 1127 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:39:01 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 262144 bytes
[Tue Jun 08 01:39:01 2004] [notice] child pid 1128 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:39:03 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 65536 bytes
[Tue Jun 08 01:39:03 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] prefetching 65536 bytes
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(286): [client 127.0.0.1] parsing cookie data: apache=ok
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(354): [client 127.0.0.1] adding cookie: apache => ok
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(286): [client 127.0.0.1] parsing cookie data: $Version="1"; apache="ok"; $Path="/TestApReq__cookie"
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(354): [client 127.0.0.1] adding cookie: apache => "ok"
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(286): [client 127.0.0.1] parsing cookie data: apache=%6F%6B%69%65+%64%6F%6B%69%65
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(354): [client 127.0.0.1] adding cookie: apache => %6F%6B%69%65+%64%6F%6B%69%65
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(286): [client 127.0.0.1] parsing cookie data: apache=ok
[Tue Jun 08 01:39:03 2004] [debug] apreq_cookie.c(354): [client 127.0.0.1] adding cookie: apache => ok
[Tue Jun 08 01:39:04 2004] [notice] child pid 1131 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:39:05 2004] [debug] apreq_cookie.c(286): [client 127.0.0.1] parsing cookie data: $Version="1"; apache="ok"; $Path="/TestApReq__cookie"
[Tue Jun 08 01:39:05 2004] [debug] apreq_cookie.c(354): [client 127.0.0.1] adding cookie: apache => "ok"
[Tue Jun 08 01:39:06 2004] [notice] child pid 1132 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:39:08 2004] [notice] child pid 1135 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:39:10 2004] [notice] child pid 1138 exit signal Segmentation fault (11), possible coredump in /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t
[Tue Jun 08 01:39:11 2004] [info] removed PID file /Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/logs/httpd.pid (pid=1102)
[Tue Jun 08 01:39:11 2004] [notice] caught SIGTERM, shutting down
----
Here's the output of "gdb /usr/wwwserver/apache.2.0.49/bin/httpd -core
/Home/home2/sabol/work/httpd-apreq-2/glue/perl/t/core.1103":
----
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/wwwserver/apache.2.0.49/bin/httpd -d /Home/home2/sabol/work/httpd-apreq-2/'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/wwwserver/apache.2.0.49/lib/libaprutil-0.so.0...done.
Loaded symbols for /usr/wwwserver/apache.2.0.49/lib/libaprutil-0.so.0
Reading symbols from /usr/lib/libgdbm.so.2...done.
Loaded symbols for /usr/lib/libgdbm.so.2
Reading symbols from /usr/lib/libdb.so.2...done.
Loaded symbols for /usr/lib/libdb.so.2
Reading symbols from /usr/wwwserver/apache.2.0.49/lib/libexpat.so.0...done.
Loaded symbols for /usr/wwwserver/apache.2.0.49/lib/libexpat.so.0
Reading symbols from /usr/wwwserver/apache.2.0.49/lib/libapr-0.so.0...done.
Loaded symbols for /usr/wwwserver/apache.2.0.49/lib/libapr-0.so.0
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libpthread.so.0...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /Home/home2/sabol/work/httpd-apreq-2/env/.libs/mod_apreq.so...done.
Loaded symbols for /Home/home2/sabol/work/httpd-apreq-2/env/.libs/mod_apreq.so
Reading symbols from /home2/sabol/work/httpd-apreq-2/src/.libs/libapreq2.2...done.
Loaded symbols for /home2/sabol/work/httpd-apreq-2/src/.libs/libapreq2.2
Reading symbols from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so...done.
Loaded symbols for /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/APR/Table/Table.so...done.
Loaded symbols for /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/APR/Table/Table.so
Reading symbols from /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/APR/Bucket/Bucket.so...done.
Loaded symbols for /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/APR/Bucket/Bucket.so
Reading symbols from /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/APR/Brigade/Brigade.so...
done.
Loaded symbols for /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/APR/Brigade/Brigade.so
Reading symbols from /Home/home2/sabol/work/httpd-apreq-2/glue/perl/blib/arch/auto/Apache/Request/Request.so...done.
Loaded symbols for /Home/home2/sabol/work/httpd-apreq-2/glue/perl/blib/arch/auto/Apache/Request/Request.so
Reading symbols from /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/RequestIO/RequestIO.so...done.
Loaded symbols for /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/RequestIO/RequestIO.so
Reading symbols from /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/RequestRec/RequestRec.so...done.
Loaded symbols for /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/RequestRec/RequestRec.so
#0 0x40274f08 in XS_Apache__RequestRec_content_type ()
from /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/RequestRec/RequestRec.so
(gdb) bt
#0 0x40274f08 in XS_Apache__RequestRec_content_type ()
from /usr1/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/RequestRec/RequestRec.so
#1 0x401bb4e5 in Perl_pp_entersub () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#2 0x401b61ad in Perl_runops_standard () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#3 0x4017ec85 in S_call_body () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#4 0x4017ea4e in perl_call_sv () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#5 0x4016cd9b in modperl_callback () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#6 0x4016d162 in modperl_callback_run_handlers () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#7 0x4016d224 in modperl_callback_per_dir () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#8 0x4016a5ca in modperl_response_handler_run () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#9 0x4016a696 in modperl_response_handler () from /usr/wwwserver/apache.2.0.49/modules/mod_perl.so
#10 0x0808cdae in ap_run_handler (r=0x81c6728) at config.c:151
#11 0x0808d2c9 in ap_invoke_handler (r=0x81c6728) at config.c:358
#12 0x080764cb in ap_process_request (r=0x81c6728) at http_request.c:246
#13 0x080724dc in ap_process_http_connection (c=0x81be7e0) at http_core.c:250
#14 0x08095e3e in ap_run_process_connection (c=0x81be7e0) at connection.c:42
#15 0x0808ba15 in child_main (child_num_arg=0) at prefork.c:609
#16 0x0808bb5c in make_child (s=0x80cedb0, slot=0) at prefork.c:703
#17 0x0808bbb2 in startup_children (number_to_start=1) at prefork.c:721
#18 0x0808beb8 in ap_mpm_run (_pconf=0x80cbdb0, plog=0x8107ea0, s=0x80cedb0) at prefork.c:940
#19 0x080913e7 in main (argc=7, argv=0xbfffe6e4) at main.c:617
#20 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
----
Suggestions? I suspect the problem is related to Perl 5.6.1... Has anyone
ever built a working apreq2 using 5.6.1? I know I've never been successful at
it and I've tried numerous times over the past ~7 months. :-(
Re: It's time to get 2.03-dev out
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov> writes:
[...]
> I just tested a build from the CVS sources. Before starting the build,
> I blew away my httpd-apreq-2 directory and checked out a fresh copy
> from CVS. Everything seemed to work fine until I did a "make test". It
> seems env/.libs/mod_apreq.so was never created.
Yup- it looks like your box isn't appending the ".so" extension. The
problem line in the build is here (wrapped):
> gcc -shared mod_apreq.lo -Wl,--rpath
> -Wl,/home2/sabol/work/httpd-apreq-2/src/.libs -Wl,--rpath
> -Wl,/usr/wwwserver/apache.2.0.49/lib -Wl,--rpath
> -Wl,/usr/wwwserver/apache.2.0.49/lib -L/usr/lib/
> -L/usr/wwwserver/apache.2.0.49/lib ../src/.libs/libapreq2
> /usr/wwwserver/apache.2.0.49/lib/libapr-0.so -lrt -lcrypt -lnsl
> -lpthread -ldl /usr/wwwserver/apache.2.0.49/lib/libaprutil-0.so
> /usr/lib/libgdbm.so -ldb1 /usr/wwwserver/apache.2.0.49/lib/libexpat.so
> -Wl,-soname -Wl,mod_apreq -o .libs/mod_apreq
^^^^^^^^^ ^^^^^^^^^
That should be "mod_apreq.so" in both places. No clue what's
causing this misbehavior.
--
Joe Schaefer
Re: It's time to get 2.03-dev out
Posted by "Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov>.
Joe Schaefer wrote:
> Please test current cvs and report/fix any build problems; I plan
> to start the release process in a few days.
My configuration:
dual AMD processors
Linux Red Hat 7.3 + SMP + latest kernel security patches
Apache 2.0.49
mod_perl 1.99_13
Perl 5.6.1
libtool 1.4.2
autoconf 2.59
automake 1.8.2
I just tested a build from the CVS sources. Before starting the build, I blew
away my httpd-apreq-2 directory and checked out a fresh copy from CVS.
Everything seemed to work fine until I did a "make test". It seems
env/.libs/mod_apreq.so was never created.
----
waiting 60 seconds for server to start: .Syntax error on line 12 of /Home/home2/sabol/work/httpd-apreq-2/env/t/conf/httpd.conf:
Cannot load /Home/home2/sabol/work/httpd-apreq-2/env/.libs/mod_apreq.so into server: /Home/home2/sabol/work/httpd-apreq-2/env/.libs/mod_apreq.so: cannot open shared object file: No such file or directory
[ error]
server has died with status 1 (t/logs/error_log wasn't created, start the server in the debug mode)
----
% ls -l env/.libs/
total 216
-rwxr-xr-x 1 sabol man 75021 Jun 8 00:43 mod_apreq*
-rw-r--r-- 1 sabol man 72010 Jun 8 00:43 mod_apreq.a
lrwxrwxrwx 1 sabol man 15 Jun 8 00:43 mod_apreq.la -> ../mod_apreq.la
-rw-r--r-- 1 sabol man 968 Jun 8 00:43 mod_apreq.lai
-rwxr-xr-x 1 sabol man 53638 Jun 8 00:47 test_cgi*
I think this is the relevant portion of the build log:
make[1]: Entering directory `/Home/home2/sabol/work/httpd-apreq-2/env'
source='mod_apreq.c' object='mod_apreq.lo' libtool=yes \
depfile='.deps/mod_apreq.Plo' tmpdepfile='.deps/mod_apreq.TPlo' \
depmode=gcc /bin/sh ../depcomp \
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../src -I../src -I/usr/wwwserver/apache.2.0.49/include -I/usr/wwwserver/apache.2.0.49/include -I/usr/wwwserver/apache.2.0.49/include -g -O2 -c -o mod_apreq.lo mod_apreq.c
rm -f .libs/mod_apreq.lo
gcc -DHAVE_CONFIG_H -I. -I. -I../src -I../src -I/usr/wwwserver/apache.2.0.49/include -I/usr/wwwserver/apache.2.0.49/include -I/usr/wwwserver/apache.2.0.49/include -g -O2 -c mod_apreq.c -Wp,-MD,.deps/mod_apreq.TPlo -fPIC -DPIC -DPIC -o mod_apreq.o
mv -f mod_apreq.o .libs/mod_apreq.lo
gcc -DHAVE_CONFIG_H -I. -I. -I../src -I../src -I/usr/wwwserver/apache.2.0.49/include -I/usr/wwwserver/apache.2.0.49/include -I/usr/wwwserver/apache.2.0.49/include -g -O2 -c mod_apreq.c -Wp,-MD,.deps/mod_apreq.TPlo -o mod_apreq.o >/dev/null 2>&1
mv -f .libs/mod_apreq.lo mod_apreq.lo
/bin/sh ../libtool --mode=link gcc -g -O2 -o mod_apreq.la -export-dynamic -module -avoid-version -rpath `/usr/wwwserver/apache/bin/apxs -q LIBEXECDIR` mod_apreq.lo ../src/libapreq2.la /usr/wwwserver/apache.2.0.49/lib/libapr-0.la -lrt -lcrypt -lnsl -lpthread -ldl /usr/wwwserver/apache.2.0.49/lib/libaprutil-0.la -lgdbm -ldb1 -lexpat
libtool: link: warning: `/usr/lib//libgdbm.la' seems to be moved
rm -fr .libs/mod_apreq.la .libs/mod_apreq.* .libs/mod_apreq.*
gcc -shared mod_apreq.lo -Wl,--rpath -Wl,/home2/sabol/work/httpd-apreq-2/src/.libs -Wl,--rpath -Wl,/usr/wwwserver/apache.2.0.49/lib -Wl,--rpath -Wl,/usr/wwwserver/apache.2.0.49/lib -L/usr/lib/ -L/usr/wwwserver/apache.2.0.49/lib ../src/.libs/libapreq2 /usr/wwwserver/apache.2.0.49/lib/libapr-0.so -lrt -lcrypt -lnsl -lpthread -ldl /usr/wwwserver/apache.2.0.49/lib/libaprutil-0.so /usr/lib/libgdbm.so -ldb1 /usr/wwwserver/apache.2.0.49/lib/libexpat.so -Wl,-soname -Wl,mod_apreq -o .libs/mod_apreq
ar cru .libs/mod_apreq.a mod_apreq.o
ranlib .libs/mod_apreq.a
creating mod_apreq.la
(cd .libs && rm -f mod_apreq.la && ln -s ../mod_apreq.la mod_apreq.la)
make[1]: Leaving directory `/Home/home2/sabol/work/httpd-apreq-2/env'