--On Thursday, July 8, 2004 8:32 AM +0100 Joe Orton <[EMAIL PROTECTED]>
wrote:
Since we know the cleanup does nothing, defining it unnecessarily wastes
both a few bytes of code size and a few cycles at run-time. e.g. since
the cleanup is never registered for the non-epoll/kqueue case, running
apr
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_cl
--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 usi
> 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 chan
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)
>A
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.
[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 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_BIG
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 th
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]
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 de
[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:
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 Sun, Aug 31, 2003 at 06:46:51PM +0100, Colm MacCarthaigh wrote:
> The patch for sockaddr.c is great, works fine. The autoconf-fu
> needs some tweaks to work/compile :) ;
Gah. I just tossed the assert for now.
Thanks. -- justin
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-a
--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,
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 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
t
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 some
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 wha
--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-base
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 d
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);
> >
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
> So what do you get on your system? I must be missing some OS X fix...
> (But this box is running straight Jaguar with all available updates from
> Software Update installed.)
My laptop, running straight Jaguar plus all available fixes:
[EMAIL PROTECTED] gni $ ./gni_mapped
look up via IPv4: 0/w
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 m
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 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 th
[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 (an
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_IN
[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 Tue, Feb 11, 2003 at 08:51:26AM -0800, Justin Erenkrantz wrote:
> [ Resend from correct address... ]
>
> --On Tuesday, February 11, 2003 3:36 PM + [EMAIL PROTECTED] wrote:
>
> >jorton 2003/02/11 07:36:56
> >
> > Modified:.configure.in
> > Log:
> > Capitalize some "Posix
[ Resend from correct address... ]
--On Tuesday, February 11, 2003 3:36 PM + [EMAIL PROTECTED] wrote:
jorton 2003/02/11 07:36:56
Modified:.configure.in
Log:
Capitalize some "Posix"es and s/dnl/# a comment.
Why are you removing the dnl's? Comments should only be dnl not #
On 5 Aug 2002 [EMAIL PROTECTED] wrote:
> martin 2002/08/05 02:28:24
>
> Modified:.configure.in
> Log:
> Fix buggy substitution
>
> Revision ChangesPath
> 1.474 +2 -2 apr/configure.in
>
> Index: configure.in
>
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 tha
> 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
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: conf
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 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 y
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 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 u
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 /
Perfect.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
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
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.
>
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 w
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 any
[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
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 extern
[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 mute
On 27 Jul 2001 [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 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 ge
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
> this is glibc-specific, not Linux-specific, right?
Yes.
> Why are we turning on _BSD_SOURCE and _SVID_SOURCE here? What do they
> have to do with pthread_rwlock_t? Only _XOPEN_SOURCE=500 is needed
> for pthread_rwlock_t IIRC. _BSD_SOURCE is related to the combination
> of _XOPEN_SOURCE=
[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
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 no
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 a
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
[EMAIL PROTECTED] writes:
> wsanchez01/04/06 18:02:31
>
> Modified:.configure.in
> Log:
> Detect mach-o/dyld.h, which we'll need for DSO support on Darwin.
> --- configure.in2001/04/06 23:52:54 1.279
> +++ configure.in2001/04/07 01:02:31 1.280
> @@ -48
"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'
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
"Brian Havard" <[EMAIL PROTECTED]> writes:
> On 29 Mar 2001 11:17:32 -0500, Jeff Trawick wrote:
>
> >"Brian Havard" <[EMAIL PROTECTED]> writes:
> >
> >> On 29 Mar 2001 11:04:02 -0500, Jeff Trawick wrote:
> >>
> >> >The way I do this in my libtool emulator is to provide an
> >> >AC_PROG_LIBTOOL m
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. (
"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).
> >
> >C
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 -
[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
[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
On Tue, Feb 27, 2001 at 11:11:14AM -0500, Jim Jagielski wrote:
>...
> Yes, but we are doing:
>
> AC_CHECK_HEADERS($1)
>
> where $1 is what's passed to APR_FLAG_HEADERS, which autoheader isn't
> parsing correctly... What I've been seeing on all my test machines is that
> the HAVE_CTYPES_H, f
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 h
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 hou
Greg Stein wrote:
>
> >
> > I'm not seeing that, since we're reducing down to AC_CHECK_HEADERS.
> > Let me double check... I'm seeing correct stuff under FreeBSD and A/UX.
>
> Well, yah. I fixed it :-)
>
I meant before :) Basically we were just doing:
for i in $stuff
do
AC_CHECK_HE
On Tue, Feb 27, 2001 at 08:00:15AM -0500, Jim Jagielski wrote:
> 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 bro
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
[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 def
[EMAIL PROTECTED] wrote:
>
>
> I like APR_FLAG_HEADERS personally. I like the idea of having configure
> just detect the variable name, but that means documenting what the
> transformations are, and it keeps us from having control over the variable
> name, which I kind of dislike.
>
It also, h
I like APR_FLAG_HEADERS personally. I like the idea of having configure
just detect the variable name, but that means documenting what the
transformations are, and it keeps us from having control over the variable
name, which I kind of dislike.
Ryan
On Mon, 26 Feb 2001, Cliff Woolley wrote:
>
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"
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 clea
[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:
> 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 const
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...
--
[EMAIL PROTECTED] writes:
> rbb 01/02/26 08:44:39
>
> Modified:.configure.in
> Log:
> Fix the sendfile handling in APR. We have to subst the sys_sendfileh
> variable into apr.h.
Thanks... I have no explanation for why I left this off earlier.
(If my init process wa
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 mktem
[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 hav
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
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 res
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 autodet
> > 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
Sascha Schumann <[EMAIL PROTECTED]> writes:
> > Okay, what you committed looks nice but on RedHat 6.0 and RedHat 6.1
> > the AC_EGREP_HEADER doesn't find TCP_CORK in the kernel header file
> > because TCP_CORK is hidden by a check for the libc version.
>
> Hm, here it looks that way:
>
>
> > 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.
>
> 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 solutio
> > Okay, what you committed looks nice but on RedHat 6.0 and RedHat 6.1
> > the AC_EGREP_HEADER doesn't find TCP_CORK in the kernel header file
> > because TCP_CORK is hidden by a check for the libc version.
>
> Hm, here it looks that way:
>
> #if defined(__KERNEL__) || !defined(__GLIBC_
> Okay, what you committed looks nice but on RedHat 6.0 and RedHat 6.1
> the AC_EGREP_HEADER doesn't find TCP_CORK in the kernel header file
> because TCP_CORK is hidden by a check for the libc version.
Hm, here it looks that way:
#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC
Sascha Schumann <[EMAIL PROTECTED]> writes:
> 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
> st
> > > I guess you are referring to libc 5.x.x systems? There are
> > > still kernels around (2.0.x, early 2.2.x possibly) which
> > > don't support TCP_CORK, so I think we should not simply
> > > presume that TCP_CORK works.
> > >
> > > Would anyone mind, if the *linux* portio
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
> >
> > 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
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
1 - 100 of 101 matches
Mail list logo
