[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Possible explanation for automake error on getloadavg.c
From: |
John Cronin |
Subject: |
Possible explanation for automake error on getloadavg.c |
Date: |
Thu, 12 Sep 2002 14:35:10 +0100 |
I post this here primarily because I'm not on the main make list, but also it
seems that it is a problem that has surfaced because of make's support for other
systems (e.g. w32).
Upon checking the autoconf manual, I see:
AC_FUNC_GETLOADAVG Macro
Check how to get the system load averages. If the system has the getloadavg
function, define HAVE_GETLOADAVG, and set GETLOADAVG_LIBS to any libraries
needed to get that function. Also add GETLOADAVG_LIBS to LIBS.
Otherwise, require an AC_LIBOBJ replacement (getloadavg.c) of getloadavg, and
possibly define several other C preprocessor macros and output variables:
1. Define C_GETLOADAVG.
2. Define SVR4, DGUX, UMAX, or UMAX4_3 if on those systems.
3. If nlist.h is found, define NLIST_STRUCT.
4. If struct nlist has an n_un.n_name member, define
HAVE_STRUCT_NLIST_N_UN_N_NAME. The obsolete symbol NLIST_NAME_UNION is still
defined, but do not depend upon it.
5. Programs may need to be installed setgid (or setuid) for getloadavg to work.
In this case, define GETLOADAVG_PRIVILEGED, set the output variable NEED_SETGID
to true (and otherwise to false), and set KMEM_GROUP to the name of the group
that should own the installed program.
Now AC_FUNC_GETLOADAVG is checked in configure.in. If it doesn't find a
'getloadavg function', it REQUIRES the presence of a getloadavg.c in the
sources. As automake doesn't know whether this test will pass or fail, it
thinks that it COULD still be added to LIBOBJS, and therefore specifying it
explicitly in loadavg_SOURCES results in an error, as it could already be
defined (automatically discovered).
Now on most unix systems, this is not a problem, as they have getloadavg, but if
getloadavg() _isn't_ there, getloadavg.c in the make distribution could
conceivably be linked twice.
I propose the solution of:
If getloadavg() isn't found, the test program is useless. The system 'uptime'
would surely use getloadavg, which isn't there, so it wouldn't work, so there is
nothing to check it against. Therefore, going back to the autoconf manual, we
see if getloadavg() isn't there, it defines C_GETLOADAVG. Thus check after if
it _is_ defined, and don't compile the test program. This would prevent the
double linking of getloadavg.c.
Make a copy of getloadavg.c to, say mgetloadavg.c, and use this in
loadavg_SOURCES. Then AC_FUNC_GETLOADAVG won't complain, as it still has a
getloadavg.c (even though it will never be compiled for loadavg, but it still
would be for make, so it must stay up to date (I assume it is used in make?)),
and mgetloadavg.c won't be automatically included in loadavg, so no error there
either.
Your input would be much appreciated.
John.
- Possible explanation for automake error on getloadavg.c,
John Cronin <=