From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] include: undefine _LINUX_TYPES_H if including sys/capability.h
Date: Wed, 16 Oct 2019 09:28:45 +0200 [thread overview]
Message-ID: <87r23dw3ma.fsf@rpws.prws.suse.cz> (raw)
In-Reply-To: <CAEemH2dfHM7ExwYwdc-_oEw9_DftgfRw3mn2pnAEf1CKxyyn2A@mail.gmail.com>
Hello,
Li Wang <liwang@redhat.com> writes:
> Richard Palethorpe <rpalethorpe@suse.de> wrote:
>
> ...
>> > #ifdef HAVE_SYS_CAPABILITY_H
>> > # include <sys/capability.h>
>> > +# undef _LINUX_TYPES_H
>>
>> My concern here is if linux/types.h has already been included. Then this
>> could cause a redefinition error if it is included again.
>>
>
> Hmm, it looks tricky to solve this, because I didn't find a macro to show
> version in libcap files.
>
> Another method I can think of is to build a small program to check if that
> libcap version is newer or not during the configure phase. If yes, then
> export a new macro HAVE_NEWER_LIBCAP to be used in /lapi/capability.h.
Yes, this could work.
>
> The following patch has been verified on both rhel6 and rhel8, any comments?
> [I'm not familiar with m4 syntax, just copy from other places]
m4 all looks ugly to me ;-)
>
> diff --git a/include/lapi/capability.h b/include/lapi/capability.h
> index 3c2ee7937..3607179b5 100644
> --- a/include/lapi/capability.h
> +++ b/include/lapi/capability.h
> @@ -10,7 +10,9 @@
>
> #ifdef HAVE_SYS_CAPABILITY_H
> # include <sys/capability.h>
> -# undef _LINUX_TYPES_H
> +# ifndef HAVE_NEWER_LIBCAP
> +# undef _LINUX_TYPES_H
> +# endif
> #endif
This is so wierd it maybe deserves a comment. Otherwise, this looks good
to me.
>
> #ifndef CAP_NET_RAW
> diff --git a/m4/ltp-cap.m4 b/m4/ltp-cap.m4
> index 02d3cac8c..8b1546401 100644
> --- a/m4/ltp-cap.m4
> +++ b/m4/ltp-cap.m4
> @@ -14,4 +14,20 @@ if test "x$cap_libs" != x; then
> AC_DEFINE(HAVE_LIBCAP)
> fi
> AC_SUBST(CAP_LIBS,$cap_libs)
> +
> +AH_TEMPLATE(HAVE_NEWER_LIBCAP,
> +[Define to 1 if you have newer libcap-2 installed.])
> +AC_COMPILE_IFELSE([AC_LANG_SOURCE([
> +#include <sys/capability.h>
> +#include <linux/types.h>
> +int main(void) {
> + __u16 a;
> + __u32 b;
> + return 0;
> +}])],[has_newer_libcap="yes"])
> +
> +if test "x$has_newer_libcap" = xyes; then
> + AC_DEFINE(HAVE_NEWER_LIBCAP)
> +fi
> ])
--
Thank you,
Richard.
prev parent reply other threads:[~2019-10-16 7:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 10:15 [LTP] [PATCH] include: undefine _LINUX_TYPES_H if including sys/capability.h Li Wang
2019-10-15 13:02 ` Richard Palethorpe
2019-10-16 6:57 ` Li Wang
2019-10-16 7:28 ` Richard Palethorpe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r23dw3ma.fsf@rpws.prws.suse.cz \
--to=rpalethorpe@suse.de \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox