Re: Correct way to check for clock_gettime()

[Dave Hart]

On Fri, Jul 30, 2010 at 11:51 UTC, Thomas Petazzoni
<address@hidden> wrote:
> The AC_CHECK_FUNCS test sees that ac_cv_func_clock_gettime is "yes" in
> the cache (as inserted by CTorrent), so it assumes that clock_gettime()
> is available without making any compilation test. So it doesn't know
> that "-lrt" should be appended to the set of libraries to link with,
> and the libglib build process fails later on because "-lrt" is missing
> on the command line.
>
> So the question is, which of CTorrent and libglib is wrong in its
> configure.{ac,in} ?

Neither, I'm afraid.  On their own, both work correctly, including
with a configuration cache file.  The error is in sharing the
configuration cache across independently-maintained packages that are
not designed to share a cache.  I think if you continue sharing the
cache across independent packages, you will continue to expose
problems like this over time.

I am sympathetic to your desire to share the cache.  I do test builds
on some remarkably slow machines, including one which takes nearly 20
minutes of configure runs for the NTP package (and its SNTP
subpackage) without a primed cache.  I invested a good bit of work to
make sure NTP's configure.ac files use the cache properly to ensure I
can re-use caches over time, including adding a versioning mechanism
to purge the cache automatically after a change invalidating old
cached results.  I wish I had a better answer to offer, but I think
you simply need to ensure the two packages are not sharing a cache,
which means ensuring they are not nested under a common configure
script, and invoking them with different --cache-file options.

Cheers,
Dave Hart