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

[Jim Fehlig]

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