Re: cvs commit: apr configure.in
--On Wednesday, July 7, 2004 7:40 AM + [EMAIL PROTECTED] wrote: jorton 2004/07/07 00:40:12 Modified:poll/unix poll.c .configure.in Log: * poll/unix/poll.c (backend_cleanup): Only define if using epoll/kqueue. (apr_pollset_destroy): Only run cleanup if using epoll/kqueue. (apr_pollset_add): Fix warning for ye olde platforms still using poll(). I changed this from Paul's patch on purpose. Why shouldn't we always define the cleanup even if we don't have kqueue or epoll? If we add Solaris's /dev/poll, we'd need a cleanup. I see only the fallback implementation perhaps not needing it - almost any real implementation would. I thought doing it your way makes the code a lot less clean. *shrug* -- justin
Re: cvs commit: apr configure.in
On Thu, Jul 08, 2004 at 12:04:48AM -0700, Justin Erenkrantz wrote: --On Wednesday, July 7, 2004 7:40 AM + [EMAIL PROTECTED] wrote: jorton 2004/07/07 00:40:12 Modified:poll/unix poll.c .configure.in Log: * poll/unix/poll.c (backend_cleanup): Only define if using epoll/kqueue. (apr_pollset_destroy): Only run cleanup if using epoll/kqueue. (apr_pollset_add): Fix warning for ye olde platforms still using poll(). I changed this from Paul's patch on purpose. Why shouldn't we always define the cleanup even if we don't have kqueue or epoll? Since we know the cleanup does nothing, defining it unnecessarily wastes both a few bytes of code size and a few cycles at run-time. e.g. since the cleanup is never registered for the non-epoll/kqueue case, running apr_pool_cleanup_destroy() will iterate over the whole cleanup list looking for it if apr_poll_destroy() is called. If we add Solaris's /dev/poll, we'd need a cleanup. I see only the fallback implementation perhaps not needing it - almost any real implementation would. I thought doing it your way makes the code a lot less clean. The unreal? poll/select implementations will be used on the majority of APR platforms and do *not* currently require a cleanup, no perhaps about it. This is just a minor optimisation with minor cleanliness cost for the majority of platforms, I don't think it's a big deal. joe
Re: cvs commit: apr configure.in config.layout
jorton 2004/06/30 06:16:54 Modified:.configure.in config.layout Log: * configure.in, config.layout: Add -version suffix to default installbuilddir directory. Revision ChangesPath 1.593 +1 -1 apr/configure.in This looks like a change that should go into 1.0...
Re: cvs commit: apr configure.in
On Tue, Jun 29, 2004 at 02:10:48PM -, [EMAIL PROTECTED] wrote: --- configure.in14 Jun 2004 21:16:40 - 1.589 +++ configure.in29 Jun 2004 14:10:48 - 1.590 @@ -522,6 +522,8 @@ AC_SEARCH_LIBS(gethostbyname, nsl) AC_SEARCH_LIBS(gethostname, nsl) AC_SEARCH_LIBS(socket, socket) +dnl Search for -lbind / -lresolv only after having added -lsocket and -lnsl +AC_SEARCH_LIBS(res_init, bind resolv) This is not right, res_init() is not used anywhere inside APR so configure will pick up -lresolv unnecessarily on many platforms. What are you trying to solve here? joe
Re: cvs commit: apr configure.in CHANGES
[EMAIL PROTECTED] wrote: jorton 2004/01/29 00:33:41 Modified:.Tag: APR_0_9_BRANCH configure.in CHANGES Log: * configure.in: Define apr_off_t as an apr_intX_t type rather than off_t to prevent the size of apr_off_t being affected by the _FILE_OFFSET_BITS definition on LFS systems. (since Other Software is known to export changes to _FILE_OFFSET_BITS as part of its API) Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.535.2.3 retrieving revision 1.535.2.4 diff -b -d -u -r1.535.2.3 -r1.535.2.4 --- configure.in 27 Jan 2004 09:59:31 - 1.535.2.3 +++ configure.in 29 Jan 2004 08:33:41 - 1.535.2.4 +elif test $ac_cv_sizeof_off_t = 4; then +off_t_value='apr_int32_t' +off_t_fmt='#define APR_OFF_T_FMT APR_INT32_T_FMT' APR_INT32_T_FMT isn't showing up in apr.h for me, leading to compile failure for references to APR_OFF_T_FMT
Re: cvs commit: apr configure.in CHANGES
On Thu, Jan 29, 2004 at 08:44:07AM -0500, Jeff Trawick wrote: APR_INT32_T_FMT isn't showing up in apr.h for me, leading to compile failure for references to APR_OFF_T_FMT Sorry, fixed now.
Re: cvs commit: apr configure.in
On Mon, Dec 08, 2003 at 11:20:25PM -, Greg Ames wrote: gregames2003/12/08 15:20:25 Modified:.configure.in Log: allow non-portable atomics on Linux/ppc BTW, is this new asm really non-portable, or would it work on any Linux ppc64 boxes? joe
Re: cvs commit: apr configure.in
Aaron Bannert wrote: On Nov 6, 2003, at 8:55 AM, Joe Orton wrote: On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote: What is this and the APR_IS_BIGENDIAN macro used for? Do we have any code that is endian-dependent? $ grep -l -r --include \*.c APR_IS_BIGENDIAN . ./random/unix/sha2.c Ah, I didn't pick up the new directory in my last cvs update, so I didn't see it. Thanks. I don't understand the use of REVERSE32, why isn't htonl() and ntohl() used? Hmm. They might work, but they're there for a different reason, I guess. And for REVERSE64, is there a longword version of h-to-n/n-to-h that we could use instead? I doubt there's a portable one. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] wrote: jorton 2003/11/06 01:18:22 Modified:.configure.in Log: * configure.in: Fix endianness detection with autoconf 2.1x. Speaking of autoconf, I get this every time: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. do we care? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: apr configure.in
What is this and the APR_IS_BIGENDIAN macro used for? Do we have any code that is endian-dependent? -aaron On Thu, Nov 06, 2003 at 09:18:23AM -, [EMAIL PROTECTED] wrote: jorton 2003/11/06 01:18:22 Modified:.configure.in Log: * configure.in: Fix endianness detection with autoconf 2.1x. Revision ChangesPath 1.551 +7 -2 apr/configure.in Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.550 retrieving revision 1.551 diff -u -u -r1.550 -r1.551 --- configure.in5 Nov 2003 15:32:28 - 1.550 +++ configure.in6 Nov 2003 09:18:22 - 1.551 @@ -1188,8 +1188,13 @@ pid_t_fmt='#error Can not determine the proper size for pid_t' fi -dnl Checks for endianness -AC_C_BIGENDIAN([bigendian=1],[bigendian=0]) +# Checks for endianness +AC_C_BIGENDIAN +if test $ac_cv_c_bigendian = yes; then +bigendian=1 +else +bigendian=0 +fi # Basically, we have tried to figure out the correct format strings # for APR types which vary between platforms, but we don't always get
Re: cvs commit: apr configure.in
On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote: What is this and the APR_IS_BIGENDIAN macro used for? Do we have any code that is endian-dependent? $ grep -l -r --include \*.c APR_IS_BIGENDIAN . ./random/unix/sha2.c On Thu, Nov 06, 2003 at 09:18:23AM -, [EMAIL PROTECTED] wrote: jorton 2003/11/06 01:18:22 Modified:.configure.in Log: * configure.in: Fix endianness detection with autoconf 2.1x.
Re: cvs commit: apr configure.in
On Nov 6, 2003, at 8:55 AM, Joe Orton wrote: On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote: What is this and the APR_IS_BIGENDIAN macro used for? Do we have any code that is endian-dependent? $ grep -l -r --include \*.c APR_IS_BIGENDIAN . ./random/unix/sha2.c Ah, I didn't pick up the new directory in my last cvs update, so I didn't see it. Thanks. I don't understand the use of REVERSE32, why isn't htonl() and ntohl() used? And for REVERSE64, is there a longword version of h-to-n/n-to-h that we could use instead? -aaron
Re: cvs commit: apr configure.in Makefile.in
On Mon, Sep 29, 2003 at 02:20:02PM -, [EMAIL PROTECTED] wrote: ... $(TARGET_LIB): @for i in $(SUBDIRS); do objects=$$objects $$i/[EMAIL PROTECTED]@; done ; \ - tmpcmd=$(LINK) @lib_target@ @lib_target_libs@; \ + tmpcmd=$(LINK) @lib_target@ $(ALL_LIBS); \ echo $$tmpcmd; \ $$tmpcmd touch $@ Hmm, this probably breaks the --without-libtool build - does anybody actually use that configuration?
Re: cvs commit: apr configure.in CHANGES
--On Friday, August 29, 2003 10:26 AM +0100 Colm MacCarthaigh [EMAIL PROTECTED] wrote: Is that a real DNS server, or lookupd ? Am I right in thinking lookupd is more or less what everone else calls nscd? It's going to a real DNS server. And, yes, AIUI, lookupd is essentially nscd. (Although, I think lookupd isn't optional like nscd is.) Nope :) DNS servers don't even understand IPv4 addresses in that sense, you can't query a DNS server saying give me the reverse of this IPv4 addresss, your resolver has to turn 209.237.227.195 into 195.227.237.209.in-addr.arpa for anything to happen. In the case of IPv6 there are two reverse zones it should be asking for, so for 2001:770:18:2:260:CFFF:FE20:F45C it should be asking for; Okay, now I know why IPv6 will never take off. This is total lameness. Assuming RFC2553; I guess it's technically not a bug. But as far as the POSIX standard (I believe) and RFC3493 (which obsoletes 2553) are concerned, it's a bug. But that's a bit unfair since those standards are only 3 months old ;) It definitely is unusual in the world of getnameinfo() implementations, everyone else it did the sensible thing. Okay, I took your patch and added some autoconf-fu to try to detect this case. Please let me know how this looks and how it works. -- justin
Re: cvs commit: apr configure.in CHANGES
On Sun, Aug 31, 2003 at 09:34:46AM -0700, Justin Erenkrantz wrote:
Nope :) DNS servers don't even understand IPv4 addresses in that
sense, you can't query a DNS server saying give me the reverse
of this IPv4 addresss, your resolver has to turn 209.237.227.195
into 195.227.237.209.in-addr.arpa for anything to happen. In the
case of IPv6 there are two reverse zones it should be asking for,
so for 2001:770:18:2:260:CFFF:FE20:F45C it should be asking for;
Okay, now I know why IPv6 will never take off. This is total lameness.
What do mean never take off ? It's taken off, it's here, in production!
I could go on at length about this comment .. more seriously though,
it might be time daedalus was acessible over IPv6 (imo). Just using 6to4
until a native feed could arrive.
Okay, I took your patch and added some autoconf-fu to try to detect this
case.
The patch for sockaddr.c is great, works fine. The autoconf-fu
needs some tweaks to work/compile :) ;
Index: configure.in
===
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.534
diff -u -r1.534 configure.in
--- configure.in31 Aug 2003 16:28:54 - 1.534
+++ configure.in31 Aug 2003 17:44:13 -
@@ -894,6 +894,7 @@
APR_FLAG_HEADERS(
alloca.h\
+assert.h\
ByteOrder.h\
conio.h\
crypt.h\
Index: build/apr_network.m4
===
RCS file: /home/cvspublic/apr/build/apr_network.m4,v
retrieving revision 1.20
diff -u -r1.20 apr_network.m4
--- build/apr_network.m431 Aug 2003 16:28:55 - 1.20
+++ build/apr_network.m431 Aug 2003 17:44:16 -
@@ -164,6 +164,9 @@
#ifdef HAVE_NETINET_IN_H
#include netinet/in.h
#endif
+#ifdef HAVE_ASSERT_H
+#include assert.h
+#endif
void main(void) {
struct sockaddr_in6 sa = {0};
@@ -180,7 +183,7 @@
addr32 = (unsigned int *)sa.sin6_addr;
addr32[2] = htonl(0x);
addr32[3] = ipv4.s_addr;
-assert(IN6_IS_ADDR_V4MAPPED(sin6.sin6_addr));
+assert(IN6_IS_ADDR_V4MAPPED(sa.sin6_addr));
#ifdef SIN6_LEN
sa.sin_len = sizeof(sa);
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/
Re: cvs commit: apr configure.in CHANGES
--On Thursday, August 28, 2003 10:54 AM +0100 Colm MacCarthaigh [EMAIL PROTECTED] wrote: If gni_mapped worked for you then something is definitely different anyway. Well, I did some more tracing of what's going on. Darwin's getnameinfo() isn't handling the IPv6-IPv4 mapping, so it is sending the address to its DNS server to be reversed looked up without modification. Aren't DNS servers supposed to understand these IPv4-mapped addresses too? That is, must the client resolver detect and downgrade automatically? (Looking at glibc, that's exactly what it does in resolv/nss_dns/dns-host.c.) Also, upon review of the manpages and RFC 2553, getipnodebyaddr is the only one expliclitly to handle IPv4-mapped addresses. So, adding that call to Jeff's gni_mapped.c yields: look up via IPv4: 0,0/www.ibm.com look up via IPv6: 8,0/not found look up via IPv6: 0,0/www.ibm.com where the code looks like: struct hostent *hptr; hptr = getipnodebyaddr(sin6.sin6_addr, sizeof sin6.sin6_addr, sin6.sin6_family, rc); printf(look up via IPv6: %d,%d/%s\n, rc, errno, hptr-h_name); freehostent(hptr); Also, the BUGS for the Darwin impl say: The current implementation is not thread-safe. So, yes, I guess we can step down for the resolver as your patch did. But, I'm wondering whether this is really a 'bug' in Darwin. -- justin
Re: cvs commit: apr configure.in CHANGES
On Thu, Aug 28, 2003 at 09:56:14PM -0700, Justin Erenkrantz wrote: --On Thursday, August 28, 2003 10:54 AM +0100 Colm MacCarthaigh [EMAIL PROTECTED] wrote: If gni_mapped worked for you then something is definitely different anyway. Well, I did some more tracing of what's going on. Darwin's getnameinfo() isn't handling the IPv6-IPv4 mapping, so it is sending the address to its DNS server to be reversed looked up without modification. Is that a real DNS server, or lookupd ? Am I right in thinking lookupd is more or less what everone else calls nscd? Aren't DNS servers supposed to understand these IPv4-mapped addresses too? Nope :) DNS servers don't even understand IPv4 addresses in that sense, you can't query a DNS server saying give me the reverse of this IPv4 addresss, your resolver has to turn 209.237.227.195 into 195.227.237.209.in-addr.arpa for anything to happen. In the case of IPv6 there are two reverse zones it should be asking for, so for 2001:770:18:2:260:CFFF:FE20:F45C it should be asking for; C.5.4.F.0.2.E.F.F.F.F.C.0.6.2.0.2.0.0.0.8.1.0.0.0.7.7.0.1.0.0.2.ip6.int and C.5.4.F.0.2.E.F.F.F.F.C.0.6.2.0.2.0.0.0.8.1.0.0.0.7.7.0.1.0.0.2.ip6.arpa In the case of an IPv4 mapped address; :::209.237.227.195 would be mapped to : 3.c.3.e.d.e.1.d.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.(int|arpa) And this isnt goign to get very far! That is, must the client resolver detect and downgrade automatically? (Looking at glibc, that's exactly what it does in resolv/nss_dns/dns-host.c.) Yep :) From RFC3493, section 6.2 : on getnameinfo; If the socket address structure contains an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, the implementation shall extract the embedded IPv4 address and lookup the node name for that IPv4 address. Also, upon review of the manpages and RFC 2553, getipnodebyaddr is the only one expliclitly to handle IPv4-mapped addresses. Yep, this is one of the reasons why RFC2553 needed a good rewrite :) So, adding that call to Jeff's gni_mapped.c yields: look up via IPv4: 0,0/www.ibm.com look up via IPv6: 8,0/not found look up via IPv6: 0,0/www.ibm.com where the code looks like: struct hostent *hptr; hptr = getipnodebyaddr(sin6.sin6_addr, sizeof sin6.sin6_addr, sin6.sin6_family, rc); printf(look up via IPv6: %d,%d/%s\n, rc, errno, hptr-h_name); freehostent(hptr); getipnodebyaddr has functionality that pushed into getnameinfo more recently, and this is one of them. getipnodebyaddr() is deprecated by RFC3493 and it's use is now discouraged. So I really would recommend against putting it into APR. Also, the BUGS for the Darwin impl say: The current implementation is not thread-safe. So, yes, I guess we can step down for the resolver as your patch did. But, I'm wondering whether this is really a 'bug' in Darwin. -- justin Assuming RFC2553; I guess it's technically not a bug. But as far as the POSIX standard (I believe) and RFC3493 (which obsoletes 2553) are concerned, it's a bug. But that's a bit unfair since those standards are only 3 months old ;) It definitely is unusual in the world of getnameinfo() implementations, everyone else it did the sensible thing. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.stdlib.net/
Re: cvs commit: apr configure.in CHANGES
--On Tuesday, August 26, 2003 6:56 AM -0400 Jeff Trawick [EMAIL PROTECTED] wrote: Yeah, that looks reasonable :) I'm still curious about what was happening on Justin's system. No clue, either. =) I very well may have gotten what was working mixed up, sorry. What I do know is that host-based authorization is working AFAICT. So, I'm not sure that this particular code path is indicative of the original problem we saw. That is, I'm not sure how we'd ever execute the code path, or if we are, it isn't showing signs of failure. If it is failing, I'd like a clear example of its failure. (What we was posted last year appears to be working.) And, if there is a legitimate bug in Darwin's handling of something, we should file a bug report with Apple. Not sure whom the best person to file it would be. -- justin
Re: cvs commit: apr configure.in CHANGES
Justin Erenkrantz [EMAIL PROTECTED] writes: --On Tuesday, August 26, 2003 6:56 AM -0400 Jeff Trawick [EMAIL PROTECTED] wrote: Yeah, that looks reasonable :) I'm still curious about what was happening on Justin's system. No clue, either. =) I very well may have gotten what was working mixed up, sorry. What I do know is that host-based authorization is working AFAICT. So, I'm not sure that this particular code path is indicative of the original problem we saw. That is, I'm not sure how we'd ever execute the code path, or if we are, it isn't showing signs of failure. If it is failing, I'd like a clear example of its failure. (What we was posted last year appears to be working. ) And, if there is a legitimate bug in Darwin's handling of something, we shoul d file a bug report with Apple. Not sure whom the best person to file it would be. -- justin I'll be glad to file any Darwin bugs if you want to shoot them to me. If you or someone else files them, please be sure to send me the Radar number so that I can 1) add my 2 cents and 2) track it 3) possibly harass (dis)interested parties at Apple. :-) -Fitz -- Brian W. Fitzpatrick[EMAIL PROTECTED] http://www.red-bean.com/fitz/
Re: cvs commit: apr configure.in CHANGES
On Wed, Aug 27, 2003 at 09:13:03PM -0700, Justin Erenkrantz wrote: Yeah, that looks reasonable :) I'm still curious about what was happening on Justin's system. No clue, either. =) I very well may have gotten what was working mixed up, sorry. If gni_mapped worked for you then something is definitely different anyway. What I do know is that host-based authorization is working AFAICT. So, I'm not sure that this particular code path is indicative of the original problem we saw. That is, I'm not sure how we'd ever execute the code path, or if we are, it isn't showing signs of failure. If it is failing, I'd like a clear example of its failure. (What we was posted last year appears to be working.) But if gni_mapped works for you this is expected :) And, if there is a legitimate bug in Darwin's handling of something, we should file a bug report with Apple. Not sure whom the best person to file it would be. -- justin It very much looks like some peoples Darwin installs have a broken getnameinfo() and some don't. The bug could be in libc, libresolv (if any), libsocket, lookupd or libbind (in fact there's an indentical old bug in libbind that caused this behaviour so if libc/lookupd use it that could be the trigger). But anyway ... in the meantime can I persuade you (or someone) to commit that patch anyway ? It does no harm on working systems and will fix the broken ones. It's a pity to not have IPv6 working on Darwin because of a small bug with a trivial work-around :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.stdlib.net/
Re: cvs commit: apr configure.in CHANGES
Colm MacCarthaigh wrote: On Mon, Aug 25, 2003 at 12:59:42PM -0400, Jeff Trawick wrote: So what do you get on your system? I must be missing some OS X fix... (But this box is running straight Jaguar with all available updates from Software Update installed.) This is what my darwin-using friends have been telling me aswell. Can you try: --- gni_mapped.c Sat Feb 15 00:18:30 2003 +++ gni_mapped2.c Mon Aug 25 17:40:15 2003 @@ -37,8 +37,10 @@ rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof hostbuf, NULL, 0, 0); printf(look up via IPv4: %d/%s\n, rc, hostbuf); +sin.sin_addr.s_addr = sin6.sin6_addr.s6_addr32[3]; the presence of this line doesn't make any difference on my box compiling with -DKERNEL picks up the s6_addr32 macro on Jaguar + strcpy(hostbuf, not found); -rc = getnameinfo((struct sockaddr *)sin6, sizeof sin6, hostbuf, sizeof hostbuf, NULL, 0, NI_NAMEREQD); +rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof hostbuf, NULL, 0, 0); printf(look up via IPv6: %d/%s\n, rc, hostbuf); without the NI_NAMEREQD flag, with our without the line you added previously, I get look up via IPv6: 0/:::812a:1263 return 0; Where .s6_addr32 is the appropriate member of sin6_addr on darwin, for BSDs it should be: sin6.sin6_addr.__u6_addr.__u6_addr32[3]; That will tell if the patch would fix thigns (which it does for my friends). which patch are we talking about?
Re: cvs commit: apr configure.in CHANGES
On Mon, Aug 25, 2003 at 01:54:19PM -0400, Jeff Trawick wrote:
--- gni_mapped.c Sat Feb 15 00:18:30 2003
+++ gni_mapped2.cMon Aug 25 17:40:15 2003
@@ -37,8 +37,10 @@
rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof
hostbuf, NULL, 0, 0);
printf(look up via IPv4: %d/%s\n, rc, hostbuf);
+sin.sin_addr.s_addr = sin6.sin6_addr.s6_addr32[3];
the presence of this line doesn't make any difference on my box
compiling with -DKERNEL picks up the s6_addr32 macro on Jaguar
+
strcpy(hostbuf, not found);
-rc = getnameinfo((struct sockaddr *)sin6, sizeof sin6, hostbuf,
sizeof hostbuf, NULL, 0, NI_NAMEREQD);
+rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof
hostbuf, NULL, 0, 0);
printf(look up via IPv6: %d/%s\n, rc, hostbuf);
without the NI_NAMEREQD flag, with our without the line you added
previously, I get
look up via IPv6: 0/:::812a:1263
Hmmm, that doesnt make much sense. At the very least the different sin
size should be making it print an IPv4 address. Did you make both
sin6 - sin changes on that line ?
return 0;
Where .s6_addr32 is the appropriate member of sin6_addr on darwin,
for BSDs it should be:
sin6.sin6_addr.__u6_addr.__u6_addr32[3];
That will tell if the patch would fix thigns (which it does for my
friends).
which patch are we talking about?
The one below, it fixes things for at least 3 Darwin using friends
of mine.
Index: network_io/unix/sockaddr.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sockaddr.c,v
retrieving revision 1.41
diff -u -r1.41 sockaddr.c
--- network_io/unix/sockaddr.c 14 Aug 2003 17:36:17 - 1.41
+++ network_io/unix/sockaddr.c 14 Aug 2003 22:40:38 -
@@ -634,9 +634,29 @@
* a numeric address string if it fails to resolve the host name;
* that is *not* what we want here
*/
+#ifdef DARWIN APR_HAVE_IPV6
+/* Darwin's getnameinfo does not work for IPv4-mapped-IPv6 addresses,
+ * the workaround is to convert the last 32 bits of the IPv6 address
+ * to a valid sockaddr_in structure. This is extremely hacky, avoid
+ * re-use. */
+if (sockaddr-family == AF_INET6
+IN6_IS_ADDR_V4MAPPED(sockaddr-sa.sin6.sin6_addr)) {
+struct apr_sockaddr_t tmpsa;
+
+tmpsa.sa.sin.sin_family = AF_INET;
+tmpsa.sa.sin.sin_addr.s_addr = ((uint32_t *)sockaddr-ipaddr_ptr)[3];
+
+rc = getnameinfo((const struct sockaddr *)tmpsa.sa,
+ sizeof(struct sockaddr_in), tmphostname,
+ sizeof(tmphostname), NULL, 0,
+ flags != 0 ? flags : NI_NAMEREQD);
+}
+else
+#endif
rc = getnameinfo((const struct sockaddr *)sockaddr-sa, sockaddr-salen,
tmphostname, sizeof(tmphostname), NULL, 0,
flags != 0 ? flags : NI_NAMEREQD);
+
if (rc != 0) {
*hostname = NULL;
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/
Re: cvs commit: apr configure.in CHANGES
Colm MacCarthaigh wrote:
-rc = getnameinfo((struct sockaddr *)sin6, sizeof sin6, hostbuf,
sizeof hostbuf, NULL, 0, NI_NAMEREQD);
+rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof
hostbuf, NULL, 0, 0);
printf(look up via IPv6: %d/%s\n, rc, hostbuf);
Hmmm, that doesnt make much sense. At the very least the different sin
size should be making it print an IPv4 address. Did you make both
sin6 - sin changes on that line ?
urr, I didn't have the getnameinfo() call patched properly :( my
apologies :(
with the patch properly applied the second getnameinfo() call works,
which I suppose is intended to prove that when it didn't work we had the
right data in the right place and it failed due to system library fubar
The one below, it fixes things for at least 3 Darwin using friends
of mine.
Index: network_io/unix/sockaddr.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sockaddr.c,v
retrieving revision 1.41
diff -u -r1.41 sockaddr.c
--- network_io/unix/sockaddr.c 14 Aug 2003 17:36:17 - 1.41
+++ network_io/unix/sockaddr.c 14 Aug 2003 22:40:38 -
@@ -634,9 +634,29 @@
* a numeric address string if it fails to resolve the host name;
* that is *not* what we want here
*/
+#ifdef DARWIN APR_HAVE_IPV6
+/* Darwin's getnameinfo does not work for IPv4-mapped-IPv6 addresses,
+ * the workaround is to convert the last 32 bits of the IPv6 address
+ * to a valid sockaddr_in structure. This is extremely hacky, avoid
+ * re-use. */
+if (sockaddr-family == AF_INET6
+IN6_IS_ADDR_V4MAPPED(sockaddr-sa.sin6.sin6_addr)) {
+struct apr_sockaddr_t tmpsa;
+
+tmpsa.sa.sin.sin_family = AF_INET;
+tmpsa.sa.sin.sin_addr.s_addr = ((uint32_t *)sockaddr-ipaddr_ptr)[3];
+
+rc = getnameinfo((const struct sockaddr *)tmpsa.sa,
+ sizeof(struct sockaddr_in), tmphostname,
+ sizeof(tmphostname), NULL, 0,
+ flags != 0 ? flags : NI_NAMEREQD);
+}
+else
+#endif
rc = getnameinfo((const struct sockaddr *)sockaddr-sa, sockaddr-salen,
tmphostname, sizeof(tmphostname), NULL, 0,
flags != 0 ? flags : NI_NAMEREQD);
+
if (rc != 0) {
*hostname = NULL;
Yeah, that looks reasonable :) I'm still curious about what was
happening on Justin's system.
Re: cvs commit: apr configure.in CHANGES
[EMAIL PROTECTED] wrote: jerenkrantz2003/08/24 16:09:19 Modified:.configure.in CHANGES Log: Re-enable IPv6 on Darwin 6.6 and beyond as it looks like getaddrinfo() now works with IPv4-mapped addresses. IIRC getnameinfo() was the problem, not getaddrinfo(). With 6.6 kernel (and whatever else Jaguar+latest updates gets you), http://www.apache.org/~trawick/gni_mapped.c still fails for me. (This supposedly means that deny/allow from IP controls are broken.) Can you try gni_mapped on your system? Another issue is that switching IPv6 support on/off is a binary compatibility issue due to the layout of apr_sockaddr_info_t. apr 1.0 may not care so much about that but Apache 2.0.x does. We may need something in Apache 2.0.x configure.
Re: cvs commit: apr configure.in CHANGES
--On Monday, August 25, 2003 12:40:47 -0400 Jeff Trawick [EMAIL PROTECTED] wrote: IIRC getnameinfo() was the problem, not getaddrinfo(). With 6.6 kernel (and whatever else Jaguar+latest updates gets you), http://www.apache.org/~trawick/gni_mapped.c still fails for me. (This supposedly means that deny/allow from IP controls are broken.) Can you try gni_mapped on your system? I don't understand what gni_mapped is supposed to output. I get the same output on Darwin as I do on FreeBSD. IIRC, the root problem was that host-based authorization didn't work. When IPv6 was overriden to be enabled, host-based authorization works now on 6.6. AFAICT, IPv4-mapped addresses look correct. (The httpd-test framework passed the tests it wasn't passing a long time ago.) I did ask for others to confirm that it worked (as it does here), but no one responded, so I assumed people were happy. As for binary compatibility, I think it just means that we should probably stop upgrading APR in releases of httpd-2.0. -- justin
Re: cvs commit: apr configure.in CHANGES
Justin Erenkrantz wrote: --On Monday, August 25, 2003 12:40:47 -0400 Jeff Trawick [EMAIL PROTECTED] wrote: IIRC getnameinfo() was the problem, not getaddrinfo(). With 6.6 kernel (and whatever else Jaguar+latest updates gets you), http://www.apache.org/~trawick/gni_mapped.c still fails for me. (This supposedly means that deny/allow from IP controls are broken.) Can you try gni_mapped on your system? I don't understand what gni_mapped is supposed to output. I get the same output on Darwin as I do on FreeBSD. On a working system, it displays this: look up via IPv4: 0/www.ibm.com look up via IPv6: 0/www.ibm.com On my Jaguar system (and on other Mac OS X systems in the past), the first lookup finds the hostname and the second lookup fails to find the hostname. So what do you get on your system? I must be missing some OS X fix... (But this box is running straight Jaguar with all available updates from Software Update installed.)
Re: cvs commit: apr configure.in CHANGES
On Mon, Aug 25, 2003 at 12:59:42PM -0400, Jeff Trawick wrote: So what do you get on your system? I must be missing some OS X fix... (But this box is running straight Jaguar with all available updates from Software Update installed.) This is what my darwin-using friends have been telling me aswell. Can you try: --- gni_mapped.cSat Feb 15 00:18:30 2003 +++ gni_mapped2.c Mon Aug 25 17:40:15 2003 @@ -37,8 +37,10 @@ rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof hostbuf, NULL, 0, 0); printf(look up via IPv4: %d/%s\n, rc, hostbuf); +sin.sin_addr.s_addr = sin6.sin6_addr.s6_addr32[3]; + strcpy(hostbuf, not found); -rc = getnameinfo((struct sockaddr *)sin6, sizeof sin6, hostbuf, sizeof hostbuf, NULL, 0, NI_NAMEREQD); +rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof hostbuf, NULL, 0, 0); printf(look up via IPv6: %d/%s\n, rc, hostbuf); return 0; Where .s6_addr32 is the appropriate member of sin6_addr on darwin, for BSDs it should be: sin6.sin6_addr.__u6_addr.__u6_addr32[3]; That will tell if the patch would fix thigns (which it does for my friends). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.stdlib.net/
Re: cvs commit: apr configure.in CHANGES
So what do you get on your system? I must be missing some OS X fix... (But this box is running straight Jaguar with all available updates from Software Update installed.) My laptop, running straight Jaguar plus all available fixes: [EMAIL PROTECTED] gni $ ./gni_mapped look up via IPv4: 0/www.ibm.com look up via IPv6: 8/not found [EMAIL PROTECTED] gni $ uname -a Darwin MonaLisa 6.6 Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC Power Macintosh powerpc Doesn't look fixed to me... S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (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: cvs commit: apr configure.in CHANGES
At 05:13 PM 3/18/2003, Branko Čibej wrote: [EMAIL PROTECTED] wrote: brane 2003/03/18 15:10:15 Modified:include apr.hw apr.hnw apr.h.in .configure.in CHANGES Log: Define a printf format and format length for apr_uint64_t. Also define APR_INT64_T_FMT_LEN on Windows and Netware; Unix already defines that symbol. [snip] int64_t_fmt='#define APR_INT64_T_FMT Ld' int64_t_fmt_len='#define APR_INT64_T_FMT_LEN 2' +uint64_t_fmt='#define APR_UINT64_T_FMT Lu' +uint64_t_fmt_len='#define APR_UINT64_T_FMT_LEN 2' int64_value=long double long_value=long double Could someone please check if I'm doing the right thing here? Using long doubles for 64-bit ints seems totally weird to me... Agreed, long is a modifier. A long is really shorthand for long int. double is a floating point type, so long double implies large floating point values to me. longlong makes much more sense. Bill
Re: cvs commit: apr configure.in CHANGES
[EMAIL PROTECTED] wrote: brane 2003/03/18 15:10:15 Modified:include apr.hw apr.hnw apr.h.in .configure.in CHANGES Log: Define a printf format and format length for apr_uint64_t. Also define APR_INT64_T_FMT_LEN on Windows and Netware; Unix already defines that symbol. [snip] int64_t_fmt='#define APR_INT64_T_FMT Ld' int64_t_fmt_len='#define APR_INT64_T_FMT_LEN 2' +uint64_t_fmt='#define APR_UINT64_T_FMT Lu' +uint64_t_fmt_len='#define APR_UINT64_T_FMT_LEN 2' int64_value=long double long_value=long double Could someone please check if I'm doing the right thing here? Using long doubles for 64-bit ints seems totally weird to me... -- Brane ibej [EMAIL PROTECTED] http://www.xbc.nu/brane/
Re: cvs commit: apr configure.in CHANGES
On Fri, Jun 14, 2002 at 01:24:02AM -, [EMAIL PROTECTED] wrote: aaron 2002/06/13 18:24:02 Modified:.configure.in CHANGES Log: Removed --disable-atomics flag and added --enable-nonportable-atomics, thereby defaulting to portable binaries on those systems that could be optimized at the expense of portability. Just a note on this commit: The old behavior, the creation of architecture- optimized but non-portable binaries [on Solaris] can be achieved by specifying --enable-nonportable-atomics to configure. This seems to be a good compromise between all-out removal of the atomics code, and having to deal with binaries that are not forward compatible on certain operating systems based on simply OS revision number. -aaron
Re: cvs commit: apr configure.in
On Mon, Jun 10, 2002 at 06:51:13PM -, [EMAIL PROTECTED] wrote: rbb 2002/06/10 11:51:13 Modified:.configure.in Log: It helps to document the actual option. :-) Revision ChangesPath 1.452 +1 -1 apr/configure.in Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.451 retrieving revision 1.452 diff -u -r1.451 -r1.452 --- configure.in9 Jun 2002 18:50:47 - 1.451 +++ configure.in10 Jun 2002 18:51:13 - 1.452 @@ -310,7 +310,7 @@ user_disabled_optimized_atomics=0 AC_ARG_ENABLE(atomics, - [ --disable-optimized-atomics Turn off optimized atomic code], + [ --disable-atomics Turn off optimized atomic code], [ if test $enableval = no; then user_disabled_optimized_atomics=1 fi ] ) Hmm...this snafu would have been my fault, but you've reversed my name changes. The option doesn't actually disable atomics, it just doesn't let solaris support atomics in a way that would break binary compatibility across sparc architectures. Let's either provide an option that actually disables atomics, or rename this one (in a non-broken way). -aaron
RE: cvs commit: apr configure.in
From: Aaron Bannert [mailto:[EMAIL PROTECTED] On Mon, Jun 10, 2002 at 06:51:13PM -, [EMAIL PROTECTED] wrote: rbb 2002/06/10 11:51:13 Modified:.configure.in Log: It helps to document the actual option. :-) Revision ChangesPath 1.452 +1 -1 apr/configure.in Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.451 retrieving revision 1.452 diff -u -r1.451 -r1.452 --- configure.in 9 Jun 2002 18:50:47 - 1.451 +++ configure.in 10 Jun 2002 18:51:13 - 1.452 @@ -310,7 +310,7 @@ user_disabled_optimized_atomics=0 AC_ARG_ENABLE(atomics, - [ --disable-optimized-atomics Turn off optimized atomic code], + [ --disable-atomics Turn off optimized atomic code], [ if test $enableval = no; then user_disabled_optimized_atomics=1 fi ] ) Hmm...this snafu would have been my fault, but you've reversed my name changes. The option doesn't actually disable atomics, it just doesn't let solaris support atomics in a way that would break binary compatibility across sparc architectures. Let's either provide an option that actually disables atomics, or rename this one (in a non-broken way). I don't really care what we do, or what the option is. I spent a half-day trying to disable the optimized atomic code, and it wasn't until I started really digging into it that I realized that it was just a question of documentation. Ryan
Re: cvs commit: apr configure.in
On Tue, Apr 30, 2002 at 11:49:41PM -, Justin Erenkrantz wrote: jerenkrantz02/04/30 16:49:41 Modified:.configure.in Log: Add --disable-atomics flag which will prevent APR from using its *own* optimized code. On those OSes that properly support atomics from userspace, we will use those no matter what the user specifies. Therefore, this change only affects Solaris/Sparc - if --disable-atomics is passed, we will use APR's generic code. Since this doesn't really disable the atomics, please rename it. Something like --disable-optimized-atomics, or how about --enable-nonportable-atomics. I'd like to continue the discussion about non-portable binaries. Although I think it would be great if APR could handle atomics, I don't see that happening. Here are a couple problems that I see: 1) non-portable binaries: By default any binaries built on solaris 5.6/sparc will not run on older architectures, even when Sun supports newer operating systems on those architectures. (eg. 5.6 binaries don't work on some 5.7/5.8 machines.) 2) inefficient portable binaries: The whole point of the atomics code isn't just to do atomic operations, but to do them efficiently. Mutexes already give us atomic operations. If you specify the above flag, any part of your application that depends on efficient atomic operations will be making a false assumption. Since APR is not satisfying a requirement of the application, APR is not supporting atomics on that platform. I don't think it is APRs job to choose efficiency over portability, even at the binary executable level. -aaron
Re: cvs commit: apr configure.in CHANGES
On Sun, Apr 28, 2002 at 07:49:34AM -, Justin Erenkrantz wrote: jerenkrantz02/04/28 00:49:34 Modified:.configure.in CHANGES Log: Not all platforms can mmap /dev/zero, so we need to do an explicit check for that. If that were to fail, then make it appear as /dev/zero never existed in the first place. PR: 8537 Sorry for the late reply. Do we have a HAVE_DEV_ZERO-like define somewhere, and if so would this mean that an OS that had /dev/zero but didn't support mmap(/dev/zero) would not have that defined anymore? Other than that I think this is a good way to test for mmap(/dev/zero). -aaron
Re: cvs commit: apr configure.in
On Wed, May 01, 2002 at 10:56:10AM -0700, Aaron Bannert wrote: Since this doesn't really disable the atomics, please rename it. Something like --disable-optimized-atomics, or how about --enable-nonportable-atomics. No one came up with a patch to do it after lots of discussion about it. If you want to rename it, please feel free to do so. (FWIW, I'd prefer the first choice.) As we all know, my naming capabilities are awful. Whatever floats your boat. 1) non-portable binaries: By default any binaries built on solaris 5.6/sparc will not run on older architectures, even when Sun supports newer operating systems on those architectures. (eg. 5.6 binaries don't work on some 5.7/5.8 machines.) Hopefully, we can come up with some solution that allows us to address this. My first guess would be some type of run-time morphing of the atomic ops on platforms where we can efficiently degrade our performance if we're not running on a CPU that supports our optimizations. I'm not exactly clear how to do it, but I think we *might* be able to do this efficiently. (Perusing the NSPR sources, it seems that they hinted at doing this, but never did it.) 2) inefficient portable binaries: The whole point of the atomics code isn't just to do atomic operations, but to do them efficiently. Mutexes already give us atomic operations. If you specify the above flag, any part of your application that depends on efficient atomic operations will be making a false assumption. Since APR is not satisfying a requirement of the application, APR is not supporting atomics on that platform. Nope, you are just running on a platform that may not be as efficient. That's always an assumption that you have to consider. In fact, I think we must be optimisitic - what is the *best* conditions that this code could operate under - rather than the worst condition. In that case, I think atomics is a good thing to have because on lots of platforms, this code can be done efficiently without the overhead of a mutex. Remember that we're only doing this on platforms that don't expose a userspace atomic interface. A bunch of other OSes do this - we've just run into two OSes that don't. Shame on them. But, there is a way to address this - handcoded assembly. However, this isn't something that we're particularly good at. So, we need to take time to consider what direction we should take. Ideally, we should have had this discussion before the atomics landed, but oh well. To me, I guess the more important questions are: 1) Who wants to *use* atomics? 2) Who wants to *support* atomics? Maybe that's a question we should start out with. If the answer is no one to either one, it isn't worth our hassle to continue this conversation and we should remove them. -- justin
Re: cvs commit: apr configure.in CHANGES
On Wed, May 01, 2002 at 11:01:47AM -0700, Aaron Bannert wrote: Sorry for the late reply. Do we have a HAVE_DEV_ZERO-like define somewhere, and if so would this mean that an OS that had /dev/zero but didn't support mmap(/dev/zero) would not have that defined anymore? Other than that I think this is a good way to test for mmap(/dev/zero). We don't have a HAVE_DEV_ZERO macro. We only seem to use knowledge of /dev/zero in configure to determine if we can do pthread mutexes. Then, in the pthread code we assume that we have /dev/zero. I think shm also uses /dev/zero in a similar fashion. -- justin
Re: cvs commit: apr configure.in CHANGES
On Sun, Apr 28, 2002 at 07:49:34AM -, [EMAIL PROTECTED] wrote: jerenkrantz02/04/28 00:49:34 Modified:.configure.in CHANGES Log: Not all platforms can mmap /dev/zero, so we need to do an explicit check for that. If that were to fail, then make it appear as /dev/zero never existed in the first place. PR: 8537 Can we make sure this change does NOT get into 2.0.36? (Don't think it should, but if Sander retags .36 from HEAD...) I'm worried that this may return a false negative in some circumstances on platforms I don't have access to (it correctly passes on Linux), so I'd like this to get the benefit of a complete development cycle. I've pointed the person who filed the PR to CVS. -- justin
Re: cvs commit: apr configure.in
On Fri, Mar 22, 2002 at 05:21:22PM -0500, Jeff Trawick wrote: If backtraces posted by users to our mailing lists and our bug databases will be even a little easier to look at, then I am strongly in favor of keeping the -g as a default. If somebody is worried about that amount of space then let them strip the executable files. +1. FWIW, I believe autoconf places the -g in there by default via AC_PROG_CC. -- justin
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] wrote: gregames02/03/22 13:41:47 Modified:.configure.in Log: get rid of the -g compiler flag on OS/390, unless this is a debug or maintainer mode build. Does anyone have a problem with doing the same on all platforms? I will commit such a fix soon if I don't hear any objections. On Linux, with -g, httpd is 1062084 bytes. Without -g, it's 430464 bytes. I remember Rasmus commenting on the size of the 2.0 executable a while back. Greg
Re: cvs commit: apr configure.in
On Fri, Mar 22, 2002 at 05:05:46PM -0500, Greg Ames wrote: [EMAIL PROTECTED] wrote: gregames02/03/22 13:41:47 Modified:.configure.in Log: get rid of the -g compiler flag on OS/390, unless this is a debug or maintainer mode build. Does anyone have a problem with doing the same on all platforms? I will commit such a fix soon if I don't hear any objections. On Linux, with -g, httpd is 1062084 bytes. Without -g, it's 430464 bytes. I remember Rasmus commenting on the size of the 2.0 executable a while back. Why is AC_PROG_CC unconditionally setting -g? I'm only fine with this as long as it doesn't prevent me from doing: CFLAGS=-Wall -g ./configure -aaron
Re: cvs commit: apr configure.in
Greg Ames [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: gregames02/03/22 13:41:47 Modified:.configure.in Log: get rid of the -g compiler flag on OS/390, unless this is a debug or maintainer mode build. Does anyone have a problem with doing the same on all platforms? I will commit such a fix soon if I don't hear any objections. On Linux, with -g, httpd is 1062084 bytes. Without -g, it's 430464 bytes. I remember Rasmus commenting on the size of the 2.0 executable a while back. If backtraces posted by users to our mailing lists and our bug databases will be even a little easier to look at, then I am strongly in favor of keeping the -g as a default. If somebody is worried about that amount of space then let them strip the executable files. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
Jeff Trawick wrote: If backtraces posted by users to our mailing lists and our bug databases will be even a little easier to look at, then I am strongly in favor of keeping the -g as a default. If somebody is worried about that amount of space then let them strip the executable files. ++1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: cvs commit: apr configure.in
Jeff Trawick wrote: [EMAIL PROTECTED] writes: gregames02/02/15 14:36:40 Modified:buildapr_hints.m4 .configure.in Log: provide APR_CC_HINTS. This allows us to specify a default compiler which the user can override externally (i.e., the compiler choice isn't forced). Then AC_PROG_CC can verify that the compiler works, and logic in APR_PRELOAD can make decisions based on the compiler choice. Shouldn't all the old logic in hints.m4 to set CC be moved to the APR_CC_HINTS macro? I'm wondering why you moved the CC settings just for OS/390 and OS/400... OS/390 and OS/400 used SETIFNULL, the others forced CC. The forcing of CC might have been for historical reasons (i.e. no nicer way to do it at the time), but I don't know for sure. I'll go ahead and change the others to use the new approach - it ought to just work. If for some reason it causes a problem on some platform, we can deal with it. Greg
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] writes: gregames02/02/15 14:36:40 Modified:buildapr_hints.m4 .configure.in Log: provide APR_CC_HINTS. This allows us to specify a default compiler which the user can override externally (i.e., the compiler choice isn't forced). Then AC_PROG_CC can verify that the compiler works, and logic in APR_PRELOAD can make decisions based on the compiler choice. Shouldn't all the old logic in hints.m4 to set CC be moved to the APR_CC_HINTS macro? I'm wondering why you moved the CC settings just for OS/390 and OS/400... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
On Mon, Jul 30, 2001 at 05:31:54PM -, [EMAIL PROTECTED] wrote: trawick 01/07/30 10:31:54 Modified:.configure.in Log: if your system has pthread_mutexattr_setrobust_np()* we'll use it, but we shouldn't require it in order to support cross process pthread mutexes (i.e., Solaris) The issue is that if you don't have robust cross process mutex, you may get into a condition where you have a bad mutex sticking around (say after a child that holds the mutex SEGVs). Bad things start to happen then. If we have robust, we definitely want to use it. I'm not sure whether we want to use pthread_mutex_t for cross process if we don't have some form of robust locking. (Solaris's setrobust_np is non-portable - as the name implies - does AIX have something similar? Is it the default behavior?) -- justin
Re: cvs commit: apr configure.in Makefile.in
On 27 Jul 2001 10:22:04 -, [EMAIL PROTECTED] wrote: dreid 01/07/27 03:22:04 Modified:.configure.in Makefile.in Log: Neither beos or OS/2 has any subdirs that need installing, so the commit that added INSTALL_SUBDIRS broke the build. I couldn't find a way of getting it to work with an empty INSTALL_SUBDIRS (others may be able to) so I opted for setting it initially to 'none' and then testing for that when come to make install. This gets make install working again but was only tested on beos. Other platforms shouldn't be affected, but please test. Brian, does this work for OS/2? I had no problem the way it was. I guess my sh has no problems with an empty list. This doesn't break anything though. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: cvs commit: apr configure.in
On Mon, Jul 02, 2001 at 04:23:49PM -, [EMAIL PROTECTED] wrote: jerenkrantz01/07/02 09:23:49 Modified:.configure.in Log: fcntl() should be our preference for the short-term. Our support of pthread_mutex_t needs more work before we can make it the default (if that's what we want anyway). Ack. This did the wrong thing. Correct commit coming up. -- justin
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] writes: jerenkrantz01/05/31 19:58:32 Modified:.configure.in Log: Detect the wacky Linux-specific condition where pthread_rwlock_init is defined, but the declaration of pthread_rwlock_t requires extra #defines. this is glibc-specific, not Linux-specific, right? Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.310 retrieving revision 1.311 diff -u -r1.310 -r1.311 --- configure.in2001/05/31 03:29:51 1.310 +++ configure.in2001/06/01 02:58:31 1.311 @@ -281,6 +281,31 @@ APR_CHECK_PTHREAD_GETSPECIFIC_TWO_ARGS APR_CHECK_PTHREAD_ATTR_GETDETACHSTATE_ONE_ARG AC_CHECK_FUNCS(pthread_key_delete pthread_rwlock_init) + +if test $ac_cv_func_pthread_rwlock_init = yes; then +dnl #- Checking for pthread_rwlock_t +dnl # Linux is silly as it has pthread_rwlock_init defined +dnl # but keeps the pthread_rwlock_t structure hidden unless +dnl # special things are defined. +AC_CACHE_CHECK([for pthread_rwlock_t], ac_cv_struct_pthread_rw, +[AC_TRY_COMPILE([#include sys/types.h +#include pthread.h], +[pthread_rwlock_t rwlock=PTHREAD_RWLOCK_INITIALIZER;], +ac_cv_struct_pthread_rw=yes, ac_cv_struct_pthread_rw=no)]) +if test $ac_cv_struct_pthread_rw = no; then +AC_TRY_COMPILE([#define _XOPEN_SOURCE 500 +#define _BSD_SOURCE +#define _SVID_SOURCE +#include sys/types.h +#include pthread.h], +[pthread_rwlock_t rwlock=PTHREAD_RWLOCK_INITIALIZER;], +ac_cv_struct_pthread_rw=yes, ac_cv_struct_pthread_rw=no) +if test $ac_cv_struct_pthread_rw = yes; then +APR_ADDTO(CPPFLAGS, [-D_XOPEN_SOURCE=500 -D_BSD_SOURCE]) +APR_ADDTO(CPPFLAGS, [-D_SVID_SOURCE]) Why are we turning on _BSD_SOURCE and _SVID_SOURCE here? What do they have to do with pthread_rwlock_t? Only _XOPEN_SOURCE=500 is needed for pthread_rwlock_t IIRC. _BSD_SOURCE is related to the combination of _XOPEN_SOURCE=500 and either S_ISLINK or S_ISSOCK. I forget what _SVID_SOURCE is for. It seems to me that we have very specific information about a certain libc's requirements but we're ashamed to admit it and so we're dressing it up in autoconf for political correctness. Unfortunately, the resulting code risks turning on unnecessary or undesirable flags on platforms we don't know about. (I'll shut up now on this issue. I promise :) ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
On Saturday, April 7, 2001, at 07:31 AM, Jeff Trawick wrote: But APR_FLAG_HEADERS() can't handle that header file because the variable name it generates is invalid. We're getting this on stderr from configure: /home/trawick/apache/httpd-2.0/srclib/apr/configure: mach-o_dyldh=0: command not found Surely you're getting this error too on Darwin and APR still doesn't realize that you have this header file. Nope, I didn't get that error; my build went just fine. This sounds like an autoconf bug... It's certainly a legal header name. Mine generated HAVE_MACH_O_DYLD_H (replaced the - with _). I didn't notice this lowercase variable. What verion of autoconf are you using? I have 2.13. -Fred
Re: cvs commit: apr configure.in
Wilfredo Sanchez [EMAIL PROTECTED] writes: But APR_FLAG_HEADERS() can't handle that header file because the variable name it generates is invalid. We're getting this on stderr from configure: /home/trawick/apache/httpd-2.0/srclib/apr/configure: mach-o_dyldh=0: command not found Actually, the difference is probably my shell being wonky and not autoconf. Does this patch fix your problem? What you committed is great. Thanks! -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
On 29 Mar 2001 11:17:32 -0500, Jeff Trawick wrote: Brian Havard [EMAIL PROTECTED] writes: On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote: The way I do this in my libtool emulator is to provide an AC_PROG_LIBTOOL macro in my libtool.m4 to set up the LIBTOOL variable. (I compile my .c at make install time for libtool). Couldn't/shouldn't hide this in an AC_PROG_LIBTOOL macro? Sounds good, my autoconf knowledge isn't very advanced though. I'll give it a try on the next round. Look in www.apache.org/~trawick/libtool.tgz... The included libtool.m4 has *extremely* simple versions of these macros. Ok, do you mean something like this? Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.263 diff -u -r1.263 configure.in --- configure.in2001/03/29 15:50:29 1.263 +++ configure.in2001/03/30 01:23:04 @@ -79,18 +79,7 @@ dnl prep libtool dnl echo performing libtool configuration... - -case $host_alias in -*os2*) -# Use a custom made libtool replacement -echo using aplibtool -LIBTOOL=$srcdir/build/aplibtool -gcc -o $LIBTOOL.exe $LIBTOOL.c -;; -*) -AC_PROG_LIBTOOL -;; -esac +APR_PROG_LIBTOOL dnl #- Checks for compiler flags nl=' Index: build/apr_common.m4 === RCS file: /home/cvs/apr/build/apr_common.m4,v retrieving revision 1.12 diff -u -r1.12 apr_common.m4 --- build/apr_common.m4 2001/03/21 15:01:53 1.12 +++ build/apr_common.m4 2001/03/30 01:23:06 @@ -401,3 +401,19 @@ ]) +dnl APR_PROG_LIBTOOL +dnl Sets up to use aplibtool on the platforms it supports (just OS/2 for now) +dnl otherwise calls AC_PROC_LIBTOOL to set up the real libtool +AC_DEFUN(APR_PROG_LIBTOOL,[ +case $host_alias in +*os2*) +# Use a custom made libtool replacement +echo using aplibtool +LIBTOOL=$srcdir/build/aplibtool +gcc -o $LIBTOOL.exe $LIBTOOL.c +;; +*) +AC_PROG_LIBTOOL +;; +esac +]) -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: cvs commit: apr configure.in
On 29 Mar 2001 20:45:28 -0500, Jeff Trawick wrote: Brian Havard [EMAIL PROTECTED] writes: On 29 Mar 2001 11:17:32 -0500, Jeff Trawick wrote: Brian Havard [EMAIL PROTECTED] writes: On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote: The way I do this in my libtool emulator is to provide an AC_PROG_LIBTOOL macro in my libtool.m4 to set up the LIBTOOL variable. (I compile my .c at make install time for libtool). Couldn't/shouldn't hide this in an AC_PROG_LIBTOOL macro? Sounds good, my autoconf knowledge isn't very advanced though. I'll give it a try on the next round. Look in www.apache.org/~trawick/libtool.tgz... The included libtool.m4 has *extremely* simple versions of these macros. Ok, do you mean something like this? No... I mean provide your own libtool.m4 which defines your own AC_PROG_LIBTOOL. Then APR doesn't care which libtool is used. I want APR to care, I want this built into APR. It's APR's job to maximize portability. I don't want to have to provide an extra package that has to be installed just to build Apache. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: cvs commit: apr configure.in
Brian Havard [EMAIL PROTECTED] writes: On 29 Mar 2001 20:45:28 -0500, Jeff Trawick wrote: No... I mean provide your own libtool.m4 which defines your own AC_PROG_LIBTOOL. Then APR doesn't care which libtool is used. I want APR to care, I want this built into APR. It's APR's job to maximize portability. I don't want to have to provide an extra package that has to be installed just to build Apache. But everywhere else you have to install an extra package (libtool) just to build Apache + APR... what's the difference? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] writes: Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.262 retrieving revision 1.263 diff -u -r1.262 -r1.263 --- configure.in2001/03/27 10:48:02 1.262 +++ configure.in2001/03/29 15:50:29 1.263 @@ -79,7 +79,18 @@ dnl prep libtool dnl echo performing libtool configuration... -AC_PROG_LIBTOOL + +case $host_alias in +*os2*) +# Use a custom made libtool replacement +echo using aplibtool +LIBTOOL=$srcdir/build/aplibtool +gcc -o $LIBTOOL.exe $LIBTOOL.c +;; +*) +AC_PROG_LIBTOOL +;; +esac The way I do this in my libtool emulator is to provide an AC_PROG_LIBTOOL macro in my libtool.m4 to set up the LIBTOOL variable. (I compile my .c at make install time for libtool). Couldn't/shouldn't hide this in an AC_PROG_LIBTOOL macro? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote: [EMAIL PROTECTED] writes: Index: configure.in === RCS file: /home/cvs/apr/configure.in,v retrieving revision 1.262 retrieving revision 1.263 diff -u -r1.262 -r1.263 --- configure.in 2001/03/27 10:48:02 1.262 +++ configure.in 2001/03/29 15:50:29 1.263 @@ -79,7 +79,18 @@ dnl prep libtool dnl echo performing libtool configuration... -AC_PROG_LIBTOOL + +case $host_alias in +*os2*) +# Use a custom made libtool replacement +echo using aplibtool +LIBTOOL=$srcdir/build/aplibtool +gcc -o $LIBTOOL.exe $LIBTOOL.c +;; +*) +AC_PROG_LIBTOOL +;; +esac The way I do this in my libtool emulator is to provide an AC_PROG_LIBTOOL macro in my libtool.m4 to set up the LIBTOOL variable. (I compile my .c at make install time for libtool). Couldn't/shouldn't hide this in an AC_PROG_LIBTOOL macro? Sounds good, my autoconf knowledge isn't very advanced though. I'll give it a try on the next round. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: cvs commit: apr configure.in
Brian Havard [EMAIL PROTECTED] writes: On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote: The way I do this in my libtool emulator is to provide an AC_PROG_LIBTOOL macro in my libtool.m4 to set up the LIBTOOL variable. (I compile my .c at make install time for libtool). Couldn't/shouldn't hide this in an AC_PROG_LIBTOOL macro? Sounds good, my autoconf knowledge isn't very advanced though. I'll give it a try on the next round. Look in www.apache.org/~trawick/libtool.tgz... The included libtool.m4 has *extremely* simple versions of these macros. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] writes: jim 01/02/26 11:56:14 Modified:.configure.in Log: Use APR_CHECK_HEADERS instead One of these commits seems to have broken every case where we previously checked for the header but didn't set a flag. In those cases, we had symbols defined in include/arch/unix/apr_private.h. One example: sys/stat.h old code: AC_CHECK_HEADERS(sys/stat.h) in apr_private.h: #define HAVE_SYS_STAT_H or /* #undef HAVE_SYS_STAT_H */ --- new code: APR_FLAG_HEADERS(sys/stat.h) there is nothing in apr_private.h for HAVE_SYS_STAT_H -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
Jeff Trawick wrote: [EMAIL PROTECTED] writes: jim 01/02/26 11:56:14 Modified:.configure.in Log: Use APR_CHECK_HEADERS instead One of these commits seems to have broken every case where we previously checked for the header but didn't set a flag. Sorry for the delay... teaches me to commit a patch and go offline for awhile :) I'm not seeing that, since we're reducing down to AC_CHECK_HEADERS. Let me double check... I'm seeing correct stuff under FreeBSD and A/UX. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Re: cvs commit: apr configure.in
Greg Stein wrote: I'm not seeing that, since we're reducing down to AC_CHECK_HEADERS. Let me double check... I'm seeing correct stuff under FreeBSD and A/UX. Well, yah. I fixed it :-) I meant before :) Basically we were just doing: for i in $stuff do AC_CHECK_HEADERS($i...) done instead of: AC_CHECK_HEADERS($stuff) But it was a lng day ;) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Re: cvs commit: apr configure.in
On Tue, Feb 27, 2001 at 03:24:29PM -, [EMAIL PROTECTED] wrote: jim 01/02/27 07:24:28 Modified:.configure.in Log: revert back to old way until we figure out an autoheader work-around. Allow building again What the hell?!!! I spent something like six hours to get that stuff working. My apr_private.h.in is generating just fine. What are you seeing? Per my previous message, we *ARE* using AC_CHECK_HEADERS inside of the APR_FLAG_HEADERS. Damn it. -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr configure.in
Greg Stein wrote: On Tue, Feb 27, 2001 at 03:24:29PM -, [EMAIL PROTECTED] wrote: jim 01/02/27 07:24:28 Modified:.configure.in Log: revert back to old way until we figure out an autoheader work-around. Allow building again What the hell?!!! I spent something like six hours to get that stuff working. My apr_private.h.in is generating just fine. What are you seeing? Per my previous message, we *ARE* using AC_CHECK_HEADERS inside of the APR_FLAG_HEADERS. Yes, but we are doing: AC_CHECK_HEADERS($1) where $1 is what's passed to APR_FLAG_HEADERS, which autoheader isn't parsing correctly... What I've been seeing on all my test machines is that the HAVE_CTYPES_H, for example, stuff in apr_private.h.in isn't in there. autoheader likes: AC_CHECK_HEADERS(sys/types.h) but not: $i=sys/types.h AC_CHECK_HEADERS($i) from what I can see. Note I've just reset configure.in. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] writes: jim 01/02/27 08:58:33 Modified:.configure.in Log: Back to using APR_FLAG_HEADERS... note that this may require GNUm4 on FreeBSD systems +dnl work around unexplained problem on Tru64 where +dnl the above invocation says it finds the header but +dnl APR_HAVE_foo_H is 0 +APR_FLAG_HEADERS(stdio.h) +APR_FLAG_HEADERS(errno.h) +APR_FLAG_HEADERS(crypt.h) +APR_FLAG_HEADERS(ctype.h) +APR_FLAG_HEADERS(fcntl.h) +APR_FLAG_HEADERS(netdb.h) Unfortunately, with this my Linux box won't build but without it my Tru64 box won't build :( I have no interest in playing with this until it works. What we had up until yesterday worked everywhere and when we forgot to do something it was easy to fix. Who has time for this shit? There are real problems to fix out there. This isn't one of them. Whoever wants this please consider dropping this in the crapper so that those of us who want to work on something useful can do so. Or at least yank it out until you can get it working on FreeBSD, Linux, AIX, Tru64, Solaris, and wherever else, using the standard system m4 of course. Otherwise, it is worse than what we started with. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
Any interest in my adding something like AC_CHECK_HEADERS_FLAG which implements the below: AC_CHECK_HEADERS(sys/signal.h, sys_signalh=1, sys_signalh=0) AC_CHECK_HEADERS_FLAG(sys/signal.h, sys_signalh) we seem to use this construct enough... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Re: cvs commit: apr configure.in
On Mon, 26 Feb 2001, Jim Jagielski wrote: Any interest in my adding something like AC_CHECK_HEADERS_FLAG which implements the below: AC_CHECK_HEADERS(sys/signal.h, sys_signalh=1, sys_signalh=0) AC_CHECK_HEADERS_FLAG(sys/signal.h, sys_signalh) we seem to use this construct enough... ++1 Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] wrote: jim 01/02/26 11:56:14 Modified:.configure.in Log: Use APR_CHECK_HEADERS instead Before I go any further, I want to rethink the name. Maybe APR_FLAG_HEADERS (want to avoid confusion here) or APR_HEADERS_SET. Suggestions welcome. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Re: cvs commit: apr configure.in
On Mon, 26 Feb 2001, Jim Jagielski wrote: Use APR_CHECK_HEADERS instead Before I go any further, I want to rethink the name. Maybe APR_FLAG_HEADERS (want to avoid confusion here) or APR_HEADERS_SET. Suggestions welcome. APR_CHECK_HEADERS doesn't bother me... it makes it clear that it serves basically the same purpose as AC_CHECK_HEADERS, but has added functionality for APR. It also wouldn't hurt my feelings any if APR_CHECK_HEADERS automagically determined the variable name to flag with a 1 or a 0 by doing basically this s/\//_/g; s/\.//g; on the header name. Hence sys/sendfile.h becomes the flag variable sys_sendfileh automatically. That would avoid typo problems like the one this morning, and it would be just one less step that's necessary. The downside is that it implies a little bit of extra work in configure... shrug --Cliff
Re: cvs commit: apr configure.in
Cliff Woolley wrote: It also wouldn't hurt my feelings any if APR_CHECK_HEADERS automagically determined the variable name to flag with a 1 or a 0 by doing basically this s/\//_/g; s/\.//g; on the header name. Hence sys/sendfile.h becomes the flag variable sys_sendfileh automatically. That would avoid typo problems like the one this morning, and it would be just one less step that's necessary. The downside is that it implies a little bit of extra work in configure... shrug I like! Could be a pain with things like APR_CHECK_HEADERS(sys/types.h sys/signal.h) but I like this :) PS: I see some weird things where we set things to 'yes' or 'no' which we may be able to standardize -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Hell is hot, that's never been disputed by anybody.
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] writes: martin 01/02/21 07:51:43 Modified:include apr_general.h file_io/unix Makefile.in .configure.in Added: file_io/unix mktemp.c Log: Add mktemp() and mkstemp() emulation for systems which don't have it. Jean-Frederic writes: I have tested Apache2.0 with a ReliantUNIX machine. This machine has a SVR4 Unix implementation. To compile correctly the -DXTI_SUPPORT should be added to CFLAGS (I have done it when calling configure), and I have added a mkstemp() because it is not in the default runtime library. I have reused and enhanced an mkstemp() routine from FreeBSD. Find enclosed the needed patch to test for mkstemp() and to use ap_mkstemp() when needed. Submitted by: Jean-Frederic Clere [EMAIL PROTECTED] Revision ChangesPath 1.53 +6 -0 apr/include/apr_general.h Index: apr_general.h === RCS file: /home/cvs/apr/include/apr_general.h,v retrieving revision 1.52 retrieving revision 1.53 diff -u -u -r1.52 -r1.53 --- apr_general.h 2001/02/16 04:15:44 1.52 +++ apr_general.h 2001/02/21 15:51:42 1.53 @@ -143,6 +143,12 @@ #define memmove(a,b,c) bcopy(b,a,c) #endif +#if (!HAVE_MKSTEMP) +#define mkstemp(a) ap_mkstemp(a) +#define mkstemps(a,b) ap_mkstemp(a,b) +#define mkdtemp(a) ap_mkdtemp(a) +#endif I guess I missed my chance to comment before :) I'll take this opportunity to raise a few issues, particularly since this breaks the Tru64 (and probably other platforms) build. If APR wants to provide a wrapper for mkstemp() which works everywhere, that is cool, but the interface has to be namespace protected. I don't think this stuff goes in apr_general.h. Unless somebody disagrees, I'm going to trim down the usage a bit for now. I'll get the stuff out of apr_general.h. We detect whether or not there is mkstemp(). If not then the code in mktemp.c will be exposed. If the system already has mkstemp(), then the code in mktemp.c will be hidden and we don't risk compile breakage (it looks pretty fragile to me). To expose it properly as an APR API, we'd need a little doc in apr_file_io.h (I guess). Also, we'd need to decide whether apr_mkstemp() is always a function or is a macro on systems which provide mkstemp(). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
On 21 Feb 2001, Jeff Trawick wrote: [EMAIL PROTECTED] writes: martin 01/02/21 07:51:43 Modified:include apr_general.h file_io/unix Makefile.in .configure.in Added: file_io/unix mktemp.c Log: Add mktemp() and mkstemp() emulation for systems which don't have it. Jean-Frederic writes: I have tested Apache2.0 with a ReliantUNIX machine. This machine has a SVR4 Unix implementation. To compile correctly the -DXTI_SUPPORT should be added to CFLAGS (I have done it when calling configure), and I have added a mkstemp() because it is not in the default runtime library. I have reused and enhanced an mkstemp() routine from FreeBSD. Find enclosed the needed patch to test for mkstemp() and to use ap_mkstemp() when needed. Submitted by: Jean-Frederic Clere [EMAIL PROTECTED] Revision ChangesPath 1.53 +6 -0 apr/include/apr_general.h Index: apr_general.h === RCS file: /home/cvs/apr/include/apr_general.h,v retrieving revision 1.52 retrieving revision 1.53 diff -u -u -r1.52 -r1.53 --- apr_general.h 2001/02/16 04:15:44 1.52 +++ apr_general.h 2001/02/21 15:51:42 1.53 @@ -143,6 +143,12 @@ #define memmove(a,b,c) bcopy(b,a,c) #endif +#if (!HAVE_MKSTEMP) +#define mkstemp(a) ap_mkstemp(a) +#define mkstemps(a,b) ap_mkstemp(a,b) +#define mkdtemp(a) ap_mkdtemp(a) +#endif I guess I missed my chance to comment before :) I'll take this opportunity to raise a few issues, particularly since this breaks the Tru64 (and probably other platforms) build. If APR wants to provide a wrapper for mkstemp() which works everywhere, that is cool, but the interface has to be namespace protected. I don't think this stuff goes in apr_general.h. +1. Unless somebody disagrees, I'm going to trim down the usage a bit for now. I'll get the stuff out of apr_general.h. We detect whether or not there is mkstemp(). If not then the code in mktemp.c will be exposed. If the system already has mkstemp(), then the code in mktemp.c will be hidden and we don't risk compile breakage (it looks pretty fragile to me). To expose it properly as an APR API, we'd need a little doc in apr_file_io.h (I guess). Also, we'd need to decide whether apr_mkstemp() is always a function or is a macro on systems which provide mkstemp(). Personally, I would just always make it a function. That allows us to control how it works, and ignore any small platform differences. Just an opinion though. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr configure.in
On Thu, Feb 08, 2001 at 10:12:28PM -, [EMAIL PROTECTED] wrote: trawick 01/02/08 14:12:28 Modified:.configure.in Log: look in -lm for modf() This gets APR test programs linking on Tru64. It may result in a double -lm on some platforms, as we autodetect the need for -lm but also hard-code the need for it in hints.m4. Wouldn't that imply that -lm should be removed from hints.m4? Recall: hints.m4 was a bridge between the old Apache 1.3 knowledge of systems, and our *detection* based system (embodied in autoconf). Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr configure.in
Greg Stein [EMAIL PROTECTED] writes: On Thu, Feb 08, 2001 at 10:12:28PM -, [EMAIL PROTECTED] wrote: trawick 01/02/08 14:12:28 Modified:.configure.in Log: look in -lm for modf() This gets APR test programs linking on Tru64. It may result in a double -lm on some platforms, as we autodetect the need for -lm but also hard-code the need for it in hints.m4. Wouldn't that imply that -lm should be removed from hints.m4? I expect that over the next few days I'll remove it for the relatively few platforms I have access to as I get a chance to verify. Alternatively, we can just remove it across the board and pick up the pieces when somebody with one of the obscure systems gets an unresolved reference and we realize that we need to look for a different function in -lm. Are you in favor of the latter approach? Thanks, -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr configure.in
On Thu, Feb 08, 2001 at 07:56:14PM -0500, Jeff Trawick wrote: Greg Stein [EMAIL PROTECTED] writes: On Thu, Feb 08, 2001 at 10:12:28PM -, [EMAIL PROTECTED] wrote: trawick 01/02/08 14:12:28 Modified:.configure.in Log: look in -lm for modf() This gets APR test programs linking on Tru64. It may result in a double -lm on some platforms, as we autodetect the need for -lm but also hard-code the need for it in hints.m4. Wouldn't that imply that -lm should be removed from hints.m4? I expect that over the next few days I'll remove it for the relatively few platforms I have access to as I get a chance to verify. Alternatively, we can just remove it across the board and pick up the pieces when somebody with one of the obscure systems gets an unresolved reference and we realize that we need to look for a different function in -lm. Are you in favor of the latter approach? The latter... definitely :-) It is a bit nicer to believe we have the right solution and then apply known fixes, then to continue to carry around baggage which we never know is still needed or not. In this particular case, the failure mode is an easy diagnosis and fix. Ideally, hints could go away, but realistically I doubt that :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr configure.in
Unless GCC defines __GLIBC__ (which it should not do), I don't see any way how this expression can evaluate to false. GCC doesn't define __GLIBC__, glibc header files do Don't worry, that was a sort-of rhetorical statement. =) I expected the AC_EGREP_HEADER macro to do something different. So, confusion was the source of error here. I've fixed it in CVS already. - Sascha
Re: cvs commit: apr configure.in
On 5 Jan 2001 [EMAIL PROTECTED] wrote: rbb 01/01/05 09:19:57 Modified:.configure.in Log: Some Linux's do not define TCP_CORK. I guess you are referring to libc 5.x.x systems? There are still kernels around (2.0.x, early 2.2.x possibly) which don't support TCP_CORK, so I think we should not simply presume that TCP_CORK works. Would anyone mind, if the *linux* portion of the case statement would egrep linux/socket.h for TCP_CORK? - Sascha
Re: cvs commit: apr configure.in
Some Linux's do not define TCP_CORK. I guess you are referring to libc 5.x.x systems? There are still kernels around (2.0.x, early 2.2.x possibly) which don't support TCP_CORK, so I think we should not simply presume that TCP_CORK works. Would anyone mind, if the *linux* portion of the case statement would egrep linux/socket.h for TCP_CORK? Sounds good. Or, we could just check to see if we are on linux and sendfile is defined. Is that a good enough check? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr configure.in
On Fri, 5 Jan 2001 [EMAIL PROTECTED] wrote: Some Linux's do not define TCP_CORK. I guess you are referring to libc 5.x.x systems? There are still kernels around (2.0.x, early 2.2.x possibly) which don't support TCP_CORK, so I think we should not simply presume that TCP_CORK works. Would anyone mind, if the *linux* portion of the case statement would egrep linux/socket.h for TCP_CORK? Sounds good. Or, we could just check to see if we are on linux and sendfile is defined. Is that a good enough check? Was TCP_CORK and sendfile introduced at the same time? I don't know.. anyway, I've committed the small egrep addition which should properly exclude older kernels (tested on a 2.0 system). - Sascha
Re: cvs commit: apr configure.in
It's false on Mandrake 7.1 too. I am in the middle of testing a patch that just looks for sendfile. I think that is the safest way to code this. Yeah, instead of curing the problem the Right Way, we just work around it by relying on well-established assumptions. Great solution. - Sascha
Re: cvs commit: apr configure.in
It's false on Mandrake 7.1 too. I am in the middle of testing a patch that just looks for sendfile. I think that is the safest way to code this. Yeah, instead of curing the problem the Right Way, we just work around it by relying on well-established assumptions. Great solution. So find the real solution, but in the meantime, let's do what works right now. Nobody is stoping you from figuring out why the EGREP doesn't work, but I am trying to test the server right now, and I can't compile easily, because we don't have the autoconf stuff working. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
