Re: Possible explanation for automake error on getloadavg.c

[Paul D. Smith]

%% "John Cronin" <address@hidden> writes:

  jc> Now AC_FUNC_GETLOADAVG is checked in configure.in.  If it doesn't
  jc> find a 'getloadavg function', it REQUIRES the presence of a
  jc> getloadavg.c in the sources.  As automake doesn't know whether
  jc> this test will pass or fail, it thinks that it COULD still be
  jc> added to LIBOBJS, and therefore specifying it explicitly in
  jc> loadavg_SOURCES results in an error, as it could already be
  jc> defined (automatically discovered).

Yes, I was looking at all this mess the other day as well.  The error is
kind of bogus because I don't put LIBOBJS into the LDADD for this
program, so in reality there is no way that you could get a conflict.
But, it is probably too hard for automake to realize this.


The problem is that I don't _want_ to put LIBOBJS into the
loadavg_LDADD.

The only one I want there is getloadavg.c, not every object that
configure found and decided to place into LIBOBJS.

  jc> Now on most unix systems, this is not a problem, as they have
  jc> getloadavg, but if getloadavg() _isn't_ there, getloadavg.c in the
  jc> make distribution could conceivably be linked twice.

Actually, many UNIX systems _DON'T_ have a getloadavg().  It's not at
all uncommon.

  jc> If getloadavg() isn't found, the test program is useless.

I'm not sure what you mean.  The whole point of the getloadavg.c file is
to emulate getloadavg() on systems which don't have it, so the test
program is _most_ useful on systems where getloadavg() isn't found, to
make sure that the emulation is working.

The test program is much less useful on systems where getloadavg() _is_
found: only to the extent that you don't trust the system getloadavg()
to work properly.

  jc> The system 'uptime' would surely use getloadavg, which isn't
  jc> there, so it wouldn't work, so there is nothing to check it
  jc> against.

??  Certainly uptime could still work; it would use some completely
different method of obtaining the system load.  There are many such
methods (that's why getloadavg.c is such a disgusting hairy bit of
code).

  jc> Therefore, going back to the autoconf manual, we see if
  jc> getloadavg() isn't there, it defines C_GETLOADAVG.  Thus check
  jc> after if it _is_ defined, and don't compile the test program.

I think you're mistaken here.  When the manual says "defines
C_GETLOADAVG", that means it adds a "#define C_GETLOADAVG 1" to your
config.h file.  There's no way to test this in the makefile and compile
or not compile the test program based on that.

Also, you're missing the fundamental point: all these checks that could
be done at configure time to avoid building the test program are
useless for solving this problem... because the error happens when you
run automake, which happens on the developers system when he creates the
distribution, and _NOT_ on the user's system when they run configure.

The only way to keep the error from happening is to figure out a way to
keep autoconf and automake happy.

  jc> This would prevent the double linking of getloadavg.c.

There is no double linking of getloadavg.c.

For the make program, I don't include getloadavg.c explicitly and I add
LIBOBJS.

For the test program, I don't add LIBOBJS and I do include getloadavg.c
explicitly.

So, regardless of whether getloadavg.c is in LIBOBJS or not, there will
be no duplicate linking.  But, automake is not smart enough to see that.
I'm not saying it should be, because that's probably hard and probably
not worth it in the grand scheme of things.  I'm just telling you why
I've been content to ignore the error so far--it's a complaint from
automake which is actually not accurate.


I think I can solve this by doing the following:

 1) In configure.in after AC_FUNC_GETLOADAVG I would check to see if we
    found one or not.

    If we didn't, I would define a substitution variable using AC_SUBST()
    to replace a variable like getloadavg_SRC or something to contain
    "getloadavg.c".

 2) In Makefile.am, I would replace this line:

     ldavg_SOURCES = getloadavg.c

    with:

     ldavg_SOURCES = @getloadavg_SRC@

That should keep automake happy since it won't see getloadavg.c
explicitly listed.  I'll also have to muck with LDADD to make sure the
right libraries are appended, etc.

Or, maybe it would be simpler to just use LIBOBJS in the test program,
and live with the extra unneeded objects that might get linked.

I'll try it out and see what works better.

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