You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by or...@apache.org on 2001/06/01 02:35:50 UTC
cvs commit: apr/build apr_hints.m4
orlikowski 01/05/31 17:35:49
Modified: build apr_hints.m4
Log:
Linux needs these options for the posix rwlocks to work.
Normally, _SVID_SOURCE and _BSD_SOURCE are defined by default.
However, we must re-define them if we define _XOPEN_SOURCE, which is needed for the rwlock definitions.
Revision Changes Path
1.14 +4 -2 apr/build/apr_hints.m4
Index: apr_hints.m4
===================================================================
RCS file: /home/cvs/apr/build/apr_hints.m4,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- apr_hints.m4 2001/05/13 11:03:59 1.13
+++ apr_hints.m4 2001/06/01 00:35:48 1.14
@@ -115,9 +115,11 @@
;;
*-linux-*)
case `uname -r` in
- 2.2* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2])
+ 2.2* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2 -D_XOPEN_SOURCE=500])
+ APR_ADDTO(CPPFLAGS, [-D_BSD_SOURCE -D_SVID_SOURCE])
;;
- 2.0* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2])
+ 2.0* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2 -D_XOPEN_SOURCE=500])
+ APR_ADDTO(CPPFLAGS, [-D_BSD_SOURCE -D_SVID_SOURCE])
;;
1.* ) APR_ADDTO(CPPFLAGS, [-DLINUX=1])
;;
Re: cvs commit: apr/build apr_hints.m4
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> On Fri, Jun 01, 2001 at 07:55:52PM -0400, Jeff Trawick wrote:
> > Greg Stein <gs...@lyra.org> writes:
> >
> > > No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
> > > Justin did are the right way to do it. We should always try to avoid
> > > hard-coding conditions to the host/library/whatever and *test* for them
> > > instead.
> > >
> > > autoconf was written to use the testing approach, rather than the "know
> > > everything about all platforms" approach that Apache 1.3 used. apr_hints is
> > > left over from the 1.3 days; ideally, we would find tests that would remove
> > > every single one of those hints.
> >
> > Which of the text below do you disagree with?
>
> I disagreed with the use of apr_hints, rather than tests. Your point about
> *timing* of those tests is entirely valid.
It seems to me that apr_hints is the only place where the timing is
correct.
-------/-------
Assume we use the design where we use configure-time tests to
determine when we need to turn on libc feature test macros.
Consider that we have system A where in order to access some pthread
function we have to turn on a feature test macro and we have system B
where in order to access some networking function we have to turn on a
feature test macro.
For system A, we'll want to test for that pthread function before all
other configure-time tests so that we'll be using the same libc
feature test macros throughout.
For system B, we'll want to test for that networking function before
all other configure-time tests so that we'll be using the same libc
feature test macros throughout.
These constraints cannot be satisified unless we restart all tests
any time we add a libc feature test macro or we implement different
orders of tests for different platforms.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/build apr_hints.m4
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 01, 2001 at 07:55:52PM -0400, Jeff Trawick wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
> > Justin did are the right way to do it. We should always try to avoid
> > hard-coding conditions to the host/library/whatever and *test* for them
> > instead.
> >
> > autoconf was written to use the testing approach, rather than the "know
> > everything about all platforms" approach that Apache 1.3 used. apr_hints is
> > left over from the 1.3 days; ideally, we would find tests that would remove
> > every single one of those hints.
>
> Which of the text below do you disagree with?
I disagreed with the use of apr_hints, rather than tests. Your point about
*timing* of those tests is entirely valid.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/build apr_hints.m4
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
> Justin did are the right way to do it. We should always try to avoid
> hard-coding conditions to the host/library/whatever and *test* for them
> instead.
>
> autoconf was written to use the testing approach, rather than the "know
> everything about all platforms" approach that Apache 1.3 used. apr_hints is
> left over from the 1.3 days; ideally, we would find tests that would remove
> every single one of those hints.
Which of the text below do you disagree with?
Jeff said previously:
>Any kind of libc feature test macros need to be turned on ASAP,
>because they could influence the outcome of other tests (whether or
>not we find an interface or which flavor of an interface we find).
>I don't think we can wait until this point in autoconfiguration to
>start turning on libc feature test macros. Maybe it will work on
>some glibc version with the current set of tests, but I don't think it
>is cool in general. It seems to me that as soon as you change libc
>feature test macros you need to start over at ground zero.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/build apr_hints.m4
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 01, 2001 at 08:01:06PM -0400, Jeff Trawick wrote:
> Justin Erenkrantz <je...@ebuilt.com> writes:
> > > No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
> > > Justin did are the right way to do it. We should always try to avoid
> > > hard-coding conditions to the host/library/whatever and *test* for them
> > > instead.
> >
> > Since the thread tests are the first real tests performed by APR's
> > autoconf - any additional CPPFLAGS (or whatnot) will get passed to
> > all subsequent tests. I think this is Jeff's concern (perfectly
> > valid - I have it too).
> >
> > Looking at configure,in, I don't think we could move the threading
> > tests around too much. It looks like it is in the right place.
> > -- justin
>
> So for this particular test on this particular platform we're fine.
>
> Later, for some other platform we find that we need to test for
> feature foo before we test for threads because feature foo is where we
> figure out that we must enable some libc feature test macro.
Sure. Are you making a point? :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/build apr_hints.m4
Posted by Jeff Trawick <tr...@bellsouth.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> > No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
> > Justin did are the right way to do it. We should always try to avoid
> > hard-coding conditions to the host/library/whatever and *test* for them
> > instead.
>
> Since the thread tests are the first real tests performed by APR's
> autoconf - any additional CPPFLAGS (or whatnot) will get passed to
> all subsequent tests. I think this is Jeff's concern (perfectly
> valid - I have it too).
>
> Looking at configure,in, I don't think we could move the threading
> tests around too much. It looks like it is in the right place.
> -- justin
So for this particular test on this particular platform we're fine.
Later, for some other platform we find that we need to test for
feature foo before we test for threads because feature foo is where we
figure out that we must enable some libc feature test macro.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/build apr_hints.m4
Posted by Justin Erenkrantz <je...@ebuilt.com>.
> No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
> Justin did are the right way to do it. We should always try to avoid
> hard-coding conditions to the host/library/whatever and *test* for them
> instead.
Since the thread tests are the first real tests performed by APR's
autoconf - any additional CPPFLAGS (or whatnot) will get passed to
all subsequent tests. I think this is Jeff's concern (perfectly
valid - I have it too).
Looking at configure,in, I don't think we could move the threading
tests around too much. It looks like it is in the right place.
-- justin
Re: cvs commit: apr/build apr_hints.m4
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 01, 2001 at 11:10:43AM -0400, Victor J. Orlikowski wrote:
> > These have to do with glibc version, not kernel version... Maybe it
> > will work fine, but it doesn't help anybody to understand why it is
> > there.
>
> Agreed. However, my logic was that these flags would only be useful in
> kernel versions that supported threading, which implies 2.0 and later.
No. I was using threads well before 2.0 came out. Threading libraries *do*
exist.
>...
> So, the right thing to do, then, is have a test based on glibc version
> in apr_hints.m4, which applies these flags whenever they are appropriate.
No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
Justin did are the right way to do it. We should always try to avoid
hard-coding conditions to the host/library/whatever and *test* for them
instead.
autoconf was written to use the testing approach, rather than the "know
everything about all platforms" approach that Apache 1.3 used. apr_hints is
left over from the 1.3 days; ideally, we would find tests that would remove
every single one of those hints.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/build apr_hints.m4
Posted by "Victor J. Orlikowski" <v....@gte.net>.
> These have to do with glibc version, not kernel version... Maybe it
> will work fine, but it doesn't help anybody to understand why it is
> there.
Agreed. However, my logic was that these flags would only be useful in
kernel versions that supported threading, which implies 2.0 and later.
Of course, the flags are glibc version dependent ultimately.
Which is why I rather like Justin's test for whether the flags are
necessary.
> Any kind of libc feature test macros need to be turned on ASAP,
> because they could influence the outcome of other tests (whether or
> not we find an interface or which flavor of an interface we find).
> I don't think we can wait until this point in autoconfiguration to
> start turning on libc feature test macros. Maybe it will work on
> some glibc version with the current set of tests, but I don't think it
> is cool in general. It seems to me that as soon as you change libc
> feature test macros you need to start over at ground zero.
>
> I think I'd feel safest with something like Victor's change but which
> looks at the glibc version instead of the kernel version.
So, the right thing to do, then, is have a test based on glibc version
in apr_hints.m4, which applies these flags whenever they are appropriate.
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: cvs commit: apr/build apr_hints.m4
Posted by Jeff Trawick <tr...@bellsouth.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> On Fri, Jun 01, 2001 at 12:35:50AM -0000, orlikowski@apache.org wrote:
> > orlikowski 01/05/31 17:35:49
> >
> > Modified: build apr_hints.m4
> > Log:
> > Linux needs these options for the posix rwlocks to work.
> > Normally, _SVID_SOURCE and _BSD_SOURCE are defined by default.
> > However, we must re-define them if we define _XOPEN_SOURCE, which is needed for the rwlock definitions.
> >
> > Revision Changes Path
> > 1.14 +4 -2 apr/build/apr_hints.m4
> >
> > Index: apr_hints.m4
> > ===================================================================
> > RCS file: /home/cvs/apr/build/apr_hints.m4,v
> > retrieving revision 1.13
> > retrieving revision 1.14
> > diff -u -r1.13 -r1.14
> > --- apr_hints.m4 2001/05/13 11:03:59 1.13
> > +++ apr_hints.m4 2001/06/01 00:35:48 1.14
> > @@ -115,9 +115,11 @@
> > ;;
> > *-linux-*)
> > case `uname -r` in
> > - 2.2* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2])
> > + 2.2* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2 -D_XOPEN_SOURCE=500])
> > + APR_ADDTO(CPPFLAGS, [-D_BSD_SOURCE -D_SVID_SOURCE])
> > ;;
> > - 2.0* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2])
> > + 2.0* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2 -D_XOPEN_SOURCE=500])
> > + APR_ADDTO(CPPFLAGS, [-D_BSD_SOURCE -D_SVID_SOURCE])
> > ;;
> > 1.* ) APR_ADDTO(CPPFLAGS, [-DLINUX=1])
> > ;;
Victor,
These have to do with glibc version, not kernel version... Maybe it
will work fine, but it doesn't help anybody to understand why it is
there.
> Won't this break 2.4? I talked to Roy before I left today and I might
> add something that does a AC_TRY_COMPILE (after seeing if
> pthread_rwlock_init is present) and punt from there (i.e. add these
> CPPFLAGS if the compile fails).
About autodetection...
Is this what you mean?
a) see if pthread_rwlock_init is present; if not, punt
b) see if pthread_rwlock_t is defined; if not, turn on those
CPPFLAGS and try again
Any kind of libc feature test macros need to be turned on ASAP,
because they could influence the outcome of other tests (whether or
not we find an interface or which flavor of an interface we find).
I don't think we can wait until this point in autoconfiguration to
start turning on libc feature test macros. Maybe it will work on
some glibc version with the current set of tests, but I don't think it
is cool in general. It seems to me that as soon as you change libc
feature test macros you need to start over at ground zero.
I think I'd feel safest with something like Victor's change but which
looks at the glibc version instead of the kernel version.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/build apr_hints.m4
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Jun 01, 2001 at 12:35:50AM -0000, orlikowski@apache.org wrote:
> orlikowski 01/05/31 17:35:49
>
> Modified: build apr_hints.m4
> Log:
> Linux needs these options for the posix rwlocks to work.
> Normally, _SVID_SOURCE and _BSD_SOURCE are defined by default.
> However, we must re-define them if we define _XOPEN_SOURCE, which is needed for the rwlock definitions.
>
> Revision Changes Path
> 1.14 +4 -2 apr/build/apr_hints.m4
>
> Index: apr_hints.m4
> ===================================================================
> RCS file: /home/cvs/apr/build/apr_hints.m4,v
> retrieving revision 1.13
> retrieving revision 1.14
> diff -u -r1.13 -r1.14
> --- apr_hints.m4 2001/05/13 11:03:59 1.13
> +++ apr_hints.m4 2001/06/01 00:35:48 1.14
> @@ -115,9 +115,11 @@
> ;;
> *-linux-*)
> case `uname -r` in
> - 2.2* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2])
> + 2.2* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2 -D_XOPEN_SOURCE=500])
> + APR_ADDTO(CPPFLAGS, [-D_BSD_SOURCE -D_SVID_SOURCE])
> ;;
> - 2.0* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2])
> + 2.0* ) APR_ADDTO(CPPFLAGS, [-DLINUX=2 -D_XOPEN_SOURCE=500])
> + APR_ADDTO(CPPFLAGS, [-D_BSD_SOURCE -D_SVID_SOURCE])
> ;;
> 1.* ) APR_ADDTO(CPPFLAGS, [-DLINUX=1])
> ;;
Won't this break 2.4? I talked to Roy before I left today and I might
add something that does a AC_TRY_COMPILE (after seeing if
pthread_rwlock_init is present) and punt from there (i.e. add these
CPPFLAGS if the compile fails).
I'm not entirely sure if I'll get around to it tonight or not.
-- justin