[libvirt] [PATCH RFC] build: fix build with libselinux 2.3

[Jim Fehlig]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: libselinux-build-fix.patch
Type: text/x-patch
Size: 2812 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140527/db480766/attachment-0001.bin>