public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
* [LTP] [PATCH] include: undefine _LINUX_TYPES_H if including sys/capability.h
@ 2019-10-15 10:15 Li Wang
  2019-10-15 13:02 ` Richard Palethorpe
  0 siblings, 1 reply; 4+ messages in thread
From: Li Wang @ 2019-10-15 10:15 UTC (permalink / raw)
  To: ltp

In some of the libcap-devel(1.96~2.16) versions, it defines the _LINUX_TYPES_H
macro to make ltp-lib cann't include linux/types.h essentially.

    # cat -n /usr/include/sys/capability.h
    ...
    25  /*
    26   * Make sure we can be included from userland by preventing
    27   * capability.h from including other kernel headers
    28   */
    29  #define _LINUX_TYPES_H

To get rid of this compiling errors on rhel6(libcap-devel-2.16) series platform,
here undefine _LINUX_TYPES_H if included that sys/capability.h.

  == Error log ==
  In file included from ../include/tst_netlink.h:26,
                 from tst_crypto.c:13:
  /usr/include/linux/netlink.h:45: error: expected specifier-qualifier-list before ?__u16?
  /usr/include/linux/netlink.h:135: error: expected specifier-qualifier-list before ?__u16?
  tst_crypto.c: In function ?tst_crypto_recv_ack?:
  tst_crypto.c:46: error: ?struct nlmsghdr? has no member named ?nlmsg_seq?
  tst_crypto.c:47: error: ?struct nlmsghdr? has no member named ?nlmsg_type?
  tst_crypto.c:47: error: ?struct nlmsghdr? has no member named ?nlmsg_seq?
  tst_crypto.c:55: error: ?struct nlmsghdr? has no member named ?nlmsg_type?
  tst_crypto.c:58: error: ?struct nlmsghdr? has no member named ?nlmsg_type?
  tst_crypto.c:58: error: ?struct nlmsghdr? has no member named ?nlmsg_seq?
  tst_crypto.c: In function ?tst_crypto_add_alg?:
  ...
  make: *** [tst_crypto.o] Error 1

Reported-by: Ping Fang <pifang@redhat.com>
Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Ping Fang <pifang@redhat.com>
Cc: Richard Palethorpe <rpalethorpe@suse.com>
---
 include/lapi/capability.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/lapi/capability.h b/include/lapi/capability.h
index dac233d84..3c2ee7937 100644
--- a/include/lapi/capability.h
+++ b/include/lapi/capability.h
@@ -10,6 +10,7 @@
 
 #ifdef HAVE_SYS_CAPABILITY_H
 # include <sys/capability.h>
+# undef _LINUX_TYPES_H
 #endif
 
 #ifndef CAP_NET_RAW
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [LTP] [PATCH] include: undefine _LINUX_TYPES_H if including sys/capability.h
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Palethorpe @ 2019-10-15 13:02 UTC (permalink / raw)
  To: ltp

Hello,

Li Wang <liwang@redhat.com> writes:

> In some of the libcap-devel(1.96~2.16) versions, it defines the _LINUX_TYPES_H
> macro to make ltp-lib cann't include linux/types.h essentially.
>
>     # cat -n /usr/include/sys/capability.h
>     ...
>     25  /*
>     26   * Make sure we can be included from userland by preventing
>     27   * capability.h from including other kernel headers
>     28   */
>     29  #define _LINUX_TYPES_H
>
> To get rid of this compiling errors on rhel6(libcap-devel-2.16) series platform,
> here undefine _LINUX_TYPES_H if included that sys/capability.h.
>
>   == Error log ==
>   In file included from ../include/tst_netlink.h:26,
>                  from tst_crypto.c:13:
>   /usr/include/linux/netlink.h:45: error: expected specifier-qualifier-list before ?__u16?
>   /usr/include/linux/netlink.h:135: error: expected specifier-qualifier-list before ?__u16?
>   tst_crypto.c: In function ?tst_crypto_recv_ack?:
>   tst_crypto.c:46: error: ?struct nlmsghdr? has no member named ?nlmsg_seq?
>   tst_crypto.c:47: error: ?struct nlmsghdr? has no member named ?nlmsg_type?
>   tst_crypto.c:47: error: ?struct nlmsghdr? has no member named ?nlmsg_seq?
>   tst_crypto.c:55: error: ?struct nlmsghdr? has no member named ?nlmsg_type?
>   tst_crypto.c:58: error: ?struct nlmsghdr? has no member named ?nlmsg_type?
>   tst_crypto.c:58: error: ?struct nlmsghdr? has no member named ?nlmsg_seq?
>   tst_crypto.c: In function ?tst_crypto_add_alg?:
>   ...
>   make: *** [tst_crypto.o] Error 1
>
> Reported-by: Ping Fang <pifang@redhat.com>
> Signed-off-by: Li Wang <liwang@redhat.com>
> Cc: Ping Fang <pifang@redhat.com>
> Cc: Richard Palethorpe <rpalethorpe@suse.com>
> ---
>  include/lapi/capability.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/lapi/capability.h b/include/lapi/capability.h
> index dac233d84..3c2ee7937 100644
> --- a/include/lapi/capability.h
> +++ b/include/lapi/capability.h
> @@ -10,6 +10,7 @@
>  
>  #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.

>  #endif
>  
>  #ifndef CAP_NET_RAW


-- 
Thank you,
Richard.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [LTP] [PATCH] include: undefine _LINUX_TYPES_H if including sys/capability.h
  2019-10-15 13:02 ` Richard Palethorpe
@ 2019-10-16  6:57   ` Li Wang
  2019-10-16  7:28     ` Richard Palethorpe
  0 siblings, 1 reply; 4+ messages in thread
From: Li Wang @ 2019-10-16  6:57 UTC (permalink / raw)
  To: ltp

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.

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]

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

 #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
 ])
-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20191016/906d80d0/attachment.htm>

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [LTP] [PATCH] include: undefine _LINUX_TYPES_H if including sys/capability.h
  2019-10-16  6:57   ` Li Wang
@ 2019-10-16  7:28     ` Richard Palethorpe
  0 siblings, 0 replies; 4+ messages in thread
From: Richard Palethorpe @ 2019-10-16  7:28 UTC (permalink / raw)
  To: ltp

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-10-16  7:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox