Re: Bug in AC_FUNC_GETLOADAVG

[Paul D. Smith]

%% Paul Eggert <address@hidden> writes:

  pe> Yes.  I think the problem is that getloadavg.c predates autoconf,
  pe> so it uses a bunch of ad-hoc rules that really should be removed
  pe> and replaced with autoconf'ed versions.  But nobody has had the
  pe> time to do it "right".

Yeah.  Plus this load is really not even that useful to make; it takes
so long to register a change that you can start a whole boatload of jobs
before the load factor goes up enough to contain them.

  pe> Which getloadavg.c were you using?  The latest one I know of is in

The one in GNU make, of course :).

  pe> ftp://alpha.gnu.org/gnu/fetish/sh-utils-2.0.12.tar.gz

  pe> Does that sh-utils have a similar problem on QNX?

Yes, definitely.  QNX actually doesn't support _any_ method to retrieve
a historical load factor like that; the information simply isn't kept by
the microkernel.  On QNX you could determine the _current_ load
using a method they document, but it involves taking a measurement, then
sleeping for 1 second, then taking it again and comparing them.  I'm not
psyched about a method of figuring system load which takes over 1 second!
Perhaps the delay could be lessened and still yield useful results, though.

I fixed this problem by adding this to getloadavg.c, after the includes
but before much else:

  /* AC_FUNC_GETLOADAVG thinks QNX is SVR4, but it isn't. */
  # if defined(__QNX__)
  #  undef SVR4
  # endif

Obviously it would be better if all the individual functions
getloadavg.c were looking for were tested by autoconf, but the change
above does allow getloadavg.c to compile and link on QNX--it resolves to
a no-op of course.

It's a hack, but so is virtually everything else there.

  pe> To help remove some of the confusion, I have installed the following
  pe> patch to CVS autoconf.  This merges the sh-utils changes to
  pe> AC_FUNC_GETLOADAVG, and fixes the doc bug that you noted.  A lot of
  pe> work still remains in this area, thogh.  (If you want to volunteer, I
  pe> don't envy you ....)

Mmm.

I've been actually seriously considering stripping out all support for
load averages on systems where setgid permissions are required.  For
some apps, like sh-utils uptime, it's perfectly legitimate to install it
setgid if necessary.

For GNU make, however, it's a big problem: most kernels will strip out
any value of LD_LIBRARY_PATH when invoking programs that are setuid or
setgid (as they should).  This causes issues with a number of makefiles,
where compile commands, etc. are depending on this value.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist