Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Feb 2016 00:28:53 -0800
From: Andre McCurdy <armccurdy@...il.com>
To: musl@...ts.openwall.com
Subject: utmpxname() but no prototype?

Hi all,

The lxc configure script uses AC_CHECK_FUNCS to test for utmpxname()
support. From the comments it looks like this check was added
specifically for compatibility with musl:

  https://github.com/lxc/lxc/commit/8b6d8b712b867ab352598ed4b73e80e54a8c915a

Up until recently, this worked as expected: the configure script
correctly detected that musl did not provide utmpxname().

However, recently musl has gained a utmpxname() stub:

  http://git.musl-libc.org/cgit/musl/commit/?id=378f8cb5222b63e4f8532c757ce54e4074567e1f

but without also gaining a corresponding prototype in utmpx.h.

This causes a new problem when building lxc: the configure script now
detects that utmpxname() is provided but the build then fails because
there's no prototype for it:

 | ../../../lxc-1.0.7/src/lxc/lxcutmp.c: In function 'utmp_get_runlevel':
 | ../../../lxc-1.0.7/src/lxc/lxcutmp.c:256:30: error: implicit
declaration of function 'utmpxname'
[-Werror=implicit-function-declaration]
 |   if (!access(path, F_OK) && !utmpxname(path))
 |                               ^

Passing "ac_cv_func_utmpxname=no" to the lxc configure script is a
workaround but I'm wondering what the real solution should be. Should
utmpx.h be providing:

  #define utmpxname(x) (-1)

in the same way that utmp.h provides:

  #define utmpname(x) (-1)

?

Thanks
Andre
--

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.