On Fri, Jul 30, 2010 at 11:51 UTC, Thomas Petazzoni
<thomas.petazzoni@xxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
