> 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 ====================== [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
