Re: RLIM_NLIMITS compile problem

[Adam Spiers <adam@xxxxxxxxxx>]

Bart Schaefer (schaefer@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> It appears that zsh expects to get RLIM_NLIMITS (possibly indirectly)
> from <sys/resource.h>, which is included by Src/system.h.  However, that
> depends on HAVE_SYS_RESOURCE_H being defined.

Took a while, but I figured it out.  HAVE_SYS_RESOURCE_H was not
getting defined in config.h by configure, because the test C program
configure was compiling had a warning about redefining RLIM_INFINITY.
Sounds like a Linux-specific problem, I thought.  Sure enough, a bit
of searching on dejanews revealed the following article:

http://x23.deja.com/[ST_rn=ps]/getdoc.xp?AN=561479526&CONTEXT=950132025.1817313343&hitnum=6

of which the following is a relevant quote:

-------- 8< -------- 8< --------
 glibc2 up to now includes <asm/resource.h> in bits/resource.h and
 defines RLIM_INFINITY later on, so when RLIM_INFINITY moved from
 linux/resource.h which glibc2 does not include to asm/resource.h,
 folks get warning about redefined RLIM_INFINITY. This will not be a
 problem with new getrlimit aware glibc, but with glibc's up to now it
 is a problem, because e.g. configure scripts will consider the
 warning as sign of sys/resource.h not being present on the
 system. With the following patch, which defines RLIM_INFINITY only if
 asm/resource.h has been included from linux/resource.h, even
 non-rlimit-changes aware glibc should continue to work just fine.
-------- 8< -------- 8< --------

My quick kludge fix was to add #ifndefs around the two conflicting
#defines of RLIM_INFINITY, then rm config.cache and rerun configure.
Thanks Bart for dropping some useful breadcrumbs.

Adam