You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Jennifer Wong <jw...@covalent.net> on 2003/11/21 19:00:25 UTC
problems compiling flood
Hi,
I'm using Red Hat Linux 7.2, and I consistently get this error when
trying to compile flood:
flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
function)
I am using a freshly checked out and built apr and apr-util.
full build messages:
[spider@casey flood]$ ./configure
--with-apr=/local0/spider/managed_apps/httpd-
2.0/srclib/apr
--with-apr-util=/local0/spider/managed_apps/httpd-2.0/srclib/apr
-util
loading cache ./config.cache
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc -E
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether ln -s works... (cached) yes
checking whether make sets ${MAKE}... (cached) yes
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for APR... yes
checking for APR-util... yes
checking for strtoll... (cached) yes
checking for strtoq... (cached) yes
checking for rand... (cached) yes
checking for lrand48... (cached) yes
checking for random... (cached) yes
checking random number generator to use... random
creating ./config.status
creating Makefile
creating config.h
creating build/rules.mk
creating build/config_vars.mk
[spider@casey flood]$ make
/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
--mode=compile
gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
-D_XOPEN_SOURCE=500 -D
_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-I/local0/spider/managed_apps/httpd-2.0
/srclib/apr/include
-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
clude -I. -c flood.c && touch flood.lo
/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
--mode=compile
gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
-D_XOPEN_SOURCE=500 -D
_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-I/local0/spider/managed_apps/httpd-2.0
/srclib/apr/include
-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
clude -I. -c flood_round_robin.c && touch flood_round_robin.lo
/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
--mode=compile
gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
-D_XOPEN_SOURCE=500 -D
_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-I/local0/spider/managed_apps/httpd-2.0
/srclib/apr/include
-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
clude -I. -c flood_profile.c && touch flood_profile.lo
/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
--mode=compile
gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
-D_XOPEN_SOURCE=500 -D
_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-I/local0/spider/managed_apps/httpd-2.0
/srclib/apr/include
-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
clude -I. -c flood_config.c && touch flood_config.lo
/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
--mode=compile
gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
-D_XOPEN_SOURCE=500 -D
_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-I/local0/spider/managed_apps/httpd-2.0
/srclib/apr/include
-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
clude -I. -c flood_net.c && touch flood_net.lo
flood_net.c: In function `open_socket':
flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
function)
flood_net.c:118: (Each undeclared identifier is reported only once
flood_net.c:118: for each function it appears in.)
make: *** [flood_net.lo] Error 1
------------------
Jennifer Wong
415.856.4278
jwong@covalent.net
AIM: jenniferlwong
Re: problems compiling flood, REALLY Flood out of sync with
APR, ALSO note that apr_poll() no longer in APR
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 01:58 PM 11/21/2003, Norman Tuttle wrote:
>Apparently, Flood development cannot keep up with the APR development.
>This is a problem because many of the Flood features working properly is
>dependent on the APR working properly (and continuing to work). It is
>essential for those working with Flood to be able to download the latest
>APR and other Apache dependencies it has in order to benefit from the many
>bug fixes, etc., which are continuing to become available.
Whoha! The *latest APR* ... so you suggest that APR's dev branch, 1.0,
should consistently build and compile 24/7, immediately useable to flood?
<snicker>
I absolutely agree that flood aught to track the latest progress, but tracking
does imply coming 'after' the changes in apr. That change was less than
a day old, so I think you are overstating things here.
APR_1_0 does *not* exist yet. It will exist soonish. We are dropping alot
of left-over cruft that came from evolving a library that hadn't existed before
APR 0.9 was begun.
Flood should either 1) rely on the stable branch (APR_0_9_BRANCH) or
2) recommend a released tarball (0.9.4 or some such).
But I'm not discouraging authors from tracking the dev branch (HEAD), that
will soon become APR 1.0! It's great you found the dependency (apparently
a permanent one) on apr_poll. Obviously the APR project needs folks like
our test-dev'ers to tell us what you need, so the project continues to be
relevant and useful.
All of this is to say "Thanks for putting your faith in APR, and please pardon
our dust when you attempt to track cvs head!"
>Perhaps the Apache folks ought to continue to support the previous
>interfaces while making new methods available so that projects which
>have dependencies on the APR and its other subprojects can continue
>to compile.
1) we aren't Apache (server) folks when wearing our APR hats :-)
2) the old interfaces are gone, nada, goodbye.
On every major version bump (0.x -> 1.x, 1.x -> 2.x etc) we will be dumping
all deprecated interfaces. These are actually well documented in doxygen
(@deprecated tags) so that everyone knows what is going, and what had
replaced it. In these cases flood had 6+ months to change over ;-)
The authors all want apr to be lightweight and bug free. Extra, lingering,
deprecated interfaces are just one more bit of baggage that can hamper
our maintenance and end-users. Yes, it's inconvenient, but you can always
continue to use an older, previous version. APR's installed libraries are
versioned, so if you linked to libapr-0.so the big cleanup in apr 1.0 should
not get in your way.
(This includes win32. While libapr.dll is 0.x, libapr-1.dll versioned names
will be used moving forwards.)
>Your compile will probably also fail, however, when it encounters
>apr_poll(), which they apparently have also taken out of the APR.
>I'm not sure what the replacement for that is; maybe somebody on this list
>or on the APR list can enlighten us on what changes are happening there.
Yup - consensus suggests this should not have been removed. And therein
is the value of a handful of brave test-dev'ers living life on the bleeding edge :)
Bill
Re: problems compiling flood
Posted by Sander Temme <sc...@covalent.net>.
>>> You may have less grief (if you are checking out from CVS) to continue
>>> to checkout from the tag APR_0_9_BRANCH (and the corresponding tag
>>> APU_0_9_BRANCH on apr-util).
>>
>> I am not sure, and Sander Striker last weekend was not sure, what is
>> actually going on in APR branching: for instance APR 0.9.4 seems to have
>> been rolled from HEAD instead of the branch.
>
> Moving discussion to APR...
>
> ...and researching. But looking at only CHANGES 0.9.4 it seemed sane...
OK... I was looking at STATUS, from the POV that this wile would be edited
to list the release numbers and dates. Its APR_0_9_4 tag was laid on 1.192
of that file. Apparently there have been no status changes since the branch
tag was laid, so CVS has not seen fit to actually create a versioned STATUS
file.
So, I hereby eat my words.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 856 4214
303 Second Street #375 South Fax: (415) 856 4210
San Francisco CA 94107
PGP FP: 7A8D B189 E871 80CB 9521 9320 C11E 7B47 964F 31D9
=======================================================
This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and
destroy all copies of the original message
=======================================================
Re: problems compiling flood
Posted by Sander Temme <sc...@covalent.net>.
>>> You may have less grief (if you are checking out from CVS) to continue
>>> to checkout from the tag APR_0_9_BRANCH (and the corresponding tag
>>> APU_0_9_BRANCH on apr-util).
>>
>> I am not sure, and Sander Striker last weekend was not sure, what is
>> actually going on in APR branching: for instance APR 0.9.4 seems to have
>> been rolled from HEAD instead of the branch.
>
> Moving discussion to APR...
>
> ...and researching. But looking at only CHANGES 0.9.4 it seemed sane...
OK... I was looking at STATUS, from the POV that this wile would be edited
to list the release numbers and dates. Its APR_0_9_4 tag was laid on 1.192
of that file. Apparently there have been no status changes since the branch
tag was laid, so CVS has not seen fit to actually create a versioned STATUS
file.
So, I hereby eat my words.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 856 4214
303 Second Street #375 South Fax: (415) 856 4210
San Francisco CA 94107
PGP FP: 7A8D B189 E871 80CB 9521 9320 C11E 7B47 964F 31D9
=======================================================
This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and
destroy all copies of the original message
=======================================================
Re: problems compiling flood
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:29 PM 11/21/2003, Sander Temme wrote:
>> You may have less grief (if you are checking out from CVS) to continue
>> to checkout from the tag APR_0_9_BRANCH (and the corresponding tag
>> APU_0_9_BRANCH on apr-util).
>
>I am not sure, and Sander Striker last weekend was not sure, what is
>actually going on in APR branching: for instance APR 0.9.4 seems to have
>been rolled from HEAD instead of the branch.
Moving discussion to APR...
...and researching. But looking at only CHANGES 0.9.4 it seemed sane...
Revision <http://cvs.apache.org/viewcvs.cgi/*checkout*/apr/CHANGES?rev=1.426.2.2>1.426.2.2 / <http://cvs.apache.org/viewcvs/apr/CHANGES?rev=1.426.2.2&content-type=text/vnd.viewcvs-markup>(view) - <http://cvs.apache.org/viewcvs/apr/CHANGES?annotate=1.426.2.2>annotate - <http://cvs.apache.org/viewcvs/apr/CHANGES?r1=1.426.2.2>[select for diffs] , Fri Sep 19 17:07:26 2003 UTC (2 months ago) by stas
Branch: <http://cvs.apache.org/viewcvs/apr/CHANGES?only_with_tag=APR_0_9_BRANCH>APR_0_9_BRANCH
CVS Tags: <http://cvs.apache.org/viewcvs/apr/CHANGES?only_with_tag=APR_0_9_4>APR_0_9_4
Changes since 1.426.2.1: +3 -0 lines
Diff to <http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426.2.1&r2=1.426.2.2>previous 1.426.2.1 (<http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426.2.1&r2=1.426.2.2&diff_format=h>colored) to <http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426&r2=1.426.2.2>branch point 1.426 (<http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426&r2=1.426.2.2&diff_format=h>colored)
fix apr_file_dup() and apr_file_dup2() to dup the ungetchar member
Re: problems compiling flood
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:29 PM 11/21/2003, Sander Temme wrote:
>> You may have less grief (if you are checking out from CVS) to continue
>> to checkout from the tag APR_0_9_BRANCH (and the corresponding tag
>> APU_0_9_BRANCH on apr-util).
>
>I am not sure, and Sander Striker last weekend was not sure, what is
>actually going on in APR branching: for instance APR 0.9.4 seems to have
>been rolled from HEAD instead of the branch.
Moving discussion to APR...
...and researching. But looking at only CHANGES 0.9.4 it seemed sane...
Revision <http://cvs.apache.org/viewcvs.cgi/*checkout*/apr/CHANGES?rev=1.426.2.2>1.426.2.2 / <http://cvs.apache.org/viewcvs/apr/CHANGES?rev=1.426.2.2&content-type=text/vnd.viewcvs-markup>(view) - <http://cvs.apache.org/viewcvs/apr/CHANGES?annotate=1.426.2.2>annotate - <http://cvs.apache.org/viewcvs/apr/CHANGES?r1=1.426.2.2>[select for diffs] , Fri Sep 19 17:07:26 2003 UTC (2 months ago) by stas
Branch: <http://cvs.apache.org/viewcvs/apr/CHANGES?only_with_tag=APR_0_9_BRANCH>APR_0_9_BRANCH
CVS Tags: <http://cvs.apache.org/viewcvs/apr/CHANGES?only_with_tag=APR_0_9_4>APR_0_9_4
Changes since 1.426.2.1: +3 -0 lines
Diff to <http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426.2.1&r2=1.426.2.2>previous 1.426.2.1 (<http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426.2.1&r2=1.426.2.2&diff_format=h>colored) to <http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426&r2=1.426.2.2>branch point 1.426 (<http://cvs.apache.org/viewcvs/apr/CHANGES.diff?r1=1.426&r2=1.426.2.2&diff_format=h>colored)
fix apr_file_dup() and apr_file_dup2() to dup the ungetchar member
Re: problems compiling flood
Posted by Sander Temme <sc...@covalent.net>.
> You may have less grief (if you are checking out from CVS) to continue
> to checkout from the tag APR_0_9_BRANCH (and the corresponding tag
> APU_0_9_BRANCH on apr-util).
I am not sure, and Sander Striker last weekend was not sure, what is
actually going on in APR branching: for instance APR 0.9.4 seems to have
been rolled from HEAD instead of the branch.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 856 4214
303 Second Street #375 South Fax: (415) 856 4210
San Francisco CA 94107
PGP FP: 7A8D B189 E871 80CB 9521 9320 C11E 7B47 964F 31D9
Re: problems compiling flood
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
Flood users,
You may have less grief (if you are checking out from CVS) to continue
to checkout from the tag APR_0_9_BRANCH (and the corresponding tag
APU_0_9_BRANCH on apr-util).
On the other hand, it should continue to build on APR_1_0_BRANCH,
or we should adopt the appropriate patches. I've cleaned up your observed
problem below ... thanks!
Bill
At 12:00 PM 11/21/2003, Jennifer Wong wrote:
>Hi,
>I'm using Red Hat Linux 7.2, and I consistently get this error when
>trying to compile flood:
>flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
>function)
>
>I am using a freshly checked out and built apr and apr-util.
>
>
>full build messages:
>[spider@casey flood]$ ./configure
>--with-apr=/local0/spider/managed_apps/httpd-
>2.0/srclib/apr
>--with-apr-util=/local0/spider/managed_apps/httpd-2.0/srclib/apr
>-util
>loading cache ./config.cache
>checking for gcc... (cached) gcc
>checking whether the C compiler (gcc ) works... yes
>checking whether the C compiler (gcc ) is a cross-compiler... no
>checking whether we are using GNU C... (cached) yes
>checking whether gcc accepts -g... (cached) yes
>checking how to run the C preprocessor... (cached) gcc -E
>checking for a BSD compatible install... (cached) /usr/bin/install -c
>checking whether ln -s works... (cached) yes
>checking whether make sets ${MAKE}... (cached) yes
>checking host system type... i686-pc-linux-gnu
>checking target system type... i686-pc-linux-gnu
>checking build system type... i686-pc-linux-gnu
>checking for APR... yes
>checking for APR-util... yes
>checking for strtoll... (cached) yes
>checking for strtoq... (cached) yes
>checking for rand... (cached) yes
>checking for lrand48... (cached) yes
>checking for random... (cached) yes
>checking random number generator to use... random
>creating ./config.status
>creating Makefile
>creating config.h
>creating build/rules.mk
>creating build/config_vars.mk
>[spider@casey flood]$ make
>/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
>--mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
>-D_XOPEN_SOURCE=500 -D
>_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
>-I/local0/spider/managed_apps/httpd-2.0
>/srclib/apr/include
>-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
>clude -I. -c flood.c && touch flood.lo
>/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
>--mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
>-D_XOPEN_SOURCE=500 -D
>_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
>-I/local0/spider/managed_apps/httpd-2.0
>/srclib/apr/include
>-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
>clude -I. -c flood_round_robin.c && touch flood_round_robin.lo
>/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
>--mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
>-D_XOPEN_SOURCE=500 -D
>_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
>-I/local0/spider/managed_apps/httpd-2.0
>/srclib/apr/include
>-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
>clude -I. -c flood_profile.c && touch flood_profile.lo
>/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
>--mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
>-D_XOPEN_SOURCE=500 -D
>_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
>-I/local0/spider/managed_apps/httpd-2.0
>/srclib/apr/include
>-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
>clude -I. -c flood_config.c && touch flood_config.lo
>/local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
>--mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
>-D_XOPEN_SOURCE=500 -D
>_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
>-I/local0/spider/managed_apps/httpd-2.0
>/srclib/apr/include
>-I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
>clude -I. -c flood_net.c && touch flood_net.lo
>flood_net.c: In function `open_socket':
>flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
>function)
>flood_net.c:118: (Each undeclared identifier is reported only once
>flood_net.c:118: for each function it appears in.)
>make: *** [flood_net.lo] Error 1
>------------------
>Jennifer Wong
>415.856.4278
>jwong@covalent.net
>AIM: jenniferlwong
>
Re: problems compiling flood, REALLY Flood out of sync with APR,
ALSO note that apr_poll() no longer in APR
Posted by Norman Tuttle <nt...@photon.poly.edu>.
Looks like they're in the process of putting apr_poll() back in APR, so
that will hopefully not be an issue. Let's keep the group informed of our
continued efforts at synchronizing the APR projects.
-Norman Tuttle, developer, OpenDemand Systems, ntuttle@opendemand.com
On Fri, 21 Nov 2003, Norman Tuttle wrote:
> Apparently, Flood development cannot keep up with the APR development.
> This is a problem because many of the Flood features working properly is
> dependent on the APR working properly (and continuing to work). It is
> essential for those working with Flood to be able to download the latest
> APR and other Apache dependencies it has in order to benefit from the many
> bug fixes, etc., which are continuing to become available. Perhaps the
> Apache folks ought to continue to support the previous interfaces while
> making new methods available so that projects which have dependencies on
> the APR and its other subprojects can continue to compile.
>
> With that said, the replacement for
> apr_socket_opt_set(fs->socket, APR_SO_TIMEOUT, LOCAL_SOCKET_TIMEOUT);
> in flood_net.c should be
> apr_socket_timeout_set(fs->socket, LOCAL_SOCKET_TIMEOUT);
>
> Your compile will probably also fail, however, when it encounters
> apr_poll(), which they apparently have also taken out of the APR.
> I'm not sure what the replacement for that is; maybe somebody on this list
> or on the APR list can enlighten us on what changes are happening there.
>
> -Norman Tuttle, developer, OpenDemand Systems, ntuttle@opendemand.com
>
> On Fri, 21 Nov 2003, Jennifer Wong wrote:
>
> > Hi,
> > I'm using Red Hat Linux 7.2, and I consistently get this error when
> > trying to compile flood:
> > flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
> > function)
> >
> > I am using a freshly checked out and built apr and apr-util.
> >
> >
> > full build messages:
> > [spider@casey flood]$ ./configure
> > --with-apr=/local0/spider/managed_apps/httpd-
> > 2.0/srclib/apr
> > --with-apr-util=/local0/spider/managed_apps/httpd-2.0/srclib/apr
> > -util
> > loading cache ./config.cache
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc ) works... yes
> > checking whether the C compiler (gcc ) is a cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> > checking how to run the C preprocessor... (cached) gcc -E
> > checking for a BSD compatible install... (cached) /usr/bin/install -c
> > checking whether ln -s works... (cached) yes
> > checking whether make sets ${MAKE}... (cached) yes
> > checking host system type... i686-pc-linux-gnu
> > checking target system type... i686-pc-linux-gnu
> > checking build system type... i686-pc-linux-gnu
> > checking for APR... yes
> > checking for APR-util... yes
> > checking for strtoll... (cached) yes
> > checking for strtoq... (cached) yes
> > checking for rand... (cached) yes
> > checking for lrand48... (cached) yes
> > checking for random... (cached) yes
> > checking random number generator to use... random
> > creating ./config.status
> > creating Makefile
> > creating config.h
> > creating build/rules.mk
> > creating build/config_vars.mk
> > [spider@casey flood]$ make
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood.c && touch flood.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_round_robin.c && touch flood_round_robin.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_profile.c && touch flood_profile.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_config.c && touch flood_config.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_net.c && touch flood_net.lo
> > flood_net.c: In function `open_socket':
> > flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
> > function)
> > flood_net.c:118: (Each undeclared identifier is reported only once
> > flood_net.c:118: for each function it appears in.)
> > make: *** [flood_net.lo] Error 1
> > ------------------
> > Jennifer Wong
> > 415.856.4278
> > jwong@covalent.net
> > AIM: jenniferlwong
> >
> >
> >
>
>
Re: problems compiling flood, REALLY Flood out of sync with APR,
etc., ALSO apr_uri_default_port_for_scheme() name changed
Posted by Norman Tuttle <nt...@photon.poly.edu>.
Note that flood_round_robin.c's apr_uri_default_port_for_scheme() now must
also become apr_uri_port_of_scheme() to match the latest apr-util.lib.
apr_poll has been put back.
-Norman Tuttle ntuttle@photon.poly.edu
On Fri, 21 Nov 2003, Norman Tuttle wrote:
> Apparently, Flood development cannot keep up with the APR development.
> This is a problem because many of the Flood features working properly is
> dependent on the APR working properly (and continuing to work). It is
> essential for those working with Flood to be able to download the latest
> APR and other Apache dependencies it has in order to benefit from the many
> bug fixes, etc., which are continuing to become available. Perhaps the
> Apache folks ought to continue to support the previous interfaces while
> making new methods available so that projects which have dependencies on
> the APR and its other subprojects can continue to compile.
>
> With that said, the replacement for
> apr_socket_opt_set(fs->socket, APR_SO_TIMEOUT, LOCAL_SOCKET_TIMEOUT);
> in flood_net.c should be
> apr_socket_timeout_set(fs->socket, LOCAL_SOCKET_TIMEOUT);
>
> Your compile will probably also fail, however, when it encounters
> apr_poll(), which they apparently have also taken out of the APR.
> I'm not sure what the replacement for that is; maybe somebody on this list
> or on the APR list can enlighten us on what changes are happening there.
>
> -Norman Tuttle, developer, OpenDemand Systems, ntuttle@opendemand.com
>
> On Fri, 21 Nov 2003, Jennifer Wong wrote:
>
> > Hi,
> > I'm using Red Hat Linux 7.2, and I consistently get this error when
> > trying to compile flood:
> > flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
> > function)
> >
> > I am using a freshly checked out and built apr and apr-util.
> >
> >
> > full build messages:
> > [spider@casey flood]$ ./configure
> > --with-apr=/local0/spider/managed_apps/httpd-
> > 2.0/srclib/apr
> > --with-apr-util=/local0/spider/managed_apps/httpd-2.0/srclib/apr
> > -util
> > loading cache ./config.cache
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc ) works... yes
> > checking whether the C compiler (gcc ) is a cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> > checking how to run the C preprocessor... (cached) gcc -E
> > checking for a BSD compatible install... (cached) /usr/bin/install -c
> > checking whether ln -s works... (cached) yes
> > checking whether make sets ${MAKE}... (cached) yes
> > checking host system type... i686-pc-linux-gnu
> > checking target system type... i686-pc-linux-gnu
> > checking build system type... i686-pc-linux-gnu
> > checking for APR... yes
> > checking for APR-util... yes
> > checking for strtoll... (cached) yes
> > checking for strtoq... (cached) yes
> > checking for rand... (cached) yes
> > checking for lrand48... (cached) yes
> > checking for random... (cached) yes
> > checking random number generator to use... random
> > creating ./config.status
> > creating Makefile
> > creating config.h
> > creating build/rules.mk
> > creating build/config_vars.mk
> > [spider@casey flood]$ make
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood.c && touch flood.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_round_robin.c && touch flood_round_robin.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_profile.c && touch flood_profile.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_config.c && touch flood_config.lo
> > /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> > --mode=compile
> > gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> > -D_XOPEN_SOURCE=500 -D
> > _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -I/local0/spider/managed_apps/httpd-2.0
> > /srclib/apr/include
> > -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> > clude -I. -c flood_net.c && touch flood_net.lo
> > flood_net.c: In function `open_socket':
> > flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
> > function)
> > flood_net.c:118: (Each undeclared identifier is reported only once
> > flood_net.c:118: for each function it appears in.)
> > make: *** [flood_net.lo] Error 1
> > ------------------
> > Jennifer Wong
> > 415.856.4278
> > jwong@covalent.net
> > AIM: jenniferlwong
> >
> >
> >
>
>
Re: problems compiling flood, REALLY Flood out of sync with APR,
ALSO note that apr_poll() no longer in APR
Posted by Norman Tuttle <nt...@photon.poly.edu>.
Apparently, Flood development cannot keep up with the APR development.
This is a problem because many of the Flood features working properly is
dependent on the APR working properly (and continuing to work). It is
essential for those working with Flood to be able to download the latest
APR and other Apache dependencies it has in order to benefit from the many
bug fixes, etc., which are continuing to become available. Perhaps the
Apache folks ought to continue to support the previous interfaces while
making new methods available so that projects which have dependencies on
the APR and its other subprojects can continue to compile.
With that said, the replacement for
apr_socket_opt_set(fs->socket, APR_SO_TIMEOUT, LOCAL_SOCKET_TIMEOUT);
in flood_net.c should be
apr_socket_timeout_set(fs->socket, LOCAL_SOCKET_TIMEOUT);
Your compile will probably also fail, however, when it encounters
apr_poll(), which they apparently have also taken out of the APR.
I'm not sure what the replacement for that is; maybe somebody on this list
or on the APR list can enlighten us on what changes are happening there.
-Norman Tuttle, developer, OpenDemand Systems, ntuttle@opendemand.com
On Fri, 21 Nov 2003, Jennifer Wong wrote:
> Hi,
> I'm using Red Hat Linux 7.2, and I consistently get this error when
> trying to compile flood:
> flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
> function)
>
> I am using a freshly checked out and built apr and apr-util.
>
>
> full build messages:
> [spider@casey flood]$ ./configure
> --with-apr=/local0/spider/managed_apps/httpd-
> 2.0/srclib/apr
> --with-apr-util=/local0/spider/managed_apps/httpd-2.0/srclib/apr
> -util
> loading cache ./config.cache
> checking for gcc... (cached) gcc
> checking whether the C compiler (gcc ) works... yes
> checking whether the C compiler (gcc ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking how to run the C preprocessor... (cached) gcc -E
> checking for a BSD compatible install... (cached) /usr/bin/install -c
> checking whether ln -s works... (cached) yes
> checking whether make sets ${MAKE}... (cached) yes
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking build system type... i686-pc-linux-gnu
> checking for APR... yes
> checking for APR-util... yes
> checking for strtoll... (cached) yes
> checking for strtoq... (cached) yes
> checking for rand... (cached) yes
> checking for lrand48... (cached) yes
> checking for random... (cached) yes
> checking random number generator to use... random
> creating ./config.status
> creating Makefile
> creating config.h
> creating build/rules.mk
> creating build/config_vars.mk
> [spider@casey flood]$ make
> /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> --mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> -D_XOPEN_SOURCE=500 -D
> _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> -I/local0/spider/managed_apps/httpd-2.0
> /srclib/apr/include
> -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> clude -I. -c flood.c && touch flood.lo
> /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> --mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> -D_XOPEN_SOURCE=500 -D
> _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> -I/local0/spider/managed_apps/httpd-2.0
> /srclib/apr/include
> -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> clude -I. -c flood_round_robin.c && touch flood_round_robin.lo
> /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> --mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> -D_XOPEN_SOURCE=500 -D
> _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> -I/local0/spider/managed_apps/httpd-2.0
> /srclib/apr/include
> -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> clude -I. -c flood_profile.c && touch flood_profile.lo
> /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> --mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> -D_XOPEN_SOURCE=500 -D
> _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> -I/local0/spider/managed_apps/httpd-2.0
> /srclib/apr/include
> -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> clude -I. -c flood_config.c && touch flood_config.lo
> /local0/spider/managed_apps/httpd-2.0/srclib/apr/libtool --silent
> --mode=compile
> gcc -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT
> -D_XOPEN_SOURCE=500 -D
> _BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> -I/local0/spider/managed_apps/httpd-2.0
> /srclib/apr/include
> -I/local0/spider/managed_apps/httpd-2.0/srclib/apr-util/in
> clude -I. -c flood_net.c && touch flood_net.lo
> flood_net.c: In function `open_socket':
> flood_net.c:118: `APR_SO_TIMEOUT' undeclared (first use in this
> function)
> flood_net.c:118: (Each undeclared identifier is reported only once
> flood_net.c:118: for each function it appears in.)
> make: *** [flood_net.lo] Error 1
> ------------------
> Jennifer Wong
> 415.856.4278
> jwong@covalent.net
> AIM: jenniferlwong
>
>
>