[Buildroot] Correct way to check for clock_gettime()

[Buildroot] Correct way to check for clock_gettime()

[Thomas Petazzoni]

Hello,

I have a build problem related to the fact that I build two seperate
packages (ctorrent and libglib) while sharing a configure cache (using
the --cache-file ./configure option) [*]

The issue is that CTorrent first does:

AC_SEARCH_LIBS([clock_gettime],[rt posix4])

Which tests if clock_gettime() can be found with no special library
argument (which fails), and then tests if it can be found using "-lrt",
which works. So 

Then, CTorrent does:

AC_CHECK_FUNCS([clock_gettime])

Which works too, because the test program gets compiled with
"-lrt" (which is strange, because I thought that only AC_CHECK_LIB was
adding the matching library to LIBS, and that AC_SEARCH_LIBS was not
doing that). But anyway, the test works, so CTorrent configure.ac adds:

 ac_cv_func_clock_gettime=${ac_cv_func_clock_gettime=yes}
 ac_cv_search_clock_gettime=${ac_cv_search_clock_gettime=-lrt}

to the configure cache.

Then later on, the ./configure script of libglib is executed. And it
does:

AC_CHECK_FUNCS(clock_gettime, [], [
  AC_CHECK_LIB(rt, clock_gettime, [
    AC_DEFINE(HAVE_CLOCK_GETTIME, 1)
    G_THREAD_LIBS="$G_THREAD_LIBS -lrt"
    G_THREAD_LIBS_FOR_GTHREAD="$G_THREAD_LIBS_FOR_GTHREAD -lrt"
  ])
])

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} ?

I've attached the CTorrent configure.ac and libglib configure.in to
this e-mail (renamed ctorrent-configure.ac and libglib-configure.in).

Thanks !

Thomas

[*] For those who wonder, we're doing this kind of builds in Buildroot,
    which is an embedded Linux build system. As we repeatedly configure
    and build several dozens of packages, sharing the configure cache
    greatly speeds up the build... but raises some issues such as the
    one described in this e-mail.
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctorrent-configure.ac
Type: application/octet-stream
Size: 4655 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100730/37c64fe7/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libglib-configure.in
Type: application/octet-stream
Size: 104463 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100730/37c64fe7/attachment-0003.obj>

[Buildroot] Correct way to check for clock_gettime()

[Thomas Petazzoni]

Hello Dave,

Thanks for your feedback!

On Fri, 30 Jul 2010 20:03:28 +0000
Dave Hart <davehart@gmail.com> wrote:

> 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.

Obviously, for Buildroot, the main advantage of cache files is if we
can share them between packages. A given package is rarely built twice.

However, the documentation of Autoconf seems to say quite the
oppositive than what you're saying. See
http://www.gnu.org/software/hello/manual/autoconf/Cache-Files.html,
which says:

"The site initialization script can specify a site-wide cache file to
use, instead of the usual per-program cache. In this case, the cache
file gradually accumulates information whenever someone runs a new
configure script. (Running configure merges the new cache results with
the existing cache file.) This may cause problems, however, if the
system configuration (e.g., the installed libraries or compilers)
changes and the stale cache file is not deleted."

So the ability of sharing the cache between execution of
different configure scripts is a documented feature. Is it just that in
reality it doesn't work that well ?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Correct way to check for clock_gettime()

[Thomas Petazzoni]

Hello Ralf,

Thanks a lot for your feedback!

On Mon, 2 Aug 2010 07:17:36 +0200
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:

> * Thomas Petazzoni wrote on Mon, Aug 02, 2010 at 03:33:53AM CEST:
> > So the ability of sharing the cache between execution of
> > different configure scripts is a documented feature. Is it just
> > that in reality it doesn't work that well ?
> 
> You should be able to modify both configure scripts in a way so that
> it works again; and in this particular example it should be done.
> Getting this approach to scale can be a lot of work though.

Is this approach "officially" supported by autoconf ? If I fix one of
the configure.{in,ac} script and try to get the change merged upstream,
it's an important argument to know if the change is done to comply with
a general rule of configure.{in,ac} and not a specific hack.

Moreover, as Steffen asked later in the thread, in the particular case
I've presented in the original mail of this thread, what would be the
correct fix ?

I have also other cases of configure cache misuse by two independent
packages. I'm often able to track down the cause of the problem, but
I'm not autoconf-ed enough to know which is the correct fix. May I
present those other cases to the list ?

Thanks again for your inputs,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com