[PATCH weston] build: add check for clock_gettime() in librt

[Pekka Paalanen]

On Thu, 21 Apr 2016 12:08:55 -0700
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Thu, Apr 21, 2016 at 11:18:48AM -0300, Gustavo Zacarias wrote:
> > zuctest is another clock_gettime() user that fails to link against librt when
> > necessary.
> > 
> > Instead of adding another -lrt LDADD entry i've opted for the saner way and
> > converted the check to a configure test that will set CLOCK_GETTIME_LIBS
> > appropiately and replaced all instances of -lrt with it.
> > Built-tested against old and new glibc.
> > 
> > Signed-off-by: Gustavo Zacarias <gustavo at zacarias.com.ar>  
> 
> Reviewed-by: Bryce Harrington <bryce at osg.samsung.com>
> > ---
> >  Makefile.am  | 15 ++++++++-------
> >  configure.ac |  5 +++++
> >  2 files changed, 13 insertions(+), 7 deletions(-)

> > diff --git a/configure.ac b/configure.ac
> > index 447cf6b..670200c 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -46,6 +46,11 @@ AC_CHECK_FUNC([dlopen], [],
> >                AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS="-ldl"))
> >  AC_SUBST(DLOPEN_LIBS)
> >  
> > +# In old glibc versions (< 2.17) clock_gettime() is in librt
> > +AC_SEARCH_LIBS([clock_gettime], [rt],
> > +             [CLOCK_GETTIME_LIBS="-lrt"])
> > +AC_SUBST([CLOCK_GETTIME_LIBS])
> > +
> >  AC_CHECK_DECL(SFD_CLOEXEC,[],
> >  	      [AC_MSG_ERROR("SFD_CLOEXEC is needed to compile weston")],
> >  	      [[#include <sys/signalfd.h>]])

Pushed with my R-b:
   fd01ba0..34d5985  master -> master

However, I had a chat with Quentin in IRC, and this use of
AC_SEARCH_LIBS clobbers LIBS which we don't intend to use, yet AC
macros do use it.

We will be following up with patches to fix that and clean up some of
the existing LIBS issues.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160422/022f984e/attachment.sig>