RLIM_NLIMITS compile problem

RLIM_NLIMITS compile problem

[Adam Spiers]

Hi all,

I'm still here - just taking it easy on the computer front at the
moment, as it was sapping too much of my time.  I'm having problems
compiling the latest CVS tree:

  make[2]: Entering directory `/mnt/hda7/opt/zsh/Src'
  gcc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2  -o builtin.o builtin.c
  In file included from zsh.mdh:26,
                   from builtin.c:30:
  exec.epro:25: `RLIM_NLIMITS' undeclared here (not in a function)
  exec.epro:26: `RLIM_NLIMITS' undeclared here (not in a function)
  make[2]: *** [builtin.o] Error 1
  make[2]: Leaving directory `/mnt/hda7/opt/zsh/Src'
  make[1]: *** [modobjs] Error 2
  make[1]: Leaving directory `/mnt/hda7/opt/zsh/Src'
  make: *** [all] Error 1

Not sure whether I'm being stupid or just rusty, but I can't figure
out where @RLIMITS_INC_H@ is supposed to get #included for this (if
indeed it is @RLIMITS_INC_H@ - maybe I even got that wrong).
config.status has:

  s%@RLIMITS_INC_H@%/usr/include/asm/resource.h%g

which looks right to me.

Re: RLIM_NLIMITS compile problem

[Bart Schaefer]

On Feb 8, 11:48pm, Adam Spiers wrote:
} Subject: RLIM_NLIMITS compile problem
}
}   exec.epro:25: `RLIM_NLIMITS' undeclared here (not in a function)
}   exec.epro:26: `RLIM_NLIMITS' undeclared here (not in a function)
} 
} Not sure whether I'm being stupid or just rusty, but I can't figure
} out where @RLIMITS_INC_H@ is supposed to get #included for this (if
} indeed it is @RLIMITS_INC_H@ - maybe I even got that wrong).
} config.status has:
} 
}   s%@RLIMITS_INC_H@%/usr/include/asm/resource.h%g

@RLIMITS_INC_H@ is used only in Modules/Makefile.in, whence it comes
via rlimits.mdd.

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.

The actual mention of RLIM_NLIMITS in exec.epro began when Zefram put
in the "mod_export" keyword back in December and revised the way that
makepro.awk works.  However, I don't see how exec.c itself compiled
before if you're having problems with the .epro now; the trouble appears
to be that HAVE_GETRLIMIT assumes HAVE_SYS_RESOURCE_H, but that must
date from long ago (before I was keeping a CVS repository, at least).

The only other even remotely recent change is that configure.in now
looks at /usr/include/bits/resource.h in addition to all the other
places it used to look, but that's still from last November.

So I'm puzzled, but:  Zefram et al., what's the reason that those
HAVE_GETRLIMIT bits in exec.c were never moved to the rlimits module?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: RLIM_NLIMITS compile problem

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) 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

Re: RLIM_NLIMITS compile problem

[Zefram]

Bart Schaefer wrote:
>So I'm puzzled, but:  Zefram et al., what's the reason that those
>HAVE_GETRLIMIT bits in exec.c were never moved to the rlimits module?

Only the builtins were moved.  Looking at it, it appears that all the
resource limit handling code could reasonably be moved into the module,
using hooks, since if the limit-setting builtins are never used then
the limit setting is a no-op.

-zefram