[libvirt] [PATCH RFC] build: fix build with libselinux 2.3
The attached patch is an attempt to fix recent build failures I've noticed with libselinux 2.3 CC securityselinuxhelper.lo securityselinuxhelper.c:159:5: error: conflicting types for 'setcon_raw' int setcon_raw(security_context_t context) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:41:12: note: previous declaration of 'setcon_raw' was here extern int setcon_raw(const char * con); ^ securityselinuxhelper.c:168:5: error: conflicting types for 'setcon' int setcon(security_context_t context) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:40:12: note: previous declaration of 'setcon' was here extern int setcon(const char * con); ^ securityselinuxhelper.c:174:5: error: conflicting types for 'setfilecon_raw' int setfilecon_raw(const char *path, security_context_t con) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:110:12: note: previous declaration of 'setfilecon_raw' was here extern int setfilecon_raw(const char *path, const char * con); ^ securityselinuxhelper.c:185:5: error: conflicting types for 'setfilecon' int setfilecon(const char *path, security_context_t con) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:109:12: note: previous declaration of 'setfilecon' was here extern int setfilecon(const char *path, const char * con); ^ Noticing that security_context_t changed to 'const char *', my first thought was to use AC_CHECK_TYPE to check for security_conext_t, but alas the typedef remains in 2.3 with the comment "No longer used; here for compatibility with legacy callers". I then pursued the approach in this patch of defining a config var based on 'pkg-config --modversion', which works in a test script, but not in the context of the LIBVIRT_CHECK_SELINUX macro. Probably due to some missed quoting, but I'm reaching the m4 knowledge barrier. Before attempting to bypass that, I'd like to see what others think of this approach. Is there a simpler solution? Regards, Jim
On 05/27/2014 10:05 PM, Jim Fehlig wrote:
The attached patch is an attempt to fix recent build failures I've noticed with libselinux 2.3
CC securityselinuxhelper.lo securityselinuxhelper.c:159:5: error: conflicting types for 'setcon_raw' int setcon_raw(security_context_t context) ^
Noticing that security_context_t changed to 'const char *', my first thought was to use AC_CHECK_TYPE to check for security_conext_t, but alas the typedef remains in 2.3 with the comment "No longer used; here for compatibility with legacy callers".
I then pursued the approach in this patch of defining a config var based on 'pkg-config --modversion', which works in a test script, but not in the context of the LIBVIRT_CHECK_SELINUX macro. Probably due to some missed quoting, but I'm reaching the m4 knowledge barrier. Before attempting to bypass that, I'd like to see what others think of this approach. Is there a simpler solution?
So the difference is deciding whether the const is present? It should be possible to write an AC_COMPILE_IF test that passes or fails based on whether you have a compatible redeclaration of the function.
if test "$with_selinux" = "yes"; then + AC_MSG_CHECKING([SELinux version]) + ver=$(pkg-config --modversion libselinux) + major_ver=`echo $ver | awk -F. '{print $1}'` + minor_ver=`echo $ver | awk -F. '{print $2}'` + SELINUX_VER=`expr $major_ver + $minor_ver` + AC_MSG_RESULT([$SELINUX_VER]) + if test $SELINUX_VER -ge 2003; then + AC_DEFINE_UNQUOTED([SELINUX_CTX_CHAR_PTR], 1, + [SELinux uses char * for security context]) + fi
Eww. Version-check tests are inherently fragile; we want to do a feature check (does a const char * compile) not a version check. I'll take some time tomorrow to propose an alternative. My idea is to define a new macro VIR_SELINUX_CTX_CONST to either '' or 'const' depending on which version builds, without messing around with fragile version checks. Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 05/27/2014 10:05 PM, Jim Fehlig wrote:
The attached patch is an attempt to fix recent build failures I've noticed with libselinux 2.3
CC securityselinuxhelper.lo securityselinuxhelper.c:159:5: error: conflicting types for 'setcon_raw' int setcon_raw(security_context_t context) ^
Noticing that security_context_t changed to 'const char *', my first thought was to use AC_CHECK_TYPE to check for security_conext_t, but alas the typedef remains in 2.3 with the comment "No longer used; here for compatibility with legacy callers".
I then pursued the approach in this patch of defining a config var based on 'pkg-config --modversion', which works in a test script, but not in the context of the LIBVIRT_CHECK_SELINUX macro. Probably due to some missed quoting, but I'm reaching the m4 knowledge barrier. Before attempting to bypass that, I'd like to see what others think of this approach. Is there a simpler solution?
So the difference is deciding whether the const is present? It should be possible to write an AC_COMPILE_IF test that passes or fails based on whether you have a compatible redeclaration of the function.
if test "$with_selinux" = "yes"; then + AC_MSG_CHECKING([SELinux version]) + ver=$(pkg-config --modversion libselinux) + major_ver=`echo $ver | awk -F. '{print $1}'` + minor_ver=`echo $ver | awk -F. '{print $2}'` + SELINUX_VER=`expr $major_ver + $minor_ver` + AC_MSG_RESULT([$SELINUX_VER]) + if test $SELINUX_VER -ge 2003; then + AC_DEFINE_UNQUOTED([SELINUX_CTX_CHAR_PTR], 1, + [SELinux uses char * for security context]) + fi
Eww. Version-check tests are inherently fragile;
Understood. That's why this was my second approach.
we want to do a feature check (does a const char * compile) not a version check. I'll take some time tomorrow to propose an alternative. My idea is to define a new macro VIR_SELINUX_CTX_CONST to either '' or 'const' depending on which version builds,
But I didn't think of that. Much better indeed. Regards, Jim
participants (2)
-
Eric Blake -
Jim Fehlig