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 Norman Tuttle <nt...@photon.poly.edu> on 2003/11/21 20:58:58 UTC
Re: problems compiling flood, REALLY Flood out of sync with APR,
ALSO note that apr_poll() no longer in APR
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>.
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 "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