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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list