httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: [BUILD] rlim_t now undefined ULTRIX
Date Thu, 17 Sep 1998 20:53:31 GMT
Ben Hyde wrote:
> 48 hours ago set_rlimit et. al. were not part of Ultrix story but
> today they are.  This diff might to be a useful part of the cascade
> that brought about this change.
>   % diff {old,new}/apache-1.3/src/include/ap_config_auto.h
>   35,36c35,36
>   < #ifdef HAVE_SYS_RESOURCE_H
>   < #undef HAVE_SYS_RESOURCE_H
>   ---
>   > #ifndef HAVE_SYS_RESOURCE_H
>   > #define HAVE_SYS_RESOURCE_H 1
> I've no idea what that means.
> rlim_t is defined by the usual technique, i.e. a hairball in
> ap_config.c.  It's setup by three (presumably disjoint mechnisms) (1)
> by inference on NEED_RLIM_T, (2) explicitly and hueristicly on some
> platforms, and finally (3) in a daunting conditional on the topic
> of GLIBC version.
> I'd rather somebody that pretends to a tiny bit of sympathy with this
> hairball decide what to do next.

Ahhh... I know what the problem is. See, the code, if it sees
sys/resource.h, then it assumes that it's OK to use the rlim_t
stuff. That's not totally true (for example, A/UX has this header
but SysV-type limiting). The fix is to go into ap_config.h and
add #undef HAVE_SYS_RESOURCE_H to the right code section for Ultrix.
Of course, what this does is avoids using rlimit stuff totally
with Ultrix, which seems to be the way it was before. Sound reasonable??

   Jim Jagielski   |||   |||
            "That's no ordinary rabbit... that's the most foul,
            cruel and bad-tempered rodent you ever laid eyes on"

View raw message