[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Correct way to check for clock_gettime()
From: |
Dave Hart |
Subject: |
Re: Correct way to check for clock_gettime() |
Date: |
Fri, 30 Jul 2010 20:03:28 +0000 |
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