Re: Bug in AC_FUNC_GETLOADAVG

[Paul D. Smith]

%% "Smith, Paul [BL60:430:EXCH]"<address@hidden> writes:

  sp> I'm using autoconf 2.53.
  sp> In the autoconf manual it says:

  sp>  - Macro: AC_FUNC_GETLOADAVG
  sp>     ...
  sp>        3. If `nlist.h' is found, define `NLIST_STRUCT'.
  sp>     ...

  sp> But, the autoconf macros do not do this.  They never define NLIST_STRUCT
  sp> to anything, ever.

Bleah.  This macro is really whacked, as is the getloadavg.c file
itself.

The above #define really means that an nlist.h exists, and it contains a
struct nlist, _and_ that the n_name field in the struct is a pointer
rather than an array.

So, I created this in my configure.in:

  # AC_FUNC_GETLOADAVG is documented to set the NLIST_STRUCT value, but it
  # doesn't.  So, we will.

  if test "$ac_cv_header_nlist_h" = yes; then
    AC_TRY_COMPILE([#include <nlist.h>],
        [struct nlist nl;
         nl.n_name = "string";
         return 0;],
        make_cv_nlist_struct=yes,
        make_cv_nlist_struct=no)
    if test "$make_cv_nlist_struct" = yes; then
      AC_DEFINE(NLIST_STRUCT, 1,
         [Define if struct nlist.n_name is a pointer rather than an array.])
    fi
  fi

That allows my test cross-compile (to QNX) to compile.  However, linking
fails because QNX doesn't have an nlist() function.

Looking at the getloadavg.c code I see that as long as the SVR4 macro is
set, we assume that we have either nlist or knlist() (unless we're on
SGI, sigh).

Looking at AC_FUNC_GETLOADAVG I see that we set SVR4 if we can find the
elf_begin() function in -lelf.

That, to me, seems like a pretty bogus test for SVR4, and checking for
SVR4 seems like a pretty bogus way to decide whether you have nlist() et.al.

-- 
-------------------------------------------------------------------------------
 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