--On Wednesday, July 7, 2004 7:40 AM + [EMAIL PROTECTED] wrote:
jorton 2004/07/07 00:40:12
Modified:poll/unix poll.c
.configure.in
Log:
* poll/unix/poll.c (backend_cleanup): Only define if using epoll/kqueue.
(apr_pollset_destroy): Only run cleanup if
On Thu, Jul 08, 2004 at 12:04:48AM -0700, Justin Erenkrantz wrote:
--On Wednesday, July 7, 2004 7:40 AM + [EMAIL PROTECTED] wrote:
jorton 2004/07/07 00:40:12
Modified:poll/unix poll.c
.configure.in
Log:
* poll/unix/poll.c (backend_cleanup): Only
jorton 2004/06/30 06:16:54
Modified:.configure.in config.layout
Log:
* configure.in, config.layout: Add -version suffix to default
installbuilddir directory.
Revision ChangesPath
1.593 +1 -1 apr/configure.in
This looks like a change that
On Tue, Jun 29, 2004 at 02:10:48PM -, [EMAIL PROTECTED] wrote:
--- configure.in14 Jun 2004 21:16:40 - 1.589
+++ configure.in29 Jun 2004 14:10:48 - 1.590
@@ -522,6 +522,8 @@
AC_SEARCH_LIBS(gethostbyname, nsl)
AC_SEARCH_LIBS(gethostname, nsl)
[EMAIL PROTECTED] wrote:
jorton 2004/01/29 00:33:41
Modified:.Tag: APR_0_9_BRANCH configure.in CHANGES
Log:
* configure.in: Define apr_off_t as an apr_intX_t type rather than
off_t to prevent the size of apr_off_t being affected by the
_FILE_OFFSET_BITS definition on LFS
On Thu, Jan 29, 2004 at 08:44:07AM -0500, Jeff Trawick wrote:
APR_INT32_T_FMT isn't showing up in apr.h for me, leading to compile
failure for references to APR_OFF_T_FMT
Sorry, fixed now.
On Mon, Dec 08, 2003 at 11:20:25PM -, Greg Ames wrote:
gregames2003/12/08 15:20:25
Modified:.configure.in
Log:
allow non-portable atomics on Linux/ppc
BTW, is this new asm really non-portable, or would it work on any
Linux ppc64 boxes?
joe
Aaron Bannert wrote:
On Nov 6, 2003, at 8:55 AM, Joe Orton wrote:
On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote:
What is this and the APR_IS_BIGENDIAN macro used for? Do we have
any code that is endian-dependent?
$ grep -l -r --include \*.c APR_IS_BIGENDIAN .
[EMAIL PROTECTED] wrote:
jorton 2003/11/06 01:18:22
Modified:.configure.in
Log:
* configure.in: Fix endianness detection with autoconf 2.1x.
Speaking of autoconf, I get this every time:
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and
What is this and the APR_IS_BIGENDIAN macro used for? Do we have
any code that is endian-dependent?
-aaron
On Thu, Nov 06, 2003 at 09:18:23AM -, [EMAIL PROTECTED] wrote:
jorton 2003/11/06 01:18:22
Modified:.configure.in
Log:
* configure.in: Fix endianness
On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote:
What is this and the APR_IS_BIGENDIAN macro used for? Do we have
any code that is endian-dependent?
$ grep -l -r --include \*.c APR_IS_BIGENDIAN .
./random/unix/sha2.c
On Thu, Nov 06, 2003 at 09:18:23AM -, [EMAIL PROTECTED]
On Nov 6, 2003, at 8:55 AM, Joe Orton wrote:
On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote:
What is this and the APR_IS_BIGENDIAN macro used for? Do we have
any code that is endian-dependent?
$ grep -l -r --include \*.c APR_IS_BIGENDIAN .
./random/unix/sha2.c
Ah, I didn't pick up
On Mon, Sep 29, 2003 at 02:20:02PM -, [EMAIL PROTECTED] wrote:
...
$(TARGET_LIB):
@for i in $(SUBDIRS); do objects=$$objects $$i/[EMAIL PROTECTED]@;
done ; \
- tmpcmd=$(LINK) @lib_target@ @lib_target_libs@; \
+ tmpcmd=$(LINK) @lib_target@ $(ALL_LIBS); \
--On Friday, August 29, 2003 10:26 AM +0100 Colm MacCarthaigh
[EMAIL PROTECTED] wrote:
Is that a real DNS server, or lookupd ? Am I right in thinking
lookupd is more or less what everone else calls nscd?
It's going to a real DNS server. And, yes, AIUI, lookupd is essentially nscd.
(Although, I
On Sun, Aug 31, 2003 at 09:34:46AM -0700, Justin Erenkrantz wrote:
Nope :) DNS servers don't even understand IPv4 addresses in that
sense, you can't query a DNS server saying give me the reverse
of this IPv4 addresss, your resolver has to turn 209.237.227.195
into 195.227.237.209.in-addr.arpa
--On Thursday, August 28, 2003 10:54 AM +0100 Colm MacCarthaigh
[EMAIL PROTECTED] wrote:
If gni_mapped worked for you then something is definitely different
anyway.
Well, I did some more tracing of what's going on.
Darwin's getnameinfo() isn't handling the IPv6-IPv4 mapping, so it is sending
On Thu, Aug 28, 2003 at 09:56:14PM -0700, Justin Erenkrantz wrote:
--On Thursday, August 28, 2003 10:54 AM +0100 Colm MacCarthaigh
[EMAIL PROTECTED] wrote:
If gni_mapped worked for you then something is definitely different
anyway.
Well, I did some more tracing of what's going on.
--On Tuesday, August 26, 2003 6:56 AM -0400 Jeff Trawick
[EMAIL PROTECTED] wrote:
Yeah, that looks reasonable :) I'm still curious about what was happening
on Justin's system.
No clue, either. =) I very well may have gotten what was working mixed up,
sorry.
What I do know is that host-based
Justin Erenkrantz [EMAIL PROTECTED] writes:
--On Tuesday, August 26, 2003 6:56 AM -0400 Jeff Trawick
[EMAIL PROTECTED] wrote:
Yeah, that looks reasonable :) I'm still curious about what was happening
on Justin's system.
No clue, either. =) I very well may have gotten what was
On Wed, Aug 27, 2003 at 09:13:03PM -0700, Justin Erenkrantz wrote:
Yeah, that looks reasonable :) I'm still curious about what was happening
on Justin's system.
No clue, either. =) I very well may have gotten what was working mixed
up, sorry.
If gni_mapped worked for you then something
Colm MacCarthaigh wrote:
On Mon, Aug 25, 2003 at 12:59:42PM -0400, Jeff Trawick wrote:
So what do you get on your system? I must be missing some OS X fix...
(But this box is running straight Jaguar with all available updates from
Software Update installed.)
This is what my darwin-using friends
On Mon, Aug 25, 2003 at 01:54:19PM -0400, Jeff Trawick wrote:
--- gni_mapped.c Sat Feb 15 00:18:30 2003
+++ gni_mapped2.cMon Aug 25 17:40:15 2003
@@ -37,8 +37,10 @@
rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof
hostbuf, NULL, 0, 0);
printf(look
Colm MacCarthaigh wrote:
-rc = getnameinfo((struct sockaddr *)sin6, sizeof sin6, hostbuf,
sizeof hostbuf, NULL, 0, NI_NAMEREQD);
+rc = getnameinfo((struct sockaddr *)sin, sizeof sin, hostbuf, sizeof
hostbuf, NULL, 0, 0);
printf(look up via IPv6: %d/%s\n, rc, hostbuf);
Hmmm, that
[EMAIL PROTECTED] wrote:
jerenkrantz2003/08/24 16:09:19
Modified:.configure.in CHANGES
Log:
Re-enable IPv6 on Darwin 6.6 and beyond as it looks like getaddrinfo() now
works with IPv4-mapped addresses.
IIRC getnameinfo() was the problem, not getaddrinfo().
With 6.6 kernel
--On Monday, August 25, 2003 12:40:47 -0400 Jeff Trawick
[EMAIL PROTECTED] wrote:
IIRC getnameinfo() was the problem, not getaddrinfo().
With 6.6 kernel (and whatever else Jaguar+latest updates gets you),
http://www.apache.org/~trawick/gni_mapped.c still fails for me. (This
supposedly means
Justin Erenkrantz wrote:
--On Monday, August 25, 2003 12:40:47 -0400 Jeff Trawick
[EMAIL PROTECTED] wrote:
IIRC getnameinfo() was the problem, not getaddrinfo().
With 6.6 kernel (and whatever else Jaguar+latest updates gets you),
http://www.apache.org/~trawick/gni_mapped.c still fails for me.
On Mon, Aug 25, 2003 at 12:59:42PM -0400, Jeff Trawick wrote:
So what do you get on your system? I must be missing some OS X fix...
(But this box is running straight Jaguar with all available updates from
Software Update installed.)
This is what my darwin-using friends have been telling me
So what do you get on your system? I must be missing some OS X fix...
(But this box is running straight Jaguar with all available updates from
Software Update installed.)
My laptop, running straight Jaguar plus all available fixes:
[EMAIL PROTECTED] gni $ ./gni_mapped
look up via IPv4:
At 05:13 PM 3/18/2003, Branko Čibej wrote:
[EMAIL PROTECTED] wrote:
brane 2003/03/18 15:10:15
Modified:include apr.hw apr.hnw apr.h.in
.configure.in CHANGES
Log:
Define a printf format and format length for apr_uint64_t.
Also define APR_INT64_T_FMT_LEN
[EMAIL PROTECTED] wrote:
brane 2003/03/18 15:10:15
Modified:include apr.hw apr.hnw apr.h.in
.configure.in CHANGES
Log:
Define a printf format and format length for apr_uint64_t.
Also define APR_INT64_T_FMT_LEN on Windows and Netware; Unix already
On Fri, Jun 14, 2002 at 01:24:02AM -, [EMAIL PROTECTED] wrote:
aaron 2002/06/13 18:24:02
Modified:.configure.in CHANGES
Log:
Removed --disable-atomics flag and added --enable-nonportable-atomics,
thereby defaulting to portable binaries on those systems that
On Mon, Jun 10, 2002 at 06:51:13PM -, [EMAIL PROTECTED] wrote:
rbb 2002/06/10 11:51:13
Modified:.configure.in
Log:
It helps to document the actual option. :-)
Revision ChangesPath
1.452 +1 -1 apr/configure.in
Index: configure.in
From: Aaron Bannert [mailto:[EMAIL PROTECTED]
On Mon, Jun 10, 2002 at 06:51:13PM -, [EMAIL PROTECTED] wrote:
rbb 2002/06/10 11:51:13
Modified:.configure.in
Log:
It helps to document the actual option. :-)
Revision ChangesPath
1.452
On Tue, Apr 30, 2002 at 11:49:41PM -, Justin Erenkrantz wrote:
jerenkrantz02/04/30 16:49:41
Modified:.configure.in
Log:
Add --disable-atomics flag which will prevent APR from using its *own*
optimized code. On those OSes that properly support atomics from
On Sun, Apr 28, 2002 at 07:49:34AM -, Justin Erenkrantz wrote:
jerenkrantz02/04/28 00:49:34
Modified:.configure.in CHANGES
Log:
Not all platforms can mmap /dev/zero, so we need to do an explicit check
for that. If that were to fail, then make it appear as
On Wed, May 01, 2002 at 10:56:10AM -0700, Aaron Bannert wrote:
Since this doesn't really disable the atomics, please rename
it. Something like --disable-optimized-atomics, or how about
--enable-nonportable-atomics.
No one came up with a patch to do it after lots of discussion about
it. If you
On Wed, May 01, 2002 at 11:01:47AM -0700, Aaron Bannert wrote:
Sorry for the late reply. Do we have a HAVE_DEV_ZERO-like define
somewhere, and if so would this mean that an OS that had /dev/zero but
didn't support mmap(/dev/zero) would not have that defined anymore? Other
than that I think
On Sun, Apr 28, 2002 at 07:49:34AM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/04/28 00:49:34
Modified:.configure.in CHANGES
Log:
Not all platforms can mmap /dev/zero, so we need to do an explicit check
for that. If that were to fail, then make it appear as
On Fri, Mar 22, 2002 at 05:21:22PM -0500, Jeff Trawick wrote:
If backtraces posted by users to our mailing lists and our bug
databases will be even a little easier to look at, then I am strongly
in favor of keeping the -g as a default. If somebody is worried about
that amount of space then
[EMAIL PROTECTED] wrote:
gregames02/03/22 13:41:47
Modified:.configure.in
Log:
get rid of the -g compiler flag on OS/390, unless this is a debug or
maintainer mode build.
Does anyone have a problem with doing the same on all platforms? I will commit
such a fix
On Fri, Mar 22, 2002 at 05:05:46PM -0500, Greg Ames wrote:
[EMAIL PROTECTED] wrote:
gregames02/03/22 13:41:47
Modified:.configure.in
Log:
get rid of the -g compiler flag on OS/390, unless this is a debug or
maintainer mode build.
Does anyone have a
Greg Ames [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
gregames02/03/22 13:41:47
Modified:.configure.in
Log:
get rid of the -g compiler flag on OS/390, unless this is a debug or
maintainer mode build.
Does anyone have a problem with doing the same
Jeff Trawick wrote:
If backtraces posted by users to our mailing lists and our bug
databases will be even a little easier to look at, then I am strongly
in favor of keeping the -g as a default. If somebody is worried about
that amount of space then let them strip the executable files.
Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
gregames02/02/15 14:36:40
Modified:buildapr_hints.m4
.configure.in
Log:
provide APR_CC_HINTS. This allows us to specify a default compiler
which the user can override externally (i.e., the
[EMAIL PROTECTED] writes:
gregames02/02/15 14:36:40
Modified:buildapr_hints.m4
.configure.in
Log:
provide APR_CC_HINTS. This allows us to specify a default compiler
which the user can override externally (i.e., the compiler choice isn't
On Mon, Jul 30, 2001 at 05:31:54PM -, [EMAIL PROTECTED] wrote:
trawick 01/07/30 10:31:54
Modified:.configure.in
Log:
if your system has pthread_mutexattr_setrobust_np()* we'll use it, but
we shouldn't require it in order to support cross process pthread mutexes
On 27 Jul 2001 10:22:04 -, [EMAIL PROTECTED] wrote:
dreid 01/07/27 03:22:04
Modified:.configure.in Makefile.in
Log:
Neither beos or OS/2 has any subdirs that need installing, so the commit
that added INSTALL_SUBDIRS broke the build. I couldn't find a way of getting
On Mon, Jul 02, 2001 at 04:23:49PM -, [EMAIL PROTECTED] wrote:
jerenkrantz01/07/02 09:23:49
Modified:.configure.in
Log:
fcntl() should be our preference for the short-term.
Our support of pthread_mutex_t needs more work before we can make it
the default (if
[EMAIL PROTECTED] writes:
jerenkrantz01/05/31 19:58:32
Modified:.configure.in
Log:
Detect the wacky Linux-specific condition where pthread_rwlock_init is
defined, but the declaration of pthread_rwlock_t requires extra
#defines.
this is glibc-specific, not
On Saturday, April 7, 2001, at 07:31 AM, Jeff Trawick wrote:
But APR_FLAG_HEADERS() can't handle that header file because the
variable name it generates is invalid. We're getting this on stderr
from configure:
/home/trawick/apache/httpd-2.0/srclib/apr/configure: mach-o_dyldh=0:
command not found
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
On 29 Mar 2001 11:17:32 -0500, Jeff Trawick wrote:
Brian Havard [EMAIL PROTECTED] writes:
On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote:
The way I do this in my libtool emulator is to provide an
AC_PROG_LIBTOOL macro in my libtool.m4 to set up the LIBTOOL
variable. (I compile my .c at
On 29 Mar 2001 20:45:28 -0500, Jeff Trawick wrote:
Brian Havard [EMAIL PROTECTED] writes:
On 29 Mar 2001 11:17:32 -0500, Jeff Trawick wrote:
Brian Havard [EMAIL PROTECTED] writes:
On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote:
The way I do this in my libtool emulator is to
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
[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
On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
Index: configure.in
===
RCS file: /home/cvs/apr/configure.in,v
retrieving revision 1.262
retrieving revision 1.263
diff -u -r1.262
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).
[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
Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
jim 01/02/26 11:56:14
Modified:.configure.in
Log:
Use APR_CHECK_HEADERS instead
One of these commits seems to have broken every case where we
previously checked for the header but didn't set a flag.
Greg Stein wrote:
I'm not seeing that, since we're reducing down to AC_CHECK_HEADERS.
Let me double check... I'm seeing correct stuff under FreeBSD and A/UX.
Well, yah. I fixed it :-)
I meant before :) Basically we were just doing:
for i in $stuff
do
On Tue, Feb 27, 2001 at 03:24:29PM -, [EMAIL PROTECTED] wrote:
jim 01/02/27 07:24:28
Modified:.configure.in
Log:
revert back to old way until we figure out
an autoheader work-around. Allow building again
What the hell?!!!
I spent something like six hours to
Greg Stein wrote:
On Tue, Feb 27, 2001 at 03:24:29PM -, [EMAIL PROTECTED] wrote:
jim 01/02/27 07:24:28
Modified:.configure.in
Log:
revert back to old way until we figure out
an autoheader work-around. Allow building again
What the hell?!!!
I
[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
Any interest in my adding something like AC_CHECK_HEADERS_FLAG
which implements the below:
AC_CHECK_HEADERS(sys/signal.h, sys_signalh=1, sys_signalh=0)
AC_CHECK_HEADERS_FLAG(sys/signal.h, sys_signalh)
we seem to use this construct enough...
--
On Mon, 26 Feb 2001, Jim Jagielski wrote:
Any interest in my adding something like AC_CHECK_HEADERS_FLAG
which implements the below:
AC_CHECK_HEADERS(sys/signal.h, sys_signalh=1, sys_signalh=0)
AC_CHECK_HEADERS_FLAG(sys/signal.h, sys_signalh)
we seem to use this construct
[EMAIL PROTECTED] wrote:
jim 01/02/26 11:56:14
Modified:.configure.in
Log:
Use APR_CHECK_HEADERS instead
Before I go any further, I want to rethink the name. Maybe APR_FLAG_HEADERS
(want to avoid confusion here) or APR_HEADERS_SET. Suggestions
welcome.
--
On Mon, 26 Feb 2001, Jim Jagielski wrote:
Use APR_CHECK_HEADERS instead
Before I go any further, I want to rethink the name. Maybe APR_FLAG_HEADERS
(want to avoid confusion here) or APR_HEADERS_SET. Suggestions
welcome.
APR_CHECK_HEADERS doesn't bother me... it makes it clear that
Cliff Woolley wrote:
It also wouldn't hurt my feelings any if APR_CHECK_HEADERS automagically
determined the variable name to flag with a 1 or a 0 by doing basically
this
s/\//_/g;
s/\.//g;
on the header name. Hence sys/sendfile.h becomes the flag variable
sys_sendfileh
[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.
On 21 Feb 2001, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
martin 01/02/21 07:51:43
Modified:include apr_general.h
file_io/unix Makefile.in
.configure.in
Added: file_io/unix mktemp.c
Log:
Add mktemp() and mkstemp()
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
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
On Thu, Feb 08, 2001 at 07:56:14PM -0500, Jeff Trawick wrote:
Greg Stein [EMAIL PROTECTED] writes:
On Thu, Feb 08, 2001 at 10:12:28PM -, [EMAIL PROTECTED] wrote:
trawick 01/02/08 14:12:28
Modified:.configure.in
Log:
look in -lm for modf()
Unless GCC defines __GLIBC__ (which it should not do), I
don't see any way how this expression can evaluate to false.
GCC doesn't define __GLIBC__, glibc header files do
Don't worry, that was a sort-of rhetorical statement. =)
I expected the AC_EGREP_HEADER macro to do
On 5 Jan 2001 [EMAIL PROTECTED] wrote:
rbb 01/01/05 09:19:57
Modified:.configure.in
Log:
Some Linux's do not define TCP_CORK.
I guess you are referring to libc 5.x.x systems? There are
still kernels around (2.0.x, early 2.2.x possibly) which
don't
Some Linux's do not define TCP_CORK.
I guess you are referring to libc 5.x.x systems? There are
still kernels around (2.0.x, early 2.2.x possibly) which
don't support TCP_CORK, so I think we should not simply
presume that TCP_CORK works.
Would anyone mind, if the
On Fri, 5 Jan 2001 [EMAIL PROTECTED] wrote:
Some Linux's do not define TCP_CORK.
I guess you are referring to libc 5.x.x systems? There are
still kernels around (2.0.x, early 2.2.x possibly) which
don't support TCP_CORK, so I think we should not simply
presume
It's false on Mandrake 7.1 too. I am in the middle of testing a patch
that just looks for sendfile. I think that is the safest way to code
this.
Yeah, instead of curing the problem the Right Way, we just
work around it by relying on well-established assumptions.
Great solution.
It's false on Mandrake 7.1 too. I am in the middle of testing a patch
that just looks for sendfile. I think that is the safest way to code
this.
Yeah, instead of curing the problem the Right Way, we just
work around it by relying on well-established assumptions.
Great
79 matches
Mail list logo
