Re: OK...
David Reid [EMAIL PROTECTED] writes: [OK, I'm getting better at this Reply To All stuff...] I still haven't gotten the hang of it :( Maybe I need to study the GNUS manual to figure out how to avoid editing the cc line to keep me out of it. 1. Modify connect to take an apr_sockaddr_t instead of a hostname... This is a simple change so I'll make it sooner rather than later. yes... OK, I've done some work on this but am getting an error now Could not connect: Can't assign requested address (49) I've got to drive to Suffolk in a short while so I'll post the patch at the end of this message and let someone else figure out where I've screwed up! :) I'll start working on that. 2. Are we agreed on Jeff's suggestions of Add apr_pool_t * to apr_sockaddr_t. apr_status_t apr_get_address(char **hostname, apr_interface_e which, apr_socket_t *sock); apr_status_t apr_get_nas(char **addr, apr_sockaddr_t *sa); These are new additions sos houldn't interfere with any existing code. I am. Good. There was an implied :) after I am. more comments on the rest later... for now I'll look at apr_connect() and make an attempt at fixing the Win32 and OS/2 builds to include apr_inet_ntop() and apr_inet_pton(). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
I need help getting Win32 to build again...
(I sent this to [EMAIL PROTECTED] the first time... not helpful...) I just committed some changes to win32's networkio.h and sockets.c and unix's inet_ntop.c to get Win32 up to speed with some Unix changes I committed this morning. However, there are at least two steps which I am punting on: 1) update aprlib.def and whatever else to note that there is a new APR function: apr_create_socket() 2) update project files for APR to build in unix's inet_ntop.c I attempted to do these steps on my VC++ 5.0 setup but I was unable to get lib/apr/test/server to link. It always failed with an unresolved reference for apr_create_socket(). Thanks for your assistance! (I care a lot that APR builds on Win32, really :) ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: OK...
David Reid [EMAIL PROTECTED] writes: Just a thought, should we define the socket families as APR values? This would mean that on a non-v6 platform we could still call create socket with APR_V6 as a family and we'd just return an error. Don't know if it makes sense or not... sure... at config time we can figure out the right values and stick them in apr.h I think; on a system with no AF_INET6 we wouldn't want to accidently set APR_V6 to the value for an address family it actually has :) I'm punting on this for now Also, do we want to be able to pass in a servicename for the port? Otherwise I think we should add a function to get the numeric port for a service name... On the one hand, it would be nice to pass it in to apr_getaddrinfo() since on platforms with the real getaddrinfo() we can pass it on through and magic happens. Unfortunately, I think apr_getaddrinfo() is going to get darn ugly what with the series of functions we try at config time and to a lesser extent at run-time (for !GETHOSTBYNAME_HANDLES_NAS) just to resolve the hostname/numeric address string. A separate function is probably simplifying overall. There is no flags parameter for now, but we may need to allow that eventually. If we think we'll need it should we add it now so we don't break the API when we do? will-do (but Greg S. doesn't like that style so if he reads this then watch out :) ) In addition to the changes you mentioned, I see apr_create_socket() as extremely important in the short run and I think we should think about apr_bind() working like apr_connect() (in other words, taking an apr_sockaddr_t). That makes sense when the user has told us the local interface address and we have to resolve it anyway. We have to keep it from being painful when we just have the port number. OK, so again care to suggest the API definitions? I think apr_connect() is good the way it is. For apr_bind(), I see it looking like apr_connect(): apr_status_t apr_bind(apr_socket_t *, apr_sockaddr_t *); Why? This makes sense. +1 I'll hold off on that one for now (until after the alpha maybe?). I need to spend some time making an honest attempt at not breaking Win32 and OS/2 when I ship this patch. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
[PATCH] change apr_bind() API, add apr_get_sockaddr()
() failed,
+ ipaddr, port);
+apr_close_socket(s);
+return stat;
+}
+
stat = apr_setsocketopt(s, APR_SO_REUSEADDR, one);
if (stat != APR_SUCCESS stat != APR_ENOTIMPL) {
ap_log_error(APLOG_MARK, APLOG_CRIT, stat, NULL,
@@ -140,7 +150,7 @@
ap_sock_disable_nagle(s);
#endif
-if ((stat = apr_bind(s)) != APR_SUCCESS) {
+if ((stat = apr_bind(s, localsa)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, stat, NULL,
make_sock: could not bind to %s, addr);
apr_close_socket(s);
Index: main/rfc1413.c
===
RCS file: /home/cvspublic/apache-2.0/src/main/rfc1413.c,v
retrieving revision 1.29
diff -u -r1.29 rfc1413.c
--- main/rfc1413.c 2000/11/17 03:45:02 1.29
+++ main/rfc1413.c 2000/11/17 18:59:30
@@ -119,7 +119,7 @@
char *cp;
char buffer[RFC1413_MAXDATA + 1];
int buflen;
-apr_sockaddr_t *destsa;
+apr_sockaddr_t *localsa, *destsa;
/*
* Bind the local and remote ends of the query socket to the same
@@ -130,10 +130,16 @@
* addresses from the query socket.
*/
-apr_set_port(sock, APR_LOCAL, ANY_PORT);
-apr_set_ipaddr(sock, APR_LOCAL, local_ip);
+if ((status = apr_getaddrinfo(localsa, local_ip, AF_INET, 0, 0, p))
+!= APR_SUCCESS) {
+/* This should not fail since we have a numeric address string
+ * as the host. */
+ap_log_error(APLOG_MARK, APLOG_CRIT, status, srv,
+ rfc1413: apr_getaddrinfo() failed);
+return -1;
+}
-if ((status = apr_bind(sock)) != APR_SUCCESS) {
+if ((status = apr_bind(sock, localsa)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, status, srv,
bind: rfc1413: Error binding to local port);
return -1;
Index: modules/proxy/proxy_ftp.c
===
RCS file: /home/cvspublic/apache-2.0/src/modules/proxy/proxy_ftp.c,v
retrieving revision 1.23
diff -u -r1.23 proxy_ftp.c
--- modules/proxy/proxy_ftp.c 2000/11/16 01:57:46 1.23
+++ modules/proxy/proxy_ftp.c 2000/11/17 18:59:31
@@ -873,8 +873,6 @@
}
apr_get_port(npport, APR_LOCAL, sock);
apr_get_ipaddr(npaddr, APR_LOCAL, sock);
-apr_set_port(dsock, APR_LOCAL, npport);
-apr_set_ipaddr(dsock, APR_LOCAL, npaddr);
if (apr_setsocketopt(dsock, APR_SO_REUSEADDR, one) != APR_SUCCESS) {
#ifndef _OSD_POSIX /* BS2000 has this option always on */
@@ -886,7 +884,15 @@
#endif /*_OSD_POSIX*/
}
- if (apr_bind(dsock) != APR_SUCCESS) {
+if (apr_getaddrinfo(localsa, npaddr, AF_INET, npport, 0, r-pool)
+!= APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ proxy: error creating local socket address);
+ap_bclose(f);
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+
+ if (apr_bind(dsock, localsa) != APR_SUCCESS) {
char buff[22];
apr_snprintf(buff, sizeof(buff), %s:%d, npaddr, npport);
Index: support/httpd.exp
===
RCS file: /home/cvspublic/apache-2.0/src/support/httpd.exp,v
retrieving revision 1.12
diff -u -r1.12 httpd.exp
--- support/httpd.exp 2000/11/17 03:45:02 1.12
+++ support/httpd.exp 2000/11/17 18:59:33
@@ -425,6 +425,7 @@
apr_get_port
apr_get_remote_name
apr_get_revents
+apr_get_sockaddr
apr_get_socket_inaddr
apr_get_socketdata
apr_get_thread_private
--
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/test testargs.c
[EMAIL PROTECTED] writes: gstein 00/11/28 23:41:27 Modified:include apr_getopt.h misc/unix getopt.c test testargs.c Log: Add an extra const into the getopt functions. We never attempt to modify any of the data, so the const is proper. This also allows clients to pass const data in. Please get http_main.c to compile without warnings again. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: controlling the flavor of lock used by APR
[EMAIL PROTECTED] writes: On Thu, 30 Nov 2000, Jeff Trawick wrote: Does anyone have thoughts on what should be done in hints.m4 to set the flavor of lock for a certain platform? Why do you want to do this? For the same reason we had USE_xyz_SERIALIZED_ACCEPT in 1.3: because certain locking mechanisms have better performance characteristics on certain platforms and we can't autodetect that. We can autodetect what is available, but not what is most appropriate. Sometimes it is not just a performance issue: we have heard tales of certain locking mechanisms being flaky on certain platforms under certain conditions. I don't yet completely understand the current logic for deciding, but part of it doesn't look right: AC_IFALLYES(custom:union_semun, AC_DECIDE(USE_SYSVSEM_SERIALIZE, [SysV IPC semget()])) AFAIK, this says that if have_union_semun is set, we'll use SysV semaphores. But have_union_semun is rarely set since it is up to the program to define union semun. Look ab out 20 lines above the AC_IFALLYES. Some platforms do actually define union semun, but not all do. We just find the platforms that advertise a semun, because we can't do much more than that. My point is that the presence of union semun is not a valid indicator of whether or not there are SysV sems. We could check for semop() or semctl() if this becomes important. Thanks, -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
[PATCH] controlling the flavor of lock used by APR
Important note: the hints.m4 change is just an example... I won't commit a change for Linux, but will do so for OS/390 before I commit... To tailor the lock method, in hints.m4 set the apr_lock_method variable to one of the USE_xxx_SERIALIZE symbols and magic will happen. Any remaining concerns before I commit? Index: hints.m4 - JUST AN EXAMPLE === RCS file: /home/cvspublic/apr/hints.m4,v retrieving revision 1.25 diff -u -r1.25 hints.m4 --- hints.m42000/11/28 22:43:00 1.25 +++ hints.m42000/11/30 18:00:53 @@ -100,6 +100,7 @@ APR_SETIFNULL(LIBS, [-lm]) ;; *-linux-*) +apr_lock_method=USE_SYSVSEM_SERIALIZE case `uname -r` in 2.2* ) APR_SETIFNULL(CFLAGS, [-DLINUX=2]) APR_SETIFNULL(LIBS, [-lm]) Index: configure.in === RCS file: /home/cvspublic/apr/configure.in,v retrieving revision 1.175 diff -u -r1.175 configure.in --- configure.in2000/11/29 19:35:52 1.175 +++ configure.in2000/11/30 18:00:54 @@ -617,7 +617,7 @@ AC_CHECK_DEFINE(PTHREAD_PROCESS_SHARED, pthread.h) fi -AC_BEGIN_DECISION([ap_lock implementation method]) +AC_BEGIN_DECISION([apr_lock implementation method]) AC_IFALLYES(custom:union_semun, AC_DECIDE(USE_SYSVSEM_SERIALIZE, [SysV IPC semget()])) AC_IFALLYES(header:sys/file.h define:LOCK_EX, @@ -627,7 +627,9 @@ AC_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl custom:with_pthread_cross, AC_DECIDE(USE_PROC_PTHREAD_SERIALIZE, [pthread mutex])) -dnl AC_DECISION_FORCE(USE_FCNTL_SERIALIZE) +if test x$apr_lock_method != x; then +AC_DECISION_FORCE($apr_lock_method) +fi AC_END_DECISION AC_DEFINE_UNQUOTED($ac_decision) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: controlling the flavor of lock used by APR
[EMAIL PROTECTED] writes: This would be moving backwards. This test was originally after the FCNTL test, but we moved it, I can't remember why. Please look this up before making this change. of course you're right about the order! Would you mind clueing me in as to why I was right? Why you were right about leaving the location of the AC_DECIDE(USE_SYSVSEM_SERIALIZE...) alone? I had misunderstood the generated shell script and thought that as soon as one of the AC_IFALLYES() matched we'd stop executing subsequent tests. Thus, I thought that fcntl should be checked for first and SysV sem last in order to prefer fcntl. However, the preferred methods have to be checked for last, so the order has been right all along (well, since March when you changed it). -- 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/locks/unix locks.c
[EMAIL PROTECTED] writes: Modified:.configure.in hints.m4 CHANGES include apr.h.in apr.hw locks/unix locks.c Log: New config variable apr_process_lock_is_global specifies that the selected inter-process lock method is sufficient for APR_LOCKALL (i.e., it blocks all threads and processes). For now, hints.m4 turns on this flag for OS/390. MHO this was put in the wrong place. This is an internal APR flag, and should not be in apr.h at all. Really what this is, is an optimization, so that we don't create an intraprocess lock if the cross-process lock will lock the threads. Locks and how they are setup was an area of great contention between Manoj and myself when I was designing them, because of lockall and cross-process locks. I agree 99%. App code shouldn't give a [EMAIL PROTECTED] The remaining 1% is that it can be extremely useful for apps to tell their users how they were built. Forget APR_PROCESS_LOCK_IS_GLOBAL for a sec and consider APR_USE_xyz_SERIALIZE. Apache code doesn't give a rip about it except for generating the htpd -V output. That has been quite useful because of the large number of times the lock mechanism in use comes up in discussions of performance and to a lesser extent brokenness. I consider APR_PROCESS_LOCK_IS_GLOBAL to be important too. Back to reality though: Why don't we add something like apr_get_config_string() which returns a string like the httpd -V output (but of course only builds the APR part)? include/apr_general.h: apr_status_t apr_get_config_string(char **cfg, apr_pool_t *cont); misc/unix/cfg.c: put the function here; any other functions dealing with config tests could go here too With this in hand, we can decide that certain feature tests macros aren't needed by apps and move them out of apr.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/locks/unix locks.c
Greg Stein [EMAIL PROTECTED] writes: On Fri, Dec 01, 2000 at 08:44:14AM -0800, [EMAIL PROTECTED] wrote: This should work the same way apr_initialize works, so that it calls into the APR sub-libraries with a function like apr_report_lock or apr_report_threads. This would make it very extensible, and as we build APR with or without different components, we would just pick up the right information. I think that is overkill for now. All of these flags are available in apr_private.h. If it starts to get unwieldy or something, then we can split. But let's start simple, make it harder when that is needed. That is for damn sure :)^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H I'll start out with all the logic right in cfg.c and as other folks have time/inclination they can consider other implementations. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: compilation difficulties on BeOS
Sam TH [EMAIL PROTECTED] writes: Then I encounter this error: cc -DBEOS -DBEOS -c -I../../include -Imm shmem.c ### mwcc Compiler Error: # MM *newmm = mm_create(reqsize + sizeof(*newmm), file, MM_ALLOCATE_ENOUGH); # ^ # illegal type Yep... this bug crept in last night; it showed up in a gcc warning on FreeBSD in the wee hours... sizeof(* void *) is undefined. You can't do void *x; sizeof(*x) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
[PATCH] apr_make_os_sock()
Hopefully I didn't miss any comments on the mailing list last night
(where is that archive again?).
Here is enough to look at to make sure I didn't screw anything up. I
added family and type parameters too so that APR doesn't have to bend
over backwards (i.e., use syscalls) to find that out. We don't keep
the type anywhere yet but it is likely to become useful in the future.
Index: include/apr_portable.h
===
RCS file: /home/cvspublic/apr/include/apr_portable.h,v
retrieving revision 1.40
diff -u -r1.40 apr_portable.h
--- include/apr_portable.h 2000/11/26 03:00:03 1.40
+++ include/apr_portable.h 2000/12/03 14:28:26
@@ -275,6 +275,23 @@
apr_pool_t *cont);
/**
+ * Create a socket from an existing descriptor and local and remote
+ * socket addresses.
+ * @param apr_sock The new socket that has been set up
+ * @param os_sock The os representation of a socket
+ * @param local The local socket address (or NULL if unknown)
+ * @param remote The remote socket address (or NULL if unknown)
+ * @param family The address family of the socket (e.g., APR_INET)
+ * @param type The type of the socket (e.g., SOCK_STREAM)
+ * @param cont The pool to use
+ * @tip If you only know the descriptor/handle or if it isn't really
+ * a true socket, use apr_put_os_sock() instead.
+ */
+apr_status_t apr_make_os_sock(apr_socket_t **apr_sock, apr_os_sock_t *os_sock,
+ struct sockaddr *local, struct sockaddr *remote,
+ int family, int type, apr_pool_t *cont);
+
+/**
* Convert the lock from os specific type to apr type
* @param lock The apr lock we are converting to.
* @param thelock The os specific lock to convert.
Index: network_io/unix/sockets.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sockets.c,v
retrieving revision 1.65
diff -u -r1.65 sockets.c
--- network_io/unix/sockets.c 2000/11/21 21:33:07 1.65
+++ network_io/unix/sockets.c 2000/12/03 14:28:28
@@ -282,6 +282,32 @@
return APR_SUCCESS;
}
+apr_status_t apr_make_os_sock(apr_socket_t **apr_sock, apr_os_sock_t *os_sock,
+ struct sockaddr *local, struct sockaddr *remote,
+ int family, int type, apr_pool_t *cont)
+{
+alloc_socket(apr_sock, cont);
+set_socket_vars(*apr_sock, family);
+(*apr_sock)-timeout = -1;
+(*apr_sock)-socketdes = *os_sock;
+if (local) {
+memcpy((*apr_sock)-local_addr-sa.sin, local,
+ (*apr_sock)-local_addr-salen);
+}
+else {
+(*apr_sock)-local_port_unknown = (*apr_sock)-local_interface_unknown
= 1;
+}
+if (remote) {
+#ifndef HAVE_POLL
+(*apr_sock)-connected = 1;
+#endif
+memcpy((*apr_sock)-remote_addr-sa.sin, local,
+ (*apr_sock)-remote_addr-salen);
+}
+
+return APR_SUCCESS;
+}
+
apr_status_t apr_put_os_sock(apr_socket_t **sock, apr_os_sock_t *thesock,
apr_pool_t *cont)
{
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] apr_make_os_sock()
Jeff Trawick [EMAIL PROTECTED] writes:
+apr_status_t apr_make_os_sock(apr_socket_t **apr_sock, apr_os_sock_t
*os_sock,
+ struct sockaddr *local, struct sockaddr
*remote,
+ int family, int type, apr_pool_t *cont)
+{
...
+memcpy((*apr_sock)-remote_addr-sa.sin, local,
+ (*apr_sock)-remote_addr-salen);
+}
add code for pool cleanup here :)
+
+return APR_SUCCESS;
+}
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] apr_make_os_sock()
[EMAIL PROTECTED] writes: On Sun, 3 Dec 2000, Jeff Trawick wrote: Hopefully I didn't miss any comments on the mailing list last night (where is that archive again?). Here is enough to look at to make sure I didn't screw anything up. I added family and type parameters too so that APR doesn't have to bend over backwards (i.e., use syscalls) to find that out. We don't keep the type anywhere yet but it is likely to become useful in the future. I would really prefer that this function at least look like the current apr_put_os_* functions. That would mean just wrapping all of this information up into a single structure that is just passed to APR's create function. What is the purpose of putting the parameters into a structure? Do we expect that we'll want to tailor the information provided to apr_make_os_socket() on certain platforms? I guess I'm not sure what you mean by APR's create function... Do you want to change apr_create_socket() to take parameters in a structure, and have the structure indicate whether or not we already have the OS socket (I don't think this is what you mean). Should it be apr_make_socket() instead of apr_make_os_socket()? -- 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-util/src/dbm Makefile.in apr_dbm.c
[EMAIL PROTECTED] writes: *) move building of aprutil.exports into the top-level Makefile so that we can use APR's directory (rather than needing to pass it to buildconf.sh) You can't do this. We need this file when running buildconf in Apache, and it doesn't make any sense to do this each time we build apr-utils, because this is not a very fast operation, especially once we add more header files. I guess this is what keeps aprutil.exports from being available at the right time (build/buildexports.sh: srclib/apr-util/aprutil.exports: No such file or directory) which leads in some sick way to the APR exports list being expanded twice in exports.c which keeps exports.c from compiling properly? Cool... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Win32 ordinal binding concerns
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Bill and others interested, Please look at the current 2.0 library and executable binaries in the depends.exe utility. You will observe only one module is bound by ordinal, and that is ws2_32.dll (which is a MS problem.) Is this to say that the linker binds on the symbol name instead of the ordinal number? -- 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-util Makefile.in
[EMAIL PROTECTED] writes: gstein 00/12/12 03:05:33 Modified:.Makefile.in Log: auto-rebuild the exports file when a header changes Revision ChangesPath 1.6 +14 -3 apr-util/Makefile.in Index: Makefile.in === RCS file: /home/cvs/apr-util/Makefile.in,v retrieving revision 1.5 retrieving revision 1.6 diff -u -u -r1.5 -r1.6 --- Makefile.in 2000/12/06 05:02:13 1.5 +++ Makefile.in 2000/12/12 11:05:32 1.6 ... @@ -33,7 +34,17 @@ echo $(LINK) $$objects ; \ $(LINK) -rpath $(libdir) $$objects -aprutil.exports: +delete-exports: + @if test -f $(TARGET_EXPORTS); then \ + headers=`find include/*.h -maxdepth 0 -newer $(TARGET_EXPORTS)` ; \ + if test -n $$headers; then \ + echo Found newer headers. Will rebuild $(TARGET_EXPORTS). ; \ + echo $(RM) -f $(TARGET_EXPORTS) ; \ + $(RM) -f $(TARGET_EXPORTS) ; \ + fi \ + fi This breaks FreeBSD (3.4, at least), which doesn't support find -maxdepth. If I understand correctly, -maxdepth 0 isn't really necessary here because there will be no directories fed to find so there can't be any traversal (no chance to test at the moment though; maybe in an hour when I get back from an errand). -- 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/shmem/unix/mm aclocal.m4
[EMAIL PROTECTED] writes: dreid 00/12/13 03:09:49 Modified:shmem/unix/mm aclocal.m4 Log: We need to define this correctly or it's never set and we don't set the correct values. This caused the tests to fail on BeOS and maybe other systems as well. Sent to rse, right? -- 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/shmem/unix/mm aclocal.m4
David Reid [EMAIL PROTECTED] writes: Yeah, and he denied all knowledge of the piece of code affected :) Hence I submitted the fix! c00l... I guess that was in the temporary patch from Ryan... -- 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/network_io/unix sa_common.c
Brian Havard [EMAIL PROTECTED] writes:
On 13 Dec 2000 22:30:22 -, [EMAIL PROTECTED] wrote:
OS/2 and Win32 logic for reporting getaddrinfo() failures is from existing
should have been gethostbyaddr() instead of getaddrinfo()
code. The OS/2 code doesn't look right to me (need to add
APR_OS_START_xyz?)
I'm not sure what is needed for pre-BONE BeOS.
Actually, h_error on OS/2 needs to be sorted out somehow as there's
currently no place for it in apr_error_t space, the only existing use of it
on OS/2 is wrong. I think we need a standard place for it so OS/2 Unix
code can share code without these #ifdefs, maybe somewhere in the
APR_OS_START_ERROR-APR_OS_START_STATUS range. There's space for 500 codes
there of which 20 are used.
Another horror to deal with is the set of errors from getaddrinfo().
Not only do they need to be distinguished between errno and h_errno
and APR-specific values, but with glibc the values are negative
(but positive on the other systems I have access to):
/* Error values for `getaddrinfo' function. */
# define EAI_BADFLAGS -1 /* Invalid value for `ai_flags' field. */
# define EAI_NONAME -2 /* NAME or SERVICE is unknown. */
# define EAI_AGAIN -3 /* Temporary failure in name resolution. */
# define EAI_FAIL -4 /* Non-recoverable failure in name res. */
# define EAI_NODATA -5 /* No address associated with NAME. */
# define EAI_FAMILY -6 /* `ai_family' not supported. */
# define EAI_SOCKTYPE -7 /* `ai_socktype' not supported. */
# define EAI_SERVICE-8 /* SERVICE not supported for `ai_socktype'. */
# define EAI_ADDRFAMILY -9 /* Address family for NAME not supported. */
# define EAI_MEMORY -10 /* Memory allocation failure. */
# define EAI_SYSTEM -11 /* System error returned in `errno'. */
-cut to the chase-
I think we should just explicitly define a bunch of APR resolver error
codes and map from h_errno and from getaddrinfo() return codes to
those APR codes directly. Other ways to handle it use less explicit
games which muddy the error code space for all platforms.
We would need four new APR error codes: APR_ENONAME, APR_ENORECOVERY,
APR_ENODATA, APR_EAFNOSUPPORT.
h_errno
HOST_NOT_FOUND - APR_ENONAME
TRY_AGAIN - APR_EAGAIN?
NO_RECOVERY - APR_ENORECOVERY
NO_DATA, NO_ADDRESS - APR_ENODATA
getaddrinfo()
EAI_BADFLAGS- APR_EINVAL?
EAI_NONAME - APR_ENORESNAME
EAI_AGAIN - APR_EAGAIN?
EAI_FAIL- APR_ENORECOVERY
EAI_NODATA - APR_ENODATA
EAI_FAMILY - APR_EAFNOSUPPORT
EAI_SOCKTYPE- APR_EINVAL(shouldn't be possible for us)
EAI_ADDRFAMILY - APR_EAFNOSUPPORT
EAI_MEMORY - APR_ENOMEM
EAI_SYSTEM - use errno
The Win32 support, which doesn't use h_errno, can continue to use its
current code.
Any thoughts? I'd like to wrap up the gaping getaddrinfo() hole
before too long.
--my original thoughts...-
Back to your problem...
As I think you suggest:
#define APR_OS_START_RES_ERROR APR_OS_START_ERROR + 200
Any system where h_errno is used will return (h_errno +
APR_OS_START_RES_ERROR) and magic will happen.
Back to my problem with this second set of res errors on Unix...
#define APR_OS_START_RES_ERROR_MAX APR_OS_START_RES_ERROR + 50
#define APR_OS_START_RES_ERROR_2 APR_OS_START_RES_ERROR + 100
The ugly APR_OS_START_RES_ERROR_MAX is because of the ugly glibc use
of negative values for the EAI_ codes. Something higher than
APR_OS_START_RES_ERROR_MAX but less than the next range after
APR_OS_START_RES_ERROR_2 is presumed to be one of these second set of
resolver error codes.
Returning an EAI_ code in sa_common.c:
if ((error = getaddrinfo()) != 0) {
return APR_OS_START_RES_ERROR_2 + error;
}
Finding the string for an EAI_ code in errorcodes.c:
if (statcode APR_OS_START_ERROR) {
return stuffbuffer(buf, bufsize, strerror(statcode));
}
else if (statcode APR_OS_START_RES_ERROR) {
return stuffbuffer(buf, bufsize, apr_error_string(statcode));
}
else if (statcode APR_OS_START_RES_ERROR_MAX) {
#ifdef HAVE_H_ERRNO
/* it is an h_errno value */
#else
APR does not understand this error code
#endif
}
else if (statcode APR_OS_START_STATUS) {
#ifdef HAVE_GAI_STRERROR
/* it is a getaddrinfo() error */
#else
APR does not understand this error code
#endif
}
else if (statcode APR_OS_START_USEERR) {
return stuffbuffer(buf, bufsize, apr_error_string(statcode));
}
else if (statcode APR_OS_START_SYSERR) {
return stuffbuffer(buf, bufsize, APR does not understand this error
code);
}
else {
return apr_os_strerror(buf, bufsize, statcode - APR_OS_START_SYSERR);
}
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com
Re: cvs commit: apr CHANGES aclocal.m4
[EMAIL PROTECTED] writes: trawick 00/12/17 05:12:12 Modified:.CHANGES aclocal.m4 Log: Tighten up the check for getaddrinfo(). If it can't figure out the appropriate address family for 127.0.0.1, it fails. Unfortunately, Tru64 fails this test so we won't do IPv6 on Tru64. Note that it is easy enough to handle numeric address strings properly and portably in apr_getaddrinfo() by writing the code ourselves. Unfortunately, the Tru64 getaddrinfo() won't handle AF_UNSPEC with hosts either, so writing explicit code to handle numeric address strings is a false solution. Yuck! -- 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/lib apr_pools.c
[EMAIL PROTECTED] writes:
rbb 01/01/02 16:53:07
Modified:lib apr_pools.c
Index: apr_pools.c
===
RCS file: /home/cvs/apr/lib/apr_pools.c,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- apr_pools.c 2001/01/02 01:33:05 1.76
+++ apr_pools.c 2001/01/03 00:53:05 1.77
@@ -493,9 +493,6 @@
}
p-sub_pools = new_pool;
}
-else {
-permanent_pool = new_pool;
-}
#if APR_HAS_THREADS
if (alloc_mutex) {
@@ -691,6 +688,7 @@
return status;
}
#endif
+permanent_pool = apr_make_sub_pool(pglobal);
How the [EMAIL PROTECTED] does this compile for you? Surely it does (yeah,
right)
as you had another commit to apr_pools.c after this one.
apr_pools.c: In function `apr_init_alloc':
apr_pools.c:691: `pglobal' undeclared (first use in this function)
apr_pools.c:691: (Each undeclared identifier is reported only once
apr_pools.c:691: for each function it appears in.)
apr_pools.c:691: too few arguments to function `apr_make_sub_pool'
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: hints.m4
Jim Jagielski [EMAIL PROTECTED] writes: Hmmm... right now, if CFLAGS (et.al.) set, the hints.m4 stuff is *not* used (they are only set if these env vars are null)... I'm thinking now that that's not the right thing. These should be set (added) no matter what. very minor point: there is a mixture of APR_ADDTO and APR_SETIFNULL, hopefully (for some platforms at least) for good reason The reason for the current behavior is so that people can overrule the settings in hints by forcing CFLAGS, LIBS, etc... on the command line. I still think we need that somehow. edit hints.m4 perhaps? edit config_vars.mk after configure*? *not so simple as there are more places to edit -- 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 APRVARS.in configure.in
[EMAIL PROTECTED] writes: rbb 01/01/09 11:28:38 Modified:.configure.in .APRVARS.in configure.in Log: Fix a compile break with the new APR libtool setup. Basically, we are using a libtool library from MM, but it isn't getting linked into the Apache executable, so we fail the link stage. This makes APR publicize the libtool libraries that it uses, so that Apache can link them in. This doesn't get it building for me :( Before this commit, the patch at the bottom from Victor got us going. Index: Makefile.in === RCS file: /home/cvspublic/apr/Makefile.in,v retrieving revision 1.37 diff -u -d -r1.37 Makefile.in --- Makefile.in 2001/01/09 11:05:33 1.37 +++ Makefile.in 2001/01/09 19:38:53 @@ -42,7 +42,8 @@ $(LIBAPR): $(MODULES) @for i in $(SUBDIRS); do objects=$$objects $$i/*.lo; done ; \ echo $(LINK) -rpath $(libdir) $$objects ; \ - $(LINK) -rpath $(libdir) $$objects + $(LINK) -rpath $(libdir) $$objects ; \ +ln -s .libs/libapr.a delete-exports: @if test -f $(TARGET_EXPORTS); then \ Index: shmem/unix/Makefile.in === RCS file: /home/cvspublic/apr/shmem/unix/Makefile.in,v retrieving revision 1.15 diff -u -d -r1.15 Makefile.in --- shmem/unix/Makefile.in 2001/01/09 11:06:15 1.15 +++ shmem/unix/Makefile.in 2001/01/09 19:39:59 @@ -17,11 +17,12 @@ # build the MM library, then copy the objects to this dir so our top-level # will find them and copy them to the (top)/objs directory MM_OBJS = \ - mm/mm_global.lo mm/mm_alloc.lo mm/mm_core.lo mm/mm_lib.lo \ - mm/mm_vers.lo + mm/mm_global.o mm/mm_alloc.o mm/mm_core.o mm/mm_lib.o \ + mm/mm_vers.o build-mm: (cd mm $(MAKE) libmm.la) - cp $(MM_OBJS) . + @rm -f mm*.o mm*.lo + @for i in $(MM_OBJS); do ln $$i `echo $$i | sed -e 's/.*\/\(.*\)\.o/\1\.lo/'`; done # DO NOT REMOVE -- 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 APRVARS.in configure.in
network_io/unix/sockaddr.lo network_io/unix/sockets.lo network_io/unix/sockopt.lo threadproc/unix/proc.lo threadproc/unix/procsup.lo threadproc/unix/signals.lo threadproc/unix/thread.lo threadproc/unix/threadpriv.lo misc/unix/errorcodes.lo misc/unix/getopt.lo misc/unix/getuuid.lo misc/unix/otherchild.lo misc/unix/rand.lo misc/unix/start.lo misc/unix/uuid.lo locks/unix/crossproc.lo locks/unix/intraproc.lo locks/unix/locks.lo time/unix/time.lo time/unix/timestr.lo mmap/unix/common.lo mmap/unix/mmap.lo shmem/unix/mm_alloc.lo shmem/unix/mm_core.lo shmem/unix/mm_global.lo shmem/unix/mm_lib.lo shmem/unix/mm_vers.lo shmem/unix/shmem.lo i18n/unix/xlate.lo user/unix/homedir.lo dso/unix/dso.lo mkdir .libs ln -s shmem/unix/mm_alloc.lo shmem/unix/mm_alloc.o ln -s shmem/unix/mm_core.lo shmem/unix/mm_core.o ln -s shmem/unix/mm_global.lo shmem/unix/mm_global.o ln -s shmem/unix/mm_lib.lo shmem/unix/mm_lib.o ln -s shmem/unix/mm_vers.lo shmem/unix/mm_vers.o ar cru .libs/libapr.a lib/apr_pools.o strings/apr_cpystrn.o strings/apr_fnmatch.o strings/apr_snprintf.o strings/apr_strings.o strings/apr_strnatcmp.o passwd/apr_getpass.o passwd/apr_md5.o tables/apr_hash.o tables/apr_tables.o file_io/unix/dir.o file_io/unix/fileacc.o file_io/unix/filedup.o file_io/unix/filestat.o file_io/unix/flock.o file_io/unix/fullrw.o file_io/unix/open.o file_io/unix/pipe.o file_io/unix/readwrite.o file_io/unix/seek.o network_io/unix/inet_ntop.o network_io/unix/inet_pton.o network_io/unix/poll.o network_io/unix/sendrecv.o network_io/unix/sockaddr.o network_io/unix/sockets.o network_io/unix/sockopt.o threadproc/unix/proc.o threadproc/unix/procsup.o threadproc/unix/signals.o threadproc/unix/thread.o threadproc/unix/threadpriv.o misc/unix/errorcodes.o misc/unix/getopt.o misc/unix/getuuid.o misc/unix/otherchild.o misc/unix/rand.o misc/unix/start.o misc/unix/uuid.o locks/unix/crossproc.o locks/unix/intraproc.o locks/unix/locks.o time/unix/time.o time/unix/tim! ! estr.o mmap/unix/common.o mmap/unix/mmap.o shmem/unix/mm_alloc.o shmem/unix/mm_core.o shmem/unix/mm_global.o shmem/unix/mm_lib.o shmem/unix/mm_vers.o shmem/unix/shmem.o i18n/unix/xlate.o user/unix/homedir.o dso/unix/dso.o ar: shmem/unix/mm_alloc.o: No such file or directory make[1]: *** [libapr.la] Error 1 make[1]: Leaving directory `/home/trawick/apache/httpd-2.0/srclib/apr' make: *** [all-recursive] Error 1 [EMAIL PROTECTED] apr]$ [EMAIL PROTECTED] apr]$ libtool --version ltmain.sh (GNU libtool) 1.3.3 (1.385.2.181 1999/07/02 15:49:11) -- 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/user/unix .cvsignore Makefile.in
[EMAIL PROTECTED] writes: gstein 01/01/09 03:06:29 Libtool-ize APR. Index: Makefile.in === RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v retrieving revision 1.14 retrieving revision 1.15 diff -u -u -r1.14 -r1.15 --- Makefile.in 2000/11/15 11:50:07 1.14 +++ Makefile.in 2001/01/09 11:06:15 1.15 ... + cp $(MM_OBJS) . Isn't this copying the wrong (or not enough) files? It currently copies just the .lo (timestamp) files. Maybe it should copy the .o files too. Later, libtool thinks these are the real files (I guess) and when building .libs/libapr.a it ends up creating the symbolic links (the ones that don't work with libtool 1.3.3) and putting these timestamp files in the archive. mm_malloc/mm_free/etc. are not in .libs/libapr.a. They are referenced, of course. -- 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/tables apr_hash.c
Greg Stein [EMAIL PROTECTED] writes: On Tue, Jan 16, 2001 at 12:59:04PM -0500, Jeff Trawick wrote: [EMAIL PROTECTED] writes: ... /** - * Get the number of keys in the hash table. + * Get the number of key/value pairs in the hash table. * @param ht The hash table - * @param count Return pointer for the number of keys + * @return The number of key/value pairs in the hash table. * @deffunc void apr_hash_count(apr_hash_t *ht, apr_size_t *count); */ -APR_DECLARE(void) apr_hash_count(apr_hash_t *ht, apr_size_t *count); +APR_DECLARE(apr_size_t) apr_hash_count(apr_hash_t *ht); silly question: why not int or apr_int32_t instead of apr_size_t? apr_size_t is the internal type. change that, and you can change the return type :-) okay, just checking... maybe I'll do just that :) (IMHO, a sane API is more important than matching internal type, though it seems that both are easy to accomplish in this case) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
[PATCH] what exactly does APR_FINFO_DIRENT do?
This patch gets mod_autoindex working again for me:
Index: srclib/apr/file_io/unix/dir.c
===
RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v
retrieving revision 1.48
diff -u -r1.48 dir.c
--- srclib/apr/file_io/unix/dir.c 2001/01/24 16:16:35 1.48
+++ srclib/apr/file_io/unix/dir.c 2001/01/24 18:07:57
@@ -151,7 +151,7 @@
* only if stat will give us what this platform supports, and we can't
* get it from the platform.
* XXX: Optimize here with d_fileno, d_type etc by platform */
-wanted = ~(APR_FINFO_NAME);
+wanted = ~(APR_FINFO_NAME|APR_FINFO_DIRENT);
if (wanted)
{
char fspec[PATH_MAX];
mod_autoindex specifies APR_FINFO_DIRENT in the call to
apr_dir_read(), and it ended up getting APR_INCOMPLETE as the return
code from apr_dir_read() because apr_dir_read() didn't take out the
APR_FINFO_DIRENT bit and later thought that something wasn't handled.
I hear that mod_autoindex is broken on Win32 too. Maybe something
similar is needed?
But back to the question in the subject... I don't think
APR_FINFO_DIRENT does anything, so why do we need it?
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/file_io/unix filestat.c
William A. Rowe, Jr. [EMAIL PROTECTED] writes: trawick 01/01/24 13:11:52 Modified:file_io/unix filestat.c Log: get filestat.c to compile again and it rides again, I presume? Thanks Jeff autoindex is still failing for me; I'll play with it some more -- 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/include apr_xlate.h
Roy T. Fielding [EMAIL PROTECTED] writes: However, the code will work fine regardless of the warning, so it probably isn't worth the effort to support no warnings on anything but the latest gcc. you mean the latest glibc Previously, we had a warning on OS/390 and Tru64 (and I guess the level of glibc which comes with RH 7) because they had no const, and a clean compile everywhere else. I left it alone since their iconv() did not match the de facto standard and I didn't want to put in a cast that people on normal systems would not understand. I certainly didn't want a cast which would cause warnings. I had no qualms having the warning on Tru64 and OS/390 (not that many people build it on these platforms and it kept the code simpler). Now, most users (I'm guessing, but it seems like a safe guess) will see a warning, so something needs to be done. I'll look into using a different cast trick (or autoconf test) which will avoid the warning on all platforms. As long as there is a reasonable comment in the code I suspect people will live it alone (do you hear that Greg? :) ) Have fun... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: build blues
Greg Stein [EMAIL PROTECTED] writes: [ one thing that bugs me to no end is that we define macros with the AC_ prefix. I see a macro, look it up in the autoconf docs, can't find it, then discover we wrote it. blarg. ... amen (but then I'm guilty of this too from many moons ago :) ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: FreeBSD 4.2 breakage (?)
Regarding _POSIX_SOURCE: What did this solve again? Perhaps my knowledge needs updating, but it wasn't long ago that there was no ratified POSIX standard which covered the networking APIs. I am pretty sure that no POSIX standard covers everything which Apache/APR needs. Frankly, I'm not too concerned that Apache or APR might use some interface which is in no POSIX standard. What is important is that Apache/APR build and run on as many platforms as practical. Whether the standard in vogue is POSIX (which one?), Single UNIX, or whatever, some systems wouldn't implement the new stuff at all and others wouldn't implement it correctly. The same thing is true for the different levels of the much more interesting* single Unix specification. Heck, some systems we work on haven't had new releases in ages. We just have to wander through the many flavors of God's own OS the best we can. *much more interesting because Unix95 (and later) actually specify an interesting enough set of interfaces that you can expect to write a real program using those interfaces; POSIX was never a rich enough set; did anybody hear of Microsoft's original POSIX box on NT? it was POSIX compliant at the programming interface level but you couldn't do anything useful with it -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] iconv tweak
Doesn't AC_TRY_COMPILE() succeed if there is a warning? I think your patch only helps on rare systems where the compiler won't compile it at all if the const-ness doesn't match the iconv() prototype. Yeah, that is an improvement over the current situation but it would be nice to get rid of the problem -- warning or error -- altogether. Mo DeJong [EMAIL PROTECTED] writes: On Sun, 4 Feb 2001, Greg Stein wrote: There was some discussion about iconv prototyes here recently, but I kind of missed it. Do we always need to live with a warning about a type mismatch, or is the cast below appropriate? IOW, do some headers have const on them, and others not? Yup, you cannot just use a cast, you need to use a HAVE... test because headers differ and newer versions of gcc will generate an error on a plain cast. What does plain cast in this sense mean? Here is the bit of code from the Jikes java compiler that deals with this issue. size_t n = iconv(_converter, #ifdef HAVE_ERROR_CALL_ICONV_CONST (char **) #endif source_ptr, srcl, (char **)chp, chl ); The code would be nicer if we define ICONV_INBUF_TYPE to char ** or const char ** and then do n = iconv(_converter, (ICONV_INBUF_TYPE)source_ptr, srcl, (char **)chp, chl); but that is a minor detail (particularly since we have so few calls to iconv). Is it reasonable to test for a compile *warning* via autoconf? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] iconv tweak
Mo DeJong [EMAIL PROTECTED] writes: Is it reasonable to test for a compile *warning* via autoconf? I am not sure why that matters. The point is that apr does not compile on some systems, this iconv #define code will fix that. Warnings do matter, hence my questions. I certainly agree that it is important to get all systems compiling even if we have to have warnings; I'm just wondering about a better solution. Thanks, Jeff -- 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 buildconf
[EMAIL PROTECTED] writes: wsanchez01/02/07 12:42:16 Modified:.buildconf Log: Check for glibtoolize as well as libtoolize. ... Index: buildconf === RCS file: /home/cvs/apr/buildconf,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- buildconf 2001/01/09 11:05:34 1.6 +++ buildconf 2001/02/07 20:42:16 1.7 @@ -3,8 +3,8 @@ # # Build aclocal.m4 from libtool's libtool.m4 and our own M4 files. # -ltpath=`helpers/PrintPath libtoolize` -ltpath=`dirname $ltpath` +libtoolize=`helpers/PrintPath glibtoolize libtoolize` +ltpath=`dirname $libtool` I think you meant ltpath=`dirname $libtoolize` buildconf ain't working right for me and configure isn't either :) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] iconv tweak
Sam TH [EMAIL PROTECTED] writes: The easiest way would probably be to use c++ to test this, since in c++ cast from a char ** to a const char ** is illegal, and generates and error. c++ is cool, but we can't require it so we'd have to see if it failed due to no c++, then back down to the c test -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] a somewhat different approach to the iconv() issue
Roy T. Fielding [EMAIL PROTECTED] writes:
. we *know* that versions of glibc 2.2 have const char **
instead of char ** so make that work without any hints.m4
stuff (which would have to look at the glibc version)
Why not check for GCC and simply add -Werror to the compile?
excellent...
...
I think the final patch should remove the first cast of inbufptr
that I added in my initial fix.
You're talking about this I presume...
@@ -285,7 +285,7 @@
size_t translated;
if (convset-ich != (iconv_t)-1) {
-char *inbufptr = inbuf;
+char *inbufptr = (char *)inbuf;
char *outbufptr = outbuf;
translated = iconv(convset-ich, inbufptr,
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: [PATCH] a somewhat different approach to the iconv() issue
Sascha Schumann [EMAIL PROTECTED] writes: On 7 Feb 2001, Jeff Trawick wrote: Jeff Trawick [EMAIL PROTECTED] writes: Roy T. Fielding [EMAIL PROTECTED] writes: . we *know* that versions of glibc 2.2 have const char ** instead of char ** so make that work without any hints.m4 stuff (which would have to look at the glibc version) Why not check for GCC and simply add -Werror to the compile? excellent... well, in practice it isn't so excellent :( the template for AC_TRY_COMPILE() doesn't even compile without warnings Insert reiterating about pre-ANSI C systems Does anyone around here remember the -Werror thread? Well now I remember :) (off to pluck some gray hairs) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: FreeBSD 4.2 breakage (?)
Jeff Trawick [EMAIL PROTECTED] writes: Regarding _POSIX_SOURCE: Trivia on _POSIX_SOURCE from Tru64... /* * If user defines _POSIX_SOURCE and if _POSIX_C_SOURCE is not defined, * define _POSIX_C_SOURCE to be 1. (_POSIX_SOURCE maps to the POSIX 1003.1 * standard from 1990). */ This stuff can be really aggravating... I'm trying to figure out how to enable the declaration of _SC_CLK_TCK so that mod_status compiles on Tru64. YOY can't they have something like _ALL_SOURCE (like on OS/390) which says I want access to whatever you've got, standards be damned? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_ function prefixes
Garrett Rooney [EMAIL PROTECTED] writes: on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put and apr_os_thread_put. i assume that's wrong, since i can't for the life of me figure out what pupt would mean ;-) good for you if sleeping child cooperates I'll fix it up Real Soon Now... $ grep pupt `find . -name '*.h'` ./srclib/apr/include/apr_portable.h: * @deffunc apr_status_t apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, apr_os_exp_time_t **ostime, apr_pool_t *cont) ./srclib/apr/include/apr_portable.h:APR_DECLARE(apr_status_t) apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, ./srclib/apr/include/apr_portable.h: * @deffunc apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd, ./srclib/apr/include/apr_portable.h:APR_DECLARE(apr_status_t) apr_os_thread_pupt(apr_thread_t **thd, $ grep pupt `find . -name '*.c'` ./server/exports.c:const void *ap_hack_apr_os_exp_time_pupt = (const void *)apr_os_exp_time_pupt; ./server/exports.c:const void *ap_hack_apr_os_thread_pupt = (const void *)apr_os_thread_pupt; ./srclib/apr/threadproc/beos/thread.c:apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd, ./srclib/apr/threadproc/unix/thread.c:apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd, ./srclib/apr/threadproc/win32/thread.c:APR_DECLARE(apr_status_t) apr_os_thread_pupt(apr_thread_t **thd, ./srclib/apr/time/unix/time.c:apr_status_t apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, ./srclib/apr/time/win32/time.c:APR_DECLARE(apr_status_t) apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] a somewhat different approach to the iconv() issue
Roy T. Fielding [EMAIL PROTECTED] writes: What was checked in doesn't work -- I now get warnings again on my platform, and mine is the one with the correct prototypes. Hmmm... I get no warnings on a system of each flavor (Tru64 and RedHat 6) and got no warnings. What warnings do you get? Did the configure output display the right message? checking for type of inbuf parameter to iconv... char ** RedHat 7 with the latest glibc compiled from source. There are two problems, one easy and one not yet figured out: 1) The #ifdef APR_ in xlate.c must be a #if Why is that? We generally use #ifdef FOO if FOO is sometimes defined and sometimes not (e.g., APR_ICONV_INBUF_CONST). We generally use #if FOO if FOO is always defined but sometimes to 1 and sometimes to 0 (e.g., APR_HAS_XLATE). 2) The test is looking at the versions and triggering #error I don't know why the version test is giving a false-positive, nor do I particularly care -- I don't think this can be fixed by assuming the version numbers mean anything. The fix I am working on is a replacement for AC_TRY_COMPILE, but m4 isn't one of my strong points. I don't follow your comment about assuming the version numbers mean anything. Maybe if I saw the version numbers in glibc 2.2's features.h it would be easy to follow what you are saying. If you can get -Werror working for gcc, obviously we don't need the glibc version check since we can expect to use gcc on a platform which uses glibc 99.99% of the time, but I can't help but be curious about why it generated the #error on RH 7.0 which has glibc 2.2 (and I guess __GLIBC_MINOR__ == 2). (I wasn't too eager to write the compile macro either. When I considered a different flavor of AC_TRY_COMPILE it was obvious that I would have to start by cutting and pasting AC_TRY_COMPILE. A quick look at the license reminded me that I am not a lawyer :) ) -- 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
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: apr_ function prefixes
Jeff Trawick [EMAIL PROTECTED] writes: Garrett Rooney [EMAIL PROTECTED] writes: on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put and apr_os_thread_put. i assume that's wrong, since i can't for the life of me figure out what pupt would mean ;-) good for you if sleeping child cooperates I'll fix it up Real Soon Now... well, all I got was cvs not-up-to-date messages :) mailing list delays are no fun... -- 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/file_io/unix dir.c
William A. Rowe, Jr. [EMAIL PROTECTED] writes: trawick 01/02/12 12:55:34 Modified:file_io/unix dir.c Log: OS/390 has _POSIX_PATH_MAX but not PATH_MAX (did I hear a little bird say APR_PATH_MAX?) Yes... the 'right' fix would be good here. This should be pretty simple... apr.hw: Move this code from include/arch/win32/fileio.h to apr.hw but also add any needed includes (what are they?): #if APR_HAS_UNICODE_FS /* An arbitrary size that is digestable. True max is a bit less than 32000 */ #define APR_PATH_MAX 8192 #define APR_FILE_MAX MAX_PATH #else /* !APR_HAS_UNICODE_FS */ #define APR_PATH_MAX MAX_PATH #define APR_FILE_MAX MAX_PATH #endif apr.h.in: include sys/limits.h and limits.h then #if defined(PATH_MAX) #define APR_PATH_MAX PATH_MAX #elif defined(_POSIX_PATH_MAX) #define APR_PATH_MAX _POSIX_PATH_MAX #else #error Fix APR_PATH_MAX for your platform. #endif -- 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/file_io/unix dir.c
Kevin Pilch-Bisson [EMAIL PROTECTED] writes: (imagine the APR_MAX_PATH pseudo code here...) Has it been decided that this will happen? If so, any idea when? yes; most likely today (I started it this a.m. but got interrupted with something else; hope to get back to it Real Soon Now) Have fun, -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: threads on FreeBSD - disable?
[EMAIL PROTECTED] writes: So far it seems counterproductive to build a threaded APR app on FreeBSD. I suggest that APR needs logic like the following: if FreeBSD: if --enable-threads specified, abort configure with an error message else configure without thread support I would suggest just putting this into hints.m4 for APR, so that we automagically disable threading on FreeBSD for anything before 4.2-STABLE. Rumor is that 4.2-STABLE has valid thread support. I would rather not put this in configure.in, because this is the kind of thing hints.m4 was designed for. sounds cool! -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Working platforms - HP-UX 11.00
Justin Erenkrantz [EMAIL PROTECTED] writes: Notes regarding HP-UX compilation with latest CVS snapshots of httpd-2.0, apr, and apr-util: config.guess: hppa2.0w-hp-hpux11.00 uname: HP-UX B.11.00 U 9000/800 HP's Ansi C compiler (non-free): HP C/HP-UX Version A.11.01.00 MPM: prefork Let me know if you want more details about the hardware and software setup. The key is HP-UX 11.00 with HP's C compiler. apr_sendfile doesn't have an implementation in APR defined for HP-UX. I do know that HP has different sendfile() semantics than Solaris or FreeBSD. I seem to remember Linus Torvalds mentioning on lkml that HP-UX had braindamage in its sendfile implementation: weird or not, I implemented apr_sendfile() on HP-UX and it works fine with the APR test program; I'll test with Apache Real Soon Now (hopefully this weekend); I just got an HP-UX 11 account and need to get a regression test bootstrapped (by the way, we don't build with the HP compiler on HP 10.20; need to look lots further into which compiler I have access to and why it doesn't like some seemingly benign declarations in APR) There were some compiler warnings, but I didn't really pay attention to those (seemed mostly harmless). I fixed some and also have an uncommitted patch to add -D_XOPEN_SOURCE_EXTENDED (forgive spelling mistakes here); I need to double check the difference in compiler messages with and without before committing. Since pthread is new in HP-UX 11.xx, it might not be a terribly bad idea to test out the MPM pthreads model as well (I used prefork) - if I get a chance later today, I might do so. Any stress testing you can do with pthread would be great. I don't expect to have time to do much more than verify that it basically works under extremely light loads. At least this will be done on a regular basis (thanks to cron and perl). If desired, I can also dig up some time on an IBM AIX 4.3 box to test. Not sure if anyone has confirmed AIX yet. A few of us at IBM run on AIX 4.3.3 regularly. AFAIK, any time you have would be best spent on HP-UX as it would seem to have the least care and feeding of the two. Hope this helps, certainly! -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Working platforms - HP-UX 11.00
Cliff Woolley [EMAIL PROTECTED] writes: --- Jeff Trawick said: (by the way, we don't build with the HP compiler on HP 10.20; need to look lots further into which compiler I have access to and why it doesn't like some seemingly benign declarations in APR) That doesn't surprise me... HP-UX's native compiler has been known to do some massively stupid things. I don't know about sendfile being braindead, but the compiler certainly is IMO. Anyway, if you need me to test with either the native compiler or gcc on a 10.20 box, I've still got accounts on a couple... I'd be real interested in your experiences with the HP compiler on 10.20. Let me know if it compiles APR. Note that I had to remove a duplicate declaration from apr_pools.c (struct process_chain; I think) to get going, but then on later files I get some error 1711 complaining about inconsistent parameter list declaration or similar. A google on 1711 HP-UX yields a bounty of problems compiling other sets of code. Ken suggests that I may be accessing a bundled pre-ANSI compiler and it is simply ignoring the command-line parms which tell it to pretend to be a real compiler. I dunno... If I get time I'll build 1.3 on this box and if successful see what is different about the compiler parms. -- 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-util Makefile.in
[EMAIL PROTECTED] writes: Index: Makefile.in === RCS file: /home/cvs/apr/Makefile.in,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- Makefile.in 2001/02/16 10:17:10 1.40 +++ Makefile.in 2001/02/17 16:10:55 1.41 @@ -61,7 +61,7 @@ fi \ fi -$(TARGET_EXPORTS): +$(TARGET_EXPORTS): include/*.h Solaris doesn't like this :( make[3]: *** No rule to make target `include/*.h', needed by `apr.exports'. Stop. make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 --end of /export/home/trawick/regress/logs/make.stderr- -$(TARGET_EXPORTS): +$(TARGET_EXPORTS): include/*.h $(AWK) -f @APR_SOURCE_DIR@/helpers/make_export.awk include/*.h $@ ; again -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] allow using GNU make on BSDi
Joe Orton [EMAIL PROTECTED] writes: Hi, This copes with BSDi installations where the default make has been replaced with GNU make: committed; will this work for Apache without making anyone hurl? Index: configure.in === RCS file: /home/cvspublic/httpd-2.0/configure.in,v retrieving revision 1.123 diff -u -r1.123 configure.in --- configure.in2001/02/18 16:07:31 1.123 +++ configure.in2001/02/19 23:01:22 @@ -274,7 +274,13 @@ BSD_MAKEFILE=no case $host_alias in *bsdi*) -BSD_MAKEFILE=yes;; +# Check whether they've installed GNU make +if make --version /dev/null 21; then +true +else +BSD_MAKEFILE=yes +fi +;; esac AC_OUTPUT($APACHE_OUTPUT_FILES support/apxs support/apachectl,,[ -- 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/threadproc/unix signals.c
[EMAIL PROTECTED] writes: rbb 01/02/20 17:15:49 Modified:buildapr_threads.m4 include apr_thread_proc.h threadproc/unix signals.c Log: Add some functions to APR's thread/processes support to allow a single thread to handle all signal processing. this was a doozy (sp?) of a commit new configure warnings/errors: buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: libtool version 1.3.5 (ok) rebuilding aclocal.m4 rebuilding configure ./aclocal.m4:214: /bin/m4: Warning: Excess arguments to built-in `define' ignored configure.in:70: AC_TRY_COMPILE was called before AC_AIX configure.in:71: AC_TRY_COMPILE was called before AC_ISC_POSIX configure.in:72: AC_TRY_COMPILE was called before AC_MINIX rebuilding include/ap_config_auto.h.in ./aclocal.m4:214: /bin/m4: Warning: Excess arguments to built-in `define' ignored configure.in:70: AC_TRY_COMPILE was called before AC_AIX configure.in:71: AC_TRY_COMPILE was called before AC_ISC_POSIX configure.in:72: AC_TRY_COMPILE was called before AC_MINIX rebuilding srclib/apr/configure new link-edit errors: apr_sigwait() unresolved -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: add rename symbols to ap*_compat.h
Greg Stein [EMAIL PROTECTED] writes: Okay, people. Here is your chance to vote. add 2.0 symbol renames to ap*_compat.h: -0: Greg, Doug -0: Jeff (-0.2 actually, but why be different) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: httpd-2.0 does not build -- missing apr_sigwait
Martin Kraemer [EMAIL PROTECTED] writes:
The current apr is missing a macro apr_sigwait(), it is referenced in
apr/threadproc/unix/signals.c, and I guess it must look somewhat
similar to the following:
#ifdef SIGWAIT_TAKES_ONE_ARG
#define apr_sigwait(a,b) sigwait(a)
#else
#define apr_sigwait(a,b) sigwait(a,b)
#endif
The return code of the single-parameter sigwait() is the signal
number (except -1 for error). The second param of the
double-parameter sigwait() is updated with the signal number (except
in error case).
Without this macro, httpd-2.0 doesn't build, because apr_sigwait is
unresolved at link time.
I was going to commit this fix (Ryan had told me recently he had added
me to the committers list), but alas:
Access denied: Insufficient Karma (martin|apr/threadproc/unix)
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!
cvs commit: saving log message in /tmp/cvssIKmf78601
I can't fix that but I will try to commit *something* Real Soon Now.
I will try to spend time debugging the new buildconf warnings before
testing any code though so no guarantees that the apr_sigwait() fix is
golden.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: httpd-2.0 with apr_sigwait() patch loops.
Martin Kraemer [EMAIL PROTECTED] writes: Uhmmm... The patch I just proposed doesn't really cut it. It makes apache compile build, but when starting it, it loops (linux, threaded) and eats huge amounts of CPU power. Same with --with-mpm=prefork Martin: I tested prefork lightly on Linux (RH 6.0) with the sigwait() change I just committed and observed no looping, either in -DONE_PROCESS mode or in normal mode. Take care, Jeff -- 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/threadproc/unix signals.c
Jeff Trawick [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: rbb 01/02/20 17:15:49 Modified:buildapr_threads.m4 include apr_thread_proc.h threadproc/unix signals.c Log: Add some functions to APR's thread/processes support to allow a single thread to handle all signal processing. this was a doozy (sp?) of a commit new configure warnings/errors: buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: libtool version 1.3.5 (ok) rebuilding aclocal.m4 rebuilding configure ./aclocal.m4:214: /bin/m4: Warning: Excess arguments to built-in `define' ignored configure.in:70: AC_TRY_COMPILE was called before AC_AIX configure.in:71: AC_TRY_COMPILE was called before AC_ISC_POSIX configure.in:72: AC_TRY_COMPILE was called before AC_MINIX okay, maybe I can't pin this one on you :) I don't know exactly when this started. Unfortunately my build regression doesn't track changes to the stdout/stderr of buildconf (about to fix), so easy clues about the offending commit are not present. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: httpd-2.0 with apr_sigwait() patch loops.
Martin Kraemer [EMAIL PROTECTED] writes: I found out who the culprit is. It's the platform. The following patch disables the broken sendfile() implementation on s390-ibm-linux-gnu (see attachment). After that patch, httpd-2.0 works both threaded and preforked. Beauteous (well, that it works)... If you keep up with Linux-on-S/390 kernel issues then we'll eventually know when to allow it on a certain version. I've got an id on one of these systems somewhere, but after the initial shock of discovering that it's just Linux I haven't played. About to commit... Take care, Jeff -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: httpd-2.0 with apr_sigwait() patch loops.
Martin Kraemer [EMAIL PROTECTED] writes: Uhmmm... The patch I just proposed doesn't really cut it. It makes apache compile build, but when starting it, it loops (linux, threaded) and eats huge amounts of CPU power. Martin: Any idea how we would get to sendfile() when starting Apache? We shouldn't be there at all, so perhaps disabling sendfile() on s390 linux was not the right fix. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
CFLAGS vs. THREAD_CPPFLAGS
Solaris is failing to build right now because the sigwait() num-argument check is failing. When we run the test, -D_POSIX_PTHREAD_SEMANTICS is not passed to the compiler so we get the one-argument version and SIGWAIT_TAKES_ONE_ARG is defined. When we compile apr/threadprox/unix/signals.c, -D_POSIX_PTHREAD_SEMANTICS is passed to the compiler because apr_hints.m4 puts it in THREAD_CPPFLAGS. Thus we get the prototype for the two-argument version and we fail to compile. Does anybody know exactly why this worked before? I'm not sure what the right fix is yet... gotta look further. -- 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: 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: CFLAGS vs. THREAD_CPPFLAGS
[EMAIL PROTECTED] writes: This probably used to work because Apache was never setting the flags. oh... that is good to know... I'll have to play with this before too terribly long, but definitely not today. -- 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/threadproc/unix signals.c
[EMAIL PROTECTED] writes: These are a bit too unix specific for OS/2 (pthread/sigwait). ... Index: signals.c === RCS file: /home/cvs/apr/threadproc/unix/signals.c,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- signals.c 2001/02/21 20:49:28 1.22 +++ signals.c 2001/02/23 02:06:14 1.23 @@ -267,7 +267,7 @@ #endif /* SYS_SIGLIST_DECLARED */ -#if APR_HAS_THREADS +#if APR_HAS_THREADS !defined(OS2) Why don't you need the same construct in apr_thread_proc.h so that exports.c doesn't try to reference apr_create_signal_thread/apr_setup_signal_thread? (Oh, and where is that Perl guy? We got the verb before the object with these functions.) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_sigwait/SunOS compile break
Cliff Woolley [EMAIL PROTECTED] writes: I'm still having problems with an incorrectly detected number of arguments to sigwait on SunOS as of Friday, I think, and AFAIK no patches have gone in to fix it. I know this was mentioned on the list earlier this week... were any conclusions reached? Basically, it's a problem of SunOS having different numbers of arguments for sigwait depending upon what is #defined... I seem to recall it was a problem with the configure script not including all the right CFLAGS. When we tested sigwait() we didn't have some thread-related flags turned on yet. But those thread-related flags get us a different flavor of sigwait() later. I'm not sure a conclusion on how to handle was reached either. I'll just make up one. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: OT Question
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Who can point me at the best FreeBSD or Linux rpm for utf-8 support so I can really get my hands dirty on that side of the equation? FYI... I never found utf-8 support for versions of glibc I had on my Linux boxen. I tested multibyte stuff on Solaris and OS/390 only. -- 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: APR_FLAG_HEADERS
Jim Jagielski [EMAIL PROTECTED] writes: I've got a real cool idea about how to make everyone happy... Heading out right now, but will commit something later today :) Just for my curiosity, can you tell me which system actually can build APR after these cool ideas were implemented? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: threaded MPM and the signal thread
Jeff Trawick [EMAIL PROTECTED] writes: watch out non-Linux-ers... Since the signal handling was moved around in the threaded MPM, on Tru64 and AIX the child processes are looping somewhere and they don't respond to SIGTERM. It seems that the problems started when we went from sigemptyset(sig_mask); sigaddset(sig_mask, SIGINT); sigaddset(sig_mask, SIGTERM); to sigfillset(sig_mask); when building the mask for sigwait(). It turns out that AIX and Tru64 have issues with this. The code snipped below from a test program I wrote illustrates what unexpected attention to the signal mask is required on AIX and Tru64 (and perhaps other platforms, but certainly not Linux and Solaris). When APR builds again I'll try similar logic in the new signal functions and hopefully the issues with the threaded MPM on AIX and Tru64 will be gone. It is safe to do the sigdelset() calls in common code, as long as we test for the definition of the signal. There is one piece of code (clearing the high-order bit) which is very much AIX-specific though. #ifdef _AIX printf(signal mask after sigfillset() but before fixing:\n); show_sig_mask(sig_mask); /* we shouldn't have to do this, but sigwait() on AIX 4.3.3 doesn't * work correctly with all the bits on */ /* with any of the first four in the set, sigwait() returns EINVAL */ sigdelset(sig_mask, SIGKILL); sigdelset(sig_mask, SIGSTOP); sigdelset(sig_mask, SIGCONT); sigdelset(sig_mask, SIGWAITING); /* with this bit on, sigwait() blocks but never wakes up */ /* manually turn this off because sigdelset() returns an error when you try to clear it */ sig_mask.hisigs = 0x7FFF; #endif /* _AIX */ #ifdef TRU64 printf(signal mask after sigfillset() but before fixing:\n); show_sig_mask(sig_mask); /* with any of these three signals in the set, sigwait() returns EINVAL */ sigdelset(sig_mask, SIGKILL); sigdelset(sig_mask, SIGSTOP); sigdelset(sig_mask, SIGCONT); #endif -- 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/build apr_common.m4
[EMAIL PROTECTED] writes: gstein 01/02/27 03:34:50 Modified:.configure.in buildapr_common.m4 Log: * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to loop over the values *once* rather than substituting N loops for header checking. This drops configure's size from 340k down to 255k. (!!!) * apr_common.m4: M4 sees the shell's backslash, so treat it as whitespace in APR_COMMA_ARGS now APR on Tru64 doesn't think it has stdio.h (sort of; configure output says we found it; APR_HAVE_STDIO_H is set to zero); a few other header files aren't substituted properly either... work-around forthcoming... yes, this is with a virgin configure.in with none of my changes in it -- 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/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-util/build apu-conf.m4
[EMAIL PROTECTED] writes: gstein 01/02/28 07:18:37 Modified:.buildconf.sh buildapu-conf.m4 Log: *) buildconf.sh should invoke expat's buildconf.sh, if it exists *) expat.h.in is a more reliable test for an Expat distribution *) look for xml/expat-cvs before xml/expat *) invoke expat's configuration when APRUTIL is configured Note: we needed to copy over APR_SUBDIR_CONFIG (and rename) since APRUTIL is not (yet) including apr/build/apr_common.m4 (and it is a big change to do that use/sharing) I suspect that this commit introduced these error messages from buildconf. Something committed in the 5 hours preceding approx 10:48 est. caused these messages to be added. --/home/trawick/regress/logs/buildconf.stderr.diff--- 0a1,2 configure.in:72: warning: AC_TRY_RUN called without default to allow cross compiling configure.in:72: warning: AC_TRY_RUN called without default to allow cross compiling --end of /home/trawick/regress/logs/buildconf.stderr.diff-I I have no theory as to the exact problem... Maybe expat exhibits that problem outside of apr-util? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: autoconf and Gnu m4... a matched set?
Jim Jagielski [EMAIL PROTECTED] writes: According to the autoconf docs: Autoconf requires GNU `m4' in order to generate the scripts. It uses features that some UNIX versions of `m4' do not have. It also overflows internal limits of some versions of `m4', including GNU `m4' 1.0. You must use version 1.1 or later of GNU `m4'. Using version 1.3 or later will be much faster than 1.1 or 1.2. Not sure how really true or relevant that is right now... That is a powerful argument in general, but please note that what is in CVS now will not build on my Mandrake 7.2 box (GNU m4 1.4, autoconf 2.13, glibc 2.1.3) while it will build on my RedHat 6.0 box (GNU m4 1.4, autoconf 2.13, glibc 2.1.1). While changing the m4 may help some get the APR_FLAG_HEADERS() stuff to work, it looks to me that even libc differences make a difference. Or maybe it is because my Mandrake 7.2 box is a laptop. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: configure as root?
Luke Kenneth Casson Leighton [EMAIL PROTECTED] writes: question. samba, in its search for info during ./configure-time, fails certain tests (e.g. the setuid ones) if not run as root. same for apr? nope; no such tests -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: httpd-2.0/apr/apr-util Code Freeze
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Can we begin a code freeze, excepting _minor_ build and code fixes, until we have a stable tarball ready to share? I have win32 folks trying to make apache2.0a9 build, this just doesn't make any sense. Once Ryan's patch is in, let's roll, and then go back to town. I think that whoever plans to tag/roll should suggest a target time (e.g., Friday noon PST) as well as a timeframe for soft freeze (only build fixes and minor code fixes welcome for 16 hours prior to target??). A hard freeze right around the tag is expected. Part of this was implied in your earlier note (you anticipated that Ryan would commit a fix sometime today and we'd tag/roll later today). Now that Ryan suggests Thursday or Friday I wonder when you want a freeze. I don't want a freeze now if we don't tag/roll until Friday afternoon. 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/user/unix userinfo.c
[EMAIL PROTECTED] writes: Of course, you are correct this isn't very portable. However, with a bit of time and effort, and can be made portable. John has discovered exactly what you say in this message, and he will be working on making this much more portable in the next few days. It would be helpful to see his plans before it is committed, as I need to add special code to validate a password on OS/390. (John? Care to briefly describe your plans here?) For now I will put in a hack to keep that file compiling on OS/390 (no pw_passwd field). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Problem with apr-util/xml/expat
Tru64 is busted with this too, though when I do make from toplevel, link of dftables failes because libexpat.la does not exist. A make from xml just says Making all in expat A make from xml/expat does nothing. Oh, I have to touch config.status for some reason. When I do make from srclib/apr-util/xml/expat/lib I get /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.2 -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -c xmlparse.c cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c -o xmlparse.o cc: Severe: No such file or directory ... file is '.deps/xmlparse.pp' *** Exit 1 Stop. jean-frederic clere [EMAIL PROTECTED] writes: Hi, I have some problems with the Makefile on apr-util/xml/expat. The option -Wp,-MD,.deps/$(*F).pp is no understand neither on Solaris nor on ReliantUnix. On Solaris the fix is to use: +++ $(LTCOMPILE) -xM $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ Instead of $(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ On ReliantUnix the -xM option is -M, so I have: +++ $(LTCOMPILE) -M $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ I am afraid we need a way to find how -Wp,-MD, option should be processed. Cheers Jean-frederic -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Problem with apr-util/xml/expat
Greg Stein [EMAIL PROTECTED] writes: Fixed. What got fixed (Thanks!) is that once we decide to make in the lib directory we don't blow up with the non-portable dependency generation. I'm still getting bitchy e-mails from AIX, HP-UX, and Tru64. We aren't doing the make in the lib directory there. Tru64: /bin/sh /home/trawick/apache/httpd-2.0/libtool --silent --mode=link cc -I. -I/home/trawick/apache/httpd-2.0/srclib/pcre -I/home/trawick/apache/httpd-2.0/server/mpm/prefork -I/home/trawick/apache/httpd-2.0/modules/http -I/home/trawick/apache/httpd-2.0/include -I/home/trawick/apache/httpd-2.0/srclib/apr/include -I/home/trawick/apache/httpd-2.0/srclib/apr-util/include -I/home/trawick/apache/httpd-2.0/modules/dav/main -I/home/trawick/apache/httpd-2.0/os/unix -DOSF1 -DAPACHE_XLATE -g -DNO_DBM_REWRITEMAP -pthread -export-dynamic -export-dynamic -export-dynamic -export-dynamic -export-dynamic -export-dynamic -o dftables dftables.lo -ldb -lm -liconv /home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib/libexpat.la libtool: link: `/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib/libexpat.la' is not a valid libtool archive (I get the same message on HP-UX; I get collect2: Library libexpat not found on AIX, but that may be because we have a beta libtool installed there and they realized that not a valid libtool archive isn't a cool message for when it doesn't exist.) looking in the expat directory: [EMAIL PROTECTED] expat]$ ls -lrt total 281 -rw-r--r-- 1 trawick users 3593 Feb 28 09:41 Makefile.in -rw-r--r-- 1 trawick users 2897 Feb 28 09:41 README -rw-r--r-- 1 trawick users382 Feb 28 09:41 acconfig.h -rwxr-xr-x 1 trawick users764 Feb 28 09:41 buildconf.sh -rw-r--r-- 1 trawick users 2042 Feb 28 09:41 configure.in drwxr-xr-x 2 trawick users 8192 Feb 28 14:26 CVS -rw-r--r-- 1 trawick users 15196 Mar 9 10:30 aclocal.m4 drwxr-xr-x 3 trawick users 8192 Mar 9 10:30 conftools -rw-r--r-- 1 trawick users 1257 Mar 9 10:31 config.h.in -rwxr-xr-x 1 trawick users 87833 Mar 9 10:31 configure -rwxr-xr-x 1 trawick users 118755 Mar 10 07:38 libtool -rw-r--r-- 1 trawick users 3902 Mar 10 07:38 Makefile -rw-r--r-- 1 trawick users 1358 Mar 10 07:38 config.h -rw-r--r-- 1 trawick users 3351 Mar 10 07:38 config.log -rwxr-xr-x 1 trawick users 11153 Mar 10 07:38 config.status drwxr-xr-x 3 trawick users 8192 Mar 10 07:38 lib $(SUBDIRS), or rather lib, depends on config.status. But it is no older than config.status so we don't change into lib and make. If I simply remove config.status from the dependencies for $(SUBDIRS) it still doesn't build it. I don't know why. If I touch config.status, it does build it. This is kind of a hokey change, but at least it gets Tru64 working... I'd guess that AIX and HP-UX would follow right behind, but shi@ often happens. Index: Makefile.in === RCS file: /home/cvspublic/apr-util/xml/expat/Makefile.in,v retrieving revision 1.1 diff -u -r1.1 Makefile.in --- Makefile.in 2001/02/28 14:41:24 1.1 +++ Makefile.in 2001/03/10 13:34:10 @@ -83,7 +83,7 @@ DISTDIR = $(PACKAGE)-$(VERSION) DISTRIBUTION = $(DISTDIR).tar.gz -all: $(SUBDIRS) +all: $(SUBDIRS) lib/libexpat.la .PHONY: all $(SUBDIRS) clean distclean maintainer-clean dist install \ uninstall distdir @@ -108,6 +108,8 @@ $(SUBDIRS): config.status cd $@; $(MAKE) +lib/libexpat.la: + cd lib; $(MAKE) clean: @list='$(SUBDIRS)'; for dir in $$list; do \ I'm late for waffle iron duty so over and out for now. Cheers, -g On Fri, Mar 09, 2001 at 11:22:04AM -0500, Jeff Trawick wrote: Tru64 is busted with this too, though when I do make from toplevel, link of dftables failes because libexpat.la does not exist. A make from xml just says Making all in expat A make from xml/expat does nothing. Oh, I have to touch config.status for some reason. When I do make from srclib/apr-util/xml/expat/lib I get /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.2 -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -c xmlparse.c cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c -o xmlparse.o cc: Severe: No such file or directory ... file is '.deps/xmlparse.pp' *** Exit 1 Stop. jean-frederic clere [EMAIL PROTECTED] writes: Hi, I have some problems with the Makefile on apr-util/xml/expat. The option -Wp,-MD,.deps/$(*F).pp is no understand neither on Solaris nor on ReliantUnix. On Solaris the fix is to use: +++ $(LTCOMPILE) -xM $ .deps/$(*F).pp
Re: Problem with apr-util/xml/expat
Greg Stein [EMAIL PROTECTED] writes: On Sat, Mar 10, 2001 at 08:35:19AM -0500, Jeff Trawick wrote: Greg Stein [EMAIL PROTECTED] writes: Fixed. What got fixed (Thanks!) is that once we decide to make in the lib directory we don't blow up with the non-portable dependency generation. I'm still getting bitchy e-mails from AIX, HP-UX, and Tru64. We aren't doing the make in the lib directory there. ... I'm just going to nuke the dep. not good enough, unfortunately (at least on Tru64) look at this simple Makefile: [EMAIL PROTECTED] testmake]$ cat Makefile all: mydir mydir: cd mydir; make [EMAIL PROTECTED] testmake]$ If the directory mydir actually exists, it won't do a damn thing. If the directory mydir does not exist, it will try to run cd mydir; make. The same thing is happening with SUBDIRS = lib all: $(SUBDIRS) $(SUBDIRS) : cd $@; make It thinks lib is up-to-date and won't rebuild it, even after removing config.status from the dependency. I think that either some sort of timestamp file or an explicit dependency on the file we need in libs is needed. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Problem with apr-util/xml/expat
Jeff Trawick [EMAIL PROTECTED] writes: The same thing is happening with SUBDIRS = lib all: $(SUBDIRS) $(SUBDIRS) : cd $@; make It thinks lib is up-to-date and won't rebuild it, even after removing config.status from the dependency. I think that either some sort of timestamp file or an explicit dependency on the file we need in libs is needed. no, that isn't true; about to commit something that works the same way as the other targets -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
[PRE-PATCH] move ip subnet details from mod_access to APR
occurred;
+}
+a-type = T_IP;
+}
+/* XXX not sure what to do here; apr_ipsubnet_create() would need to
decide that
+ * it isn't an IP address at all and tell the caller somehow
+ */
+else if ((rv = apr_ipsubnet_create(a-x.ip, where, NULL, cmd-pool)) !=
APR_EINVAL) {
+if (rv != APR_SUCCESS) {
+/* XXX build APR error string from rv and return it */
+return some APR error occurred;
+}
+a-type = T_IP;
}
else {
a-type = T_HOST;
@@ -330,14 +256,8 @@
return 1;
case T_IP:
-/* XXX handle IPv6 with separate T_IP6 type or add common
- * address masking operations to APR */
- if (ap[i].x.ip.net != APR_INADDR_NONE
-(r-connection-remote_addr-sa.sin.sin_addr.s_addr
-ap[i].x.ip.mask) == ap[i].x.ip.net) {
- return 1;
- }
- break;
+return apr_ipsubnet_test(ap[i].x.ip, r-connection-remote_addr);
+break;
case T_HOST:
if (!gothost) {
Index: srclib/apr/include/apr_errno.h
===
RCS file: /home/cvspublic/apr/include/apr_errno.h,v
retrieving revision 1.54
diff -u -r1.54 apr_errno.h
--- srclib/apr/include/apr_errno.h 2001/02/16 04:15:42 1.54
+++ srclib/apr/include/apr_errno.h 2001/03/14 12:51:47
@@ -177,6 +177,8 @@
* APR_EDSOOPEN APR was unable to open the dso object. For more
* information call apr_dso_error().
* APR_EGENERAL General failure (specific information not available)
+ * APR_EBADIP The specified IP address is invalid
+ * APR_EBADMASK The specified netmask is invalid
* /PRE
*
* PRE
@@ -232,8 +234,8 @@
#define APR_ENOTHDKEY (APR_OS_START_ERROR + 13)
#define APR_EGENERAL (APR_OS_START_ERROR + 14)
#define APR_ENOSHMAVAIL(APR_OS_START_ERROR + 15)
-/* empty slot: +16 */
-/* empty slot: +17 */
+#define APR_EBADIP (APR_OS_START_ERROR + 16)
+#define APR_EBADMASK (APR_OS_START_ERROR + 17)
/* empty slot: +18 */
#define APR_EDSOOPEN (APR_OS_START_ERROR + 19)
@@ -254,8 +256,8 @@
#define APR_STATUS_IS_ENOTHDKEY(s) ((s) == APR_ENOTHDKEY)
#define APR_STATUS_IS_EGENERAL(s) ((s) == APR_EGENERAL)
#define APR_STATUS_IS_ENOSHMAVAIL(s)((s) == APR_ENOSHMAVAIL)
-/* empty slot: +16 */
-/* empty slot: +17 */
+#define APR_STATUS_IS_EBADIP(s) ((s) == APR_EBADIP)
+#define APR_STATUS_IS_EBADMASK(s) ((s) == APR_EBADMASK)
/* empty slot: +18 */
#define APR_STATUS_IS_EDSOOPEN(s) ((s) == APR_EDSOOPEN)
Index: srclib/apr/include/apr_network_io.h
===
RCS file: /home/cvspublic/apr/include/apr_network_io.h,v
retrieving revision 1.99
diff -u -r1.99 apr_network_io.h
--- srclib/apr/include/apr_network_io.h 2001/03/08 19:58:35 1.99
+++ srclib/apr/include/apr_network_io.h 2001/03/14 12:51:48
@@ -218,6 +218,19 @@
int numtrailers;
};
+/** A structure to represent an IP subnet */
+typedef struct apr_ipsubnet_t apr_ipsubnet_t;
+struct apr_ipsubnet_t {
+int family;
+#if APR_HAVE_IPV6
+apr_uint32_t sub[4]; /* big enough for IPv4 and IPv6 addresses */
+apr_uint32_t mask[4];
+#else
+apr_uint32_t sub[1];
+apr_uint32_t mask[1];
+#endif
+};
+
/* function definitions */
/**
@@ -753,6 +766,26 @@
*/
APR_DECLARE(apr_status_t) apr_getservbyname(apr_sockaddr_t *sockaddr,
const char *servname);
+
+/**
+ * Build an ip-subnet representation from an IP address and optional netmask or
+ * number-of-bits.
+ * @param ipsub The new ip-subnet representation
+ * @param ipstr The input IP address string
+ * @param mask_or_numbits The input netmask or number-of-bits string, or NULL
+ * @param p The pool to allocate from
+ */
+APR_DECLARE(apr_status_t) apr_ipsubnet_create(apr_ipsubnet_t **ipsub, const
char *ipstr,
+ const char *mask_or_numbits,
apr_pool_t *p);
+
+/**
+ * Test the IP address in an apr_sockaddr_t against a pre-built ip-subnet
+ * representation.
+ * @param ipsub The ip-subnet representation
+ * @param sa The socket address to test
+ * @return non-zero if the socket address is within the subnet, 0 otherwise
+ */
+APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub, apr_sockaddr_t *sa);
#ifdef __cplusplus
}
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Problem Build Latest Win32 CVS Release
Ian Holsman [EMAIL PROTECTED] writes: Hi. I'm trying to build the latest APR CVS release using the .dsw supplied in Apache. I've run into the problem where it couldn't find apr_inet_pton. I can't just include the file, as it uses EAFNOSUPPORT which isn't defined in Win32. I think this is a pretty recent change, due to the Win32 file trying include ../unix/sa_common.c I guess I'm the problem... I didn't realize that we didn't build inet_pton on Win32. Can you try this? Hopefully I'll get a chance to play with it later. Thanks (and sorry!), Jeff Index: apr.dsp === RCS file: /home/cvspublic/apr/apr.dsp,v retrieving revision 1.66 diff -u -r1.66 apr.dsp --- apr.dsp 2001/02/03 16:31:07 1.66 +++ apr.dsp 2001/03/15 23:32:36 @@ -267,6 +267,10 @@ # End Source File # Begin Source File +SOURCE=.\network_io\unix\inet_pton.c +# End Source File +# Begin Source File + SOURCE=.\include\arch\win32\networkio.h # End Source File # Begin Source File Index: network_io/unix/inet_pton.c === RCS file: /home/cvspublic/apr/network_io/unix/inet_pton.c,v retrieving revision 1.4 diff -u -r1.4 inet_pton.c --- network_io/unix/inet_pton.c 2001/03/07 17:41:37 1.4 +++ network_io/unix/inet_pton.c 2001/03/15 23:32:40 @@ -48,6 +48,10 @@ #define __P(x) x #endif +#if !defined(EAFNOSUPPORT) defined(WSAEAFNOSUPPORT) +#define EAFNOSUPPORT WSAEAFNOSUPPORT +#endif + /* * WARNING: Don't even consider trying to compile this on a system where * sizeof(int) 4. sizeof(int) 4 is fine; all the world's not a VAX. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Problem Build Latest Win32 CVS Release
Ian Holsman [EMAIL PROTECTED] writes: It compiles OK. I've got 2 other issues the build at the moment Creating library Debug/libhttpd.lib and object Debug/libhttpd.exp mod_access.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] mod_access.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] oops... the darn .def file... I'm getting my windows machine up to date now and will work on it shortly... and the include path of the xml project doesn't reference the ./expat/lib directory in it's include path, but the expat-lite directory which is now empty. I'll see what I can do... I'm pretty clumsy with the project files. 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: Problem Build Latest Win32 CVS Release
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Many comments on several posts Creating library Debug/libhttpd.lib and object Debug/libhttpd.exp mod_access.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] mod_access.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] oops... the darn .def file... I'm getting my windows machine up to date now and will work on it shortly... No def files... please properly APR_DECLARE(rettype) apr_fn(args) always and this doesn't become a problem again, ever. hmmm... it was done properly to start with... I don't know why Ian was getting this error Index: apr.dsp === RCS file: /home/cvspublic/apr/apr.dsp,v retrieving revision 1.66 diff -u -r1.66 apr.dsp --- apr.dsp 2001/02/03 16:31:07 1.66 +++ apr.dsp 2001/03/15 23:32:36 @@ -267,6 +267,10 @@ # End Source File # Begin Source File +SOURCE=.\network_io\unix\inet_pton.c +# End Source File +# Begin Source File + PLEASE please (pretty please) remember to keep apr/libapr .dsp files in sync. While it's a pain, its easier than having to keep those .def files up to date ;-) found that out too :) done... Index: network_io/unix/inet_pton.c === RCS file: /home/cvspublic/apr/network_io/unix/inet_pton.c,v retrieving revision 1.4 diff -u -r1.4 inet_pton.c --- network_io/unix/inet_pton.c 2001/03/07 17:41:37 1.4 +++ network_io/unix/inet_pton.c 2001/03/15 23:32:40 @@ -48,6 +48,10 @@ #define __P(x) x #endif +#if !defined(EAFNOSUPPORT) defined(WSAEAFNOSUPPORT) +#define EAFNOSUPPORT WSAEAFNOSUPPORT +#endif + This needs to be APR_EAFNOSUPPORT and a status test, _please_ fix this in the canonical errors header! Then the APR_STATUS_IS_EAFNOSUPPORT() on Win32 compares WSAEAFNOSUPPORT, and on OS2 it will do what OS2 does. not tonight... dead code anyway... maybe useful if EAFNOSUPPORT could be exposed to callers of APR Other than that, looks like you are all over this (as in... on top of it :-) not really... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: iconv problems
jean-frederic clere [EMAIL PROTECTED] writes: Hi, I have detected that iconv (iconv(), iconv_open() and iconv_close()) are not working as APR expects it on some platforms (BS2000 and ReliantUnix at least). Perhaps you can explain the difference in behavior? There are 2 ways of arranging the problem: 1 - Patch code where needed so that this iconv works correctly. 2 - Add apr_iconv(), apr_iconv_open() and apr_iconv_close() to APR. Either is possible, of course. We wouldn't export apr_iconv_* as formal APR APIs so the usefulness of such is lessened. This makes me wonder what the differences are, how much code is exposed to the difference, etc. What to do for platform that have not iconv at all? (Well is covered by HAVE_ICONV). APR cares about HAVE_ICONV... The APR app cares about APR_HAS_XLATE -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: disk i/o problems
Ben Collins-Sussman [EMAIL PROTECTED] writes: Jeff Trawick [EMAIL PROTECTED] writes: Ben Collins-Sussman [EMAIL PROTECTED] writes: Hi all -- I'm getting some weird disk slowdowns on FreeBSD 4.2. Did you by chance look at an strace/truss of your APR app on Linux and FreeBSD to see what APR is doing on your file? I used 'truss' during a subversion checkout and I saw nothing suspicious. But to be honest, I wouldn't know what wrongness would look like! I'm just not familiar enough with system calls. read() (or write() -- I don't know what operation you're doing) for small amounts... you'd want to get APR to read() big chunks, like 4K or 8K or similar... definitely not 10 bytes, then 123 bytes, then 80 bytes, etc. Are you using buffered APR file support? Huh? What? Please explain. On apr_file_open(), specify APR_BUFFERED. This causes the file I/O support to act like the C Standard Library stdio routines, in that it will minimize system calls. On the first read it grabs a bunch of data in one syscall, continues to service read operations from that bunch of data until exhausted, at which point it does another syscall. If the I/O isn't buffered, then your performance will be affected by . cost of system call . buffer cache (design and/or tuning and/or amount of real memory available) I can easily imagine that performance of an I/O-intensive program using non-buffered I/O could vary drastically between systems. If I can't figure out what's going on, maybe I can show people the problem next week at the Hackathon... No problem... I'll be the one trying to find a place to plug in my ethernet cable. -- 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-util/xml/expat configure.in
[EMAIL PROTECTED] writes: Modified:.configure.in xml/expat configure.in Log: Use aplibtool on OS/2. Index: configure.in === RCS file: /home/cvs/apr-util/configure.in,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- configure.in2001/03/09 14:02:45 1.14 +++ configure.in2001/03/29 15:53:24 1.15 @@ -39,7 +39,18 @@ dnl prep libtool dnl echo performing libtool configuration... -AC_PROG_LIBTOOL + +AC_CANONICAL_SYSTEM +case $host_alias in +*os2*) +# Use a custom made libtool replacement +echo using aplibtool +LIBTOOL=$APR_SOURCE_DIR/build/aplibtool +;; +*) +AC_PROG_LIBTOOL +;; +esac Same comment as before... just provide AC_PROG_LIBTOOL which does the right thing... 1.2 +12 -2 apr-util/xml/expat/configure.in Index: configure.in === RCS file: /home/cvs/apr-util/xml/expat/configure.in,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- configure.in2001/02/28 14:41:25 1.1 +++ configure.in2001/03/29 15:53:26 1.2 @@ -45,8 +45,18 @@ AC_CONFIG_HEADER(config.h) -AC_LIBTOOL_WIN32_DLL It seemed cleaner to me to provide an empty AC_LIBTOOL_WIN32_DLL macro than to change the expat build. -AC_PROG_LIBTOOL +AC_CANONICAL_SYSTEM +case $host_alias in +*os2*) +# Use a custom made libtool replacement +echo Using aplibtool +LIBTOOL=$srcdir/../../../apr/build/aplibtool +;; +*) +AC_LIBTOOL_WIN32_DLL +AC_PROG_LIBTOOL +;; +esac as before, do this in AC_PROG_LIBTOOL -- 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
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-util/xml/expat configure.in
Brian Havard [EMAIL PROTECTED] writes: On 29 Mar 2001 11:07:31 -0500, Jeff Trawick wrote: It seemed cleaner to me to provide an empty AC_LIBTOOL_WIN32_DLL macro than to change the expat build. Err, actually it's just moved, not removed, into the everything but OS/2 section (see below). It could probably have stayed where it was come to think of it. If it doesn't hurt on unix it probably won't hurt OS/2 either. I've no idea what it does though. I didn't say you removed it. I'm saying that the change and OS/2-specific path wasn't needed. My point is that you can (and IMHO should) minimize special-case logic in the apache/apr/expat/whatever build to deal with your libtool. What happens when your libtool is taught to handle another system? These same sections of build code have to be updated again. FYI... AC_LIBTOOL_WIN32_DLL certainly doesn't hurt on Unix. I have no idea what it does either, but an empty macro works fine for me on OS/390. -- 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
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/network_io/unix sendrecv.c sockets.c
[EMAIL PROTECTED] writes: trawick 01/03/31 05:25:46 Modified:include/arch/unix networkio.h network_io/unix sendrecv.c sockets.c Log: apr_recvfrom() should only return APR_EOF if recvfrom() returned zero *AND* this is a stream socket. rc zero from a datagram socket just means that somebody sent you a zero-byte datagram. Remove the minimal parm checking from recvfrom()... better to segfault as with most of the rest of APR. The same basic change is needed for other apr_recvfrom() implementation(s)... -- 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/network_io/unix sendrecv.c sockets.c
William A. Rowe, Jr. [EMAIL PROTECTED] writes: has anyone else been using apr/test/makefile.win? With success? I just used it the first time and quickly found an opportunity (run-time exception). Thanks for the perl. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Fw: cvs commit: apr/network_io/unix sendrecv.c sockets.c
William A. Rowe, Jr. [EMAIL PROTECTED] writes: The problems it identifies in implode/explode time, and the DSO anomilies I'll take a look at. I'll be adding the filepath suite to testfile. But I'll let some other taker attack the sockets and process stuff. Basically, several tests _live_ on the fork(), and that just isn't a way to go on Win32. Couple of hours to get them all working on win32 if someone wanted to attack. I have a few other windmills I'm tilting at before AC :-) testproc and client/server work for me on Win98 now. Something done by testsock isn't working... I haven't disentangled the messages from client/server (which should work) from the messages from sendfile (which is expected to fail on 98). It could just be the ./sendfile :) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: APR threads and FreeBSD
[EMAIL PROTECTED] writes: Could someone please tell me why APR_HAS_THREADS is false on FreeBSD? I have written pthreads based code on FreeBSD and Linux and they both seem to work well (I only have 1 cpu, so FreeBSDs limitation that each process runs on only 1 cpu at a time doesn't effect me). When configuring with --enable-threads APR compiles (however the rest of Apache will not), and the testthread test passes just fine, but the testsock test seems to fail. Without the --enable-threads APR compiles and the testsock works normally, of course testthread fails in this case with the predictable message This program won't work on this platform because there is no support for threads. What is the compile failure in Apache when you add --enable-threads? I don't think a compile failure is expected. Your observation about testsock illustrates some of the problems we've had with threads on FreeBSD. Neither testsock nor the programs it starts use threads, but you observed that building with thread support (linking with libc_r) broke it. Compiling APR + prefork MPM with thread support results in weird breakage and looping in libc_r. No threads were ever created. All I can say is that neither our threaded apps nor our unthreaded apps work properly when thread support is enabled on FreeBSD. I wish I had time/skills/gumption to resolve the problem, but alas that is not the case. For now, folks are better off with threads disabled on FreeBSD. Of course we'd be thrilled if some of the FreeBSD thread folks would use --enable-threads and see what is happening :) -- 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
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: resolver issues
jean-frederic clere [EMAIL PROTECTED] writes: Hi, I have some problems with PHP3 because of res_search, dn_skipname and dn_expand. My first idea was to search for apr_res_search, apr_dn_skipname and apr_dn_expand, but it did not help. Is there a place in APR for these resolver things? These resolver things bring with them a resolver in order to work on systems that don't have res_search() et al already. Ouch! -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_send() - how to flush to network?
Graham Leggett [EMAIL PROTECTED] writes: To send the HTTP/1.1 200 Connection Established the code uses apr_send() - but this data is never flushed, so it never sees the network (a sniff shows nothing over the wire). As a result the connections hangs there and the browser never responds. A couple of points... . apr_send() hands the data straight to the TCP/IP stack; it does not buffer data, so there is no need for apr_socket_flush() . if your APR socket has a timeout set or is non-blocking, apr_send() can write fewer bytes than you requested... check the output bytes-written status If no bytes are going to the wire, what is happening in the TCP layer? Can you use netstat to display info about the TCP connection? Maybe there are already bytes in the send buffer and the TCP stack can't accept any more because the other side isn't acknowledging bytes already sent? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
out for a while... apr/test builds broken :(
FYI... I'm about to leave for the airport and will be off-line until next weekend. apr/test builds are broken and I have no time to fix. I guess Justin and I are co-conspirators (but not 100% sure :) ). test]$ make make[1]: Entering directory `/home/trawick/apache/httpd-2.0/srclib/apr/test' /bin/sh /home/trawick/apache/httpd-2.0/srclib/apr/libtool --mode=compile --silent gcc -DLINUX=2 -D_REENTRANT -g -g -O2 -pthread -I../include -I../include -c client.c touch client.lo /bin/sh /home/trawick/apache/httpd-2.0/srclib/apr/libtool --mode=link --silent gcc -DLINUX=2 -D_REENTRANT -g -g -O2 -pthread -I../include -I../include -o client -rpath $objects client.lo ../libapr.la ../shmem/unix/mm/libmm.la -lm -lcrypt -lnsl -ldl libtool: link: only absolute run-paths are allowed make[1]: *** [client] Error 1 make[1]: Leaving directory `/home/trawick/apache/httpd-2.0/srclib/apr/test' make: *** [all-recursive] Error 1 -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_dso_handle_close ?
Greg Stein [EMAIL PROTECTED] writes: I'm sorry, but this is just feeling wrong. Perl opens these DSOs for me, but won't close them. I can't patch Perl to do it for me... lessee... oh! I can patch APR! Yah, that's it! I'm not comfortable with APR being a workaround for other problems. APR has a design: you build an apr_FOO_t and use that. We do have a notion of getting/setting a native FOO into those structures. yep... it is unfortunate that Perl doesn't have a way to close them but it is easy enough to solve outside of APR if the existing APR way to unnaturally (i.e., via apr_os_put|make_foo) is not deemed elegant enough -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_dso_handle_close ?
Doug MacEachern [EMAIL PROTECTED] writes: below is a complete patch to implement apr_dso_handle_close() the only cleanup that saved into apr_dso_handle_t was os390: dso-failing_errno = errno; which is pointless since that value is returned by the function and nothing was checking it anyways. the reason it is saved is because of the APR interface for getting an error string from a dso load error... you don't pass in the system-specific error value (e.g., errno on Unix) but instead you pass in the apr DSO handle... since strerror() is allowed to overlay the buffer containing the error string, we don't simply save the strerror() result but instead save the errno... as for why the APR interface is designed that way: some platforms have additional information available (beyond any sort of errno-like numeric value)... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
[PATCH] do auto-unregister of other child registration
This is mostly an APR patch but it fixes a symptom (segfault)
associated with mod_cgid after doing apachectl graceful followed by
apachectl restart.
I turned on Greg Stein's mprotect-based memory debugging to help test
it out.
Before, we were leaving registrations in the other_children list after
the pool from which the list element was allocated was destroyed.
With this patch, we use the normal APR auto-cleanup design ith the
other-child registration so that we don't leave the registration
dangling.
The cleanup is a bit hokey because of the API; because
apr_proc_other_child_unregister() is given a user data ptr instead of
an apr_foo_t, we have to search the private list of registrations to
find the pool with which the cleanup is associated.
With this patch it takes a couple of secs for mod_cgid to go away, so
maybe we should be doing an explicit unregister somewhere, but at
least the auto unregister seems to work.
I have pretty low confidence in my understanding of anything to do
with APR other-child code, so I look forward to being pointed in the
right direction.
Index: modules/generators/mod_cgid.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/generators/mod_cgid.c,v
retrieving revision 1.83
diff -u -r1.83 mod_cgid.c
--- modules/generators/mod_cgid.c 2001/04/03 19:12:14 1.83
+++ modules/generators/mod_cgid.c 2001/04/26 22:34:49
@@ -242,7 +242,7 @@
apr_proc_other_child_unregister(data);
break;
case APR_OC_REASON_UNREGISTER:
-apr_pool_destroy(pcgi);
+/* don't apr_pool_destroy(pcgi); its cleanup drives this path */
kill(*sd, SIGHUP);
break;
}
Index: srclib/apr/include/arch/unix/misc.h
===
RCS file: /home/cvspublic/apr/include/arch/unix/misc.h,v
retrieving revision 1.25
diff -u -r1.25 misc.h
--- srclib/apr/include/arch/unix/misc.h 2001/02/25 20:39:32 1.25
+++ srclib/apr/include/arch/unix/misc.h 2001/04/26 22:35:13
@@ -88,6 +88,7 @@
#endif
struct apr_other_child_rec_t {
+apr_pool_t *p;
struct apr_other_child_rec_t *next;
int id; /* This is either a pid or tid depending on the platform */
void (*maintenance) (int, void *, int);
Index: srclib/apr/misc/unix/otherchild.c
===
RCS file: /home/cvspublic/apr/misc/unix/otherchild.c,v
retrieving revision 1.20
diff -u -r1.20 otherchild.c
--- srclib/apr/misc/unix/otherchild.c 2001/02/16 04:15:56 1.20
+++ srclib/apr/misc/unix/otherchild.c 2001/04/26 22:35:17
@@ -71,6 +71,22 @@
static apr_other_child_rec_t *other_children = NULL;
+static apr_status_t other_child_cleanup(void *data)
+{
+apr_other_child_rec_t **pocr, *nocr;
+
+for (pocr = other_children; *pocr; pocr = (*pocr)-next) {
+if ((*pocr)-data == data) {
+nocr = (*pocr)-next;
+(*(*pocr)-maintenance) (APR_OC_REASON_UNREGISTER, (*pocr)-data,
-1);
+*pocr = nocr;
+/* XXX: um, well we've just wasted some space in pconf ? */
+return APR_SUCCESS;
+}
+}
+return APR_SUCCESS;
+}
+
APR_DECLARE(void) apr_proc_other_child_register(apr_proc_t *pid,
void (*maintenance) (int reason, void *, int status),
void *data, apr_file_t *write_fd, apr_pool_t *p)
@@ -78,6 +94,7 @@
apr_other_child_rec_t *ocr;
ocr = apr_palloc(p, sizeof(*ocr));
+ocr-p = p;
ocr-id = pid-pid;
ocr-maintenance = maintenance;
ocr-data = data;
@@ -89,21 +106,25 @@
}
ocr-next = other_children;
other_children = ocr;
+apr_pool_cleanup_register(p, ocr-data, other_child_cleanup,
+ apr_pool_cleanup_null);
}
APR_DECLARE(void) apr_proc_other_child_unregister(void *data)
{
-apr_other_child_rec_t **pocr, *nocr;
+apr_other_child_rec_t *cur;
-for (pocr = other_children; *pocr; pocr = (*pocr)-next) {
-if ((*pocr)-data == data) {
-nocr = (*pocr)-next;
-(*(*pocr)-maintenance) (APR_OC_REASON_UNREGISTER, (*pocr)-data,
-1);
-*pocr = nocr;
-/* XXX: um, well we've just wasted some space in pconf ? */
-return;
+cur = other_children;
+while (cur) {
+if (cur-data == data) {
+break;
}
+cur = cur-next;
}
+
+/* segfault if this function called with invalid parm */
+apr_pool_cleanup_kill(cur-p, cur-data, other_child_cleanup);
+other_child_cleanup(data);
}
/* test to ensure that the write_fds are all still writable, otherwise
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: os-unixware/7651: compilation of srclib/apr/network_io/unix/sa_common.c fails
Help me out here... I don't follow your comments. William A. Rowe, Jr. [EMAIL PROTECTED] writes: Jeff, this is the wrong solution (and it was anticipated). Since win32 and OS2 don't need the unix MPM's they were never fixed, apparently (from this report) they must be. what is the connection between unix MPM and this code? Do you mean unix build of APR? We can't go munging system symbols, see the declarations in apr_errno.h for the apr_get_netos_error() (and if we need it, we could implement an apr_set_netos_error() although it may not enjoy cross-platform support!) What does munging system symbols mean? apr_get/set_netos_error() is not sufficient. For Unix that needs to deal with errno. This is h_errno. Patch the apr core and mpms to adopt this call instead of h_errno and implement your solution in terms of declaring apr_get_netos_error() and the problem should go away. can't do because of the errno/h_errno issue... ---/--- Note that this path is only used on systems with getnameinfo() and IPv6 support. The h_errno kludge helps out with some getnameinfo() issues on common versions of glibc. Before we truly clean up this code we need to understand what is needed to operate with getnameinfo() across a variety of systems. Hopefully the h_errno stuff can then be hidden inside ifdef GETNAMEINFO_SETS_H_ERRNO and any non-Unix platforms which later add getnameinfo() support won't be hurt by the kludge since it won't be set. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
