[PATCH] build: update DPDK to use C11 standard

[PATCH] build: update DPDK to use C11 standard

[Bruce Richardson]

As previously announced, DPDK 23.11 will require a C11 supporting
compiler and will use the C11 standard in all builds.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

---

When moving the information about the new requirement to the release
notes, a change like this doesn't seem to fit into any existing section.
Given its global scope and importance, I've therefore just put it on
top of the file, rather than in any section.
---
 doc/guides/linux_gsg/sys_reqs.rst      |  3 ++-
 doc/guides/rel_notes/deprecation.rst   | 18 ------------------
 doc/guides/rel_notes/release_23_11.rst | 17 +++++++++++++++++
 meson.build                            |  1 +
 4 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index dfeaf4e1c5..13be715933 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -27,7 +27,8 @@ Compilation of the DPDK
     The setup commands and installed packages needed on various systems may be different.
     For details on Linux distributions and the versions tested, please consult the DPDK Release Notes.
 
-*   General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+),
+*   General development tools including a C compiler supporting the C11 standard,
+    including standard atomics, for example: GCC (version 5.0+) or Clang (version 3.6+),
     and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK.
 
     * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 494b401cda..cc939d3c67 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,24 +17,6 @@ Other API and ABI deprecation notices are to be posted below.
 Deprecation Notices
 -------------------
 
-* C Compiler: From DPDK 23.11 onwards,
-  building DPDK will require a C compiler which supports the C11 standard,
-  including support for C11 standard atomics.
-
-  More specifically, the requirements will be:
-
-  * Support for flag "-std=c11" (or similar)
-  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
-
-  Please note:
-
-  * C11, including standard atomics, is supported from GCC version 5 onwards,
-    and is the default language version in that release
-    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
-  * C11 is the default compilation mode in Clang from version 3.6,
-    which also added support for standard atomics
-    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
-
 * build: Enabling deprecated libraries (``flow_classify``, ``kni``)
   won't be possible anymore through the use of the ``disable_libs`` build option.
   A new build option for deprecated libraries will be introduced instead.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 6b4dd21fd0..c8b9ed456c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -20,6 +20,23 @@ DPDK Release 23.11
       ninja -C build doc
       xdg-open build/doc/guides/html/rel_notes/release_23_11.html
 
+* Build Requirements: From DPDK 23.11 onwards,
+  building DPDK will require a C compiler which supports the C11 standard,
+  including support for C11 standard atomics.
+
+  More specifically, the requirements will be:
+
+  * Support for flag "-std=c11" (or similar)
+  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
+
+  Please note:
+
+  * C11, including standard atomics, is supported from GCC version 5 onwards,
+    and is the default language version in that release
+    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
+  * C11 is the default compilation mode in Clang from version 3.6,
+    which also added support for standard atomics
+    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
 
 New Features
 ------------
diff --git a/meson.build b/meson.build
index 39cb73846d..70b54f0c98 100644
--- a/meson.build
+++ b/meson.build
@@ -9,6 +9,7 @@ project('DPDK', 'c',
         license: 'BSD',
         default_options: [
             'buildtype=release',
+            'c_std=c11',
             'default_library=static',
             'warning_level=2',
         ],
-- 
2.39.2

RE: [PATCH] build: update DPDK to use C11 standard

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 31 July 2023 12.39
> 
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> ---

Acked-by: Morten Brørup <mb@smartsharesystems.com>

[PATCH v2] build: update DPDK to use C11 standard

[Bruce Richardson]

As previously announced, DPDK 23.11 will require a C11 supporting
compiler and will use the C11 standard in all builds.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>

---
V2:
* Resubmit now that 23.11-rc0 patch applied
* Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
  definition of strerror_r() with c11 standard.
---
 doc/guides/linux_gsg/sys_reqs.rst      |  3 ++-
 doc/guides/rel_notes/deprecation.rst   | 18 ------------------
 doc/guides/rel_notes/release_23_11.rst | 17 +++++++++++++++++
 lib/eal/common/eal_common_errno.c      |  1 +
 meson.build                            |  1 +
 5 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index dfeaf4e1c5..13be715933 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -27,7 +27,8 @@ Compilation of the DPDK
     The setup commands and installed packages needed on various systems may be different.
     For details on Linux distributions and the versions tested, please consult the DPDK Release Notes.
 
-*   General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+),
+*   General development tools including a C compiler supporting the C11 standard,
+    including standard atomics, for example: GCC (version 5.0+) or Clang (version 3.6+),
     and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK.
 
     * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 494b401cda..cc939d3c67 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,24 +17,6 @@ Other API and ABI deprecation notices are to be posted below.
 Deprecation Notices
 -------------------
 
-* C Compiler: From DPDK 23.11 onwards,
-  building DPDK will require a C compiler which supports the C11 standard,
-  including support for C11 standard atomics.
-
-  More specifically, the requirements will be:
-
-  * Support for flag "-std=c11" (or similar)
-  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
-
-  Please note:
-
-  * C11, including standard atomics, is supported from GCC version 5 onwards,
-    and is the default language version in that release
-    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
-  * C11 is the default compilation mode in Clang from version 3.6,
-    which also added support for standard atomics
-    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
-
 * build: Enabling deprecated libraries (``flow_classify``, ``kni``)
   won't be possible anymore through the use of the ``disable_libs`` build option.
   A new build option for deprecated libraries will be introduced instead.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 6b4dd21fd0..c8b9ed456c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -20,6 +20,23 @@ DPDK Release 23.11
       ninja -C build doc
       xdg-open build/doc/guides/html/rel_notes/release_23_11.html
 
+* Build Requirements: From DPDK 23.11 onwards,
+  building DPDK will require a C compiler which supports the C11 standard,
+  including support for C11 standard atomics.
+
+  More specifically, the requirements will be:
+
+  * Support for flag "-std=c11" (or similar)
+  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
+
+  Please note:
+
+  * C11, including standard atomics, is supported from GCC version 5 onwards,
+    and is the default language version in that release
+    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
+  * C11 is the default compilation mode in Clang from version 3.6,
+    which also added support for standard atomics
+    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
 
 New Features
 ------------
diff --git a/lib/eal/common/eal_common_errno.c b/lib/eal/common/eal_common_errno.c
index ef8f782abb..b30e2f0ad4 100644
--- a/lib/eal/common/eal_common_errno.c
+++ b/lib/eal/common/eal_common_errno.c
@@ -4,6 +4,7 @@
 
 /* Use XSI-compliant portable version of strerror_r() */
 #undef _GNU_SOURCE
+#define _POSIX_C_SOURCE 200809L
 
 #include <stdio.h>
 #include <string.h>
diff --git a/meson.build b/meson.build
index 39cb73846d..70b54f0c98 100644
--- a/meson.build
+++ b/meson.build
@@ -9,6 +9,7 @@ project('DPDK', 'c',
         license: 'BSD',
         default_options: [
             'buildtype=release',
+            'c_std=c11',
             'default_library=static',
             'warning_level=2',
         ],
-- 
2.39.2

Re: [PATCH v2] build: update DPDK to use C11 standard

[Tyler Retzlaff]

On Mon, Jul 31, 2023 at 04:58:02PM +0100, Bruce Richardson wrote:
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> 
> ---

Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

Re: [PATCH v2] build: update DPDK to use C11 standard

[Tyler Retzlaff]

On Mon, Jul 31, 2023 at 04:58:02PM +0100, Bruce Richardson wrote:
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> 
> ---
> V2:
> * Resubmit now that 23.11-rc0 patch applied
> * Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
>   definition of strerror_r() with c11 standard.
> ---
>  doc/guides/linux_gsg/sys_reqs.rst      |  3 ++-
>  doc/guides/rel_notes/deprecation.rst   | 18 ------------------
>  doc/guides/rel_notes/release_23_11.rst | 17 +++++++++++++++++
>  lib/eal/common/eal_common_errno.c      |  1 +
>  meson.build                            |  1 +
>  5 files changed, 21 insertions(+), 19 deletions(-)
> 
> diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
> index dfeaf4e1c5..13be715933 100644
> --- a/doc/guides/linux_gsg/sys_reqs.rst
> +++ b/doc/guides/linux_gsg/sys_reqs.rst
> @@ -27,7 +27,8 @@ Compilation of the DPDK
>      The setup commands and installed packages needed on various systems may be different.
>      For details on Linux distributions and the versions tested, please consult the DPDK Release Notes.
>  
> -*   General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+),
> +*   General development tools including a C compiler supporting the C11 standard,
> +    including standard atomics, for example: GCC (version 5.0+) or Clang (version 3.6+),
>      and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK.
>  
>      * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 494b401cda..cc939d3c67 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -17,24 +17,6 @@ Other API and ABI deprecation notices are to be posted below.
>  Deprecation Notices
>  -------------------
>  
> -* C Compiler: From DPDK 23.11 onwards,
> -  building DPDK will require a C compiler which supports the C11 standard,
> -  including support for C11 standard atomics.
> -
> -  More specifically, the requirements will be:
> -
> -  * Support for flag "-std=c11" (or similar)
> -  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
> -
> -  Please note:
> -
> -  * C11, including standard atomics, is supported from GCC version 5 onwards,
> -    and is the default language version in that release
> -    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
> -  * C11 is the default compilation mode in Clang from version 3.6,
> -    which also added support for standard atomics
> -    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
> -
>  * build: Enabling deprecated libraries (``flow_classify``, ``kni``)
>    won't be possible anymore through the use of the ``disable_libs`` build option.
>    A new build option for deprecated libraries will be introduced instead.
> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
> index 6b4dd21fd0..c8b9ed456c 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -20,6 +20,23 @@ DPDK Release 23.11
>        ninja -C build doc
>        xdg-open build/doc/guides/html/rel_notes/release_23_11.html
>  
> +* Build Requirements: From DPDK 23.11 onwards,
> +  building DPDK will require a C compiler which supports the C11 standard,
> +  including support for C11 standard atomics.
> +
> +  More specifically, the requirements will be:
> +
> +  * Support for flag "-std=c11" (or similar)
> +  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
> +
> +  Please note:
> +
> +  * C11, including standard atomics, is supported from GCC version 5 onwards,
> +    and is the default language version in that release
> +    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
> +  * C11 is the default compilation mode in Clang from version 3.6,
> +    which also added support for standard atomics
> +    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
>  
>  New Features
>  ------------
> diff --git a/lib/eal/common/eal_common_errno.c b/lib/eal/common/eal_common_errno.c
> index ef8f782abb..b30e2f0ad4 100644
> --- a/lib/eal/common/eal_common_errno.c
> +++ b/lib/eal/common/eal_common_errno.c
> @@ -4,6 +4,7 @@
>  
>  /* Use XSI-compliant portable version of strerror_r() */
>  #undef _GNU_SOURCE
> +#define _POSIX_C_SOURCE 200809L
>  
>  #include <stdio.h>
>  #include <string.h>
> diff --git a/meson.build b/meson.build
> index 39cb73846d..70b54f0c98 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -9,6 +9,7 @@ project('DPDK', 'c',
>          license: 'BSD',
>          default_options: [
>              'buildtype=release',
> +            'c_std=c11',
>              'default_library=static',
>              'warning_level=2',
>          ],
> -- 

oh I acked v2 (and you can maintain that ack) but one additional removal
of forced -std=gnu99 is maybe necessary?

drivers/net/failsafe/meson.build
    probably should remove cflags += '-std=gnu99'

if we remove it we inherit the -std=c11 from meson project configuration
and define a _POSIX_C_SOURCE narrowly where necessary (if it is needed).

[PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

As previously announced, DPDK 23.11 will require a C11 supporting
compiler and will use the C11 standard in all builds.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

---
V3:
* remove (now unneeded) use of -std=gnu99 in failsafe net driver.

V2:
* Resubmit now that 23.11-rc0 patch applied
* Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
  definition of strerror_r() with c11 standard.
---
 doc/guides/linux_gsg/sys_reqs.rst      |  3 ++-
 doc/guides/rel_notes/deprecation.rst   | 18 ------------------
 doc/guides/rel_notes/release_23_11.rst | 17 +++++++++++++++++
 drivers/net/failsafe/meson.build       |  1 -
 lib/eal/common/eal_common_errno.c      |  1 +
 meson.build                            |  1 +
 6 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index dfeaf4e1c5..13be715933 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -27,7 +27,8 @@ Compilation of the DPDK
     The setup commands and installed packages needed on various systems may be different.
     For details on Linux distributions and the versions tested, please consult the DPDK Release Notes.
 
-*   General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+),
+*   General development tools including a C compiler supporting the C11 standard,
+    including standard atomics, for example: GCC (version 5.0+) or Clang (version 3.6+),
     and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK.
 
     * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 494b401cda..cc939d3c67 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,24 +17,6 @@ Other API and ABI deprecation notices are to be posted below.
 Deprecation Notices
 -------------------
 
-* C Compiler: From DPDK 23.11 onwards,
-  building DPDK will require a C compiler which supports the C11 standard,
-  including support for C11 standard atomics.
-
-  More specifically, the requirements will be:
-
-  * Support for flag "-std=c11" (or similar)
-  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
-
-  Please note:
-
-  * C11, including standard atomics, is supported from GCC version 5 onwards,
-    and is the default language version in that release
-    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
-  * C11 is the default compilation mode in Clang from version 3.6,
-    which also added support for standard atomics
-    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
-
 * build: Enabling deprecated libraries (``flow_classify``, ``kni``)
   won't be possible anymore through the use of the ``disable_libs`` build option.
   A new build option for deprecated libraries will be introduced instead.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 6b4dd21fd0..c8b9ed456c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -20,6 +20,23 @@ DPDK Release 23.11
       ninja -C build doc
       xdg-open build/doc/guides/html/rel_notes/release_23_11.html
 
+* Build Requirements: From DPDK 23.11 onwards,
+  building DPDK will require a C compiler which supports the C11 standard,
+  including support for C11 standard atomics.
+
+  More specifically, the requirements will be:
+
+  * Support for flag "-std=c11" (or similar)
+  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
+
+  Please note:
+
+  * C11, including standard atomics, is supported from GCC version 5 onwards,
+    and is the default language version in that release
+    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
+  * C11 is the default compilation mode in Clang from version 3.6,
+    which also added support for standard atomics
+    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
 
 New Features
 ------------
diff --git a/drivers/net/failsafe/meson.build b/drivers/net/failsafe/meson.build
index 6013e13722..c1d361083b 100644
--- a/drivers/net/failsafe/meson.build
+++ b/drivers/net/failsafe/meson.build
@@ -7,7 +7,6 @@ if is_windows
     subdir_done()
 endif
 
-cflags += '-std=gnu99'
 cflags += '-D_DEFAULT_SOURCE'
 cflags += '-D_XOPEN_SOURCE=700'
 cflags += '-pedantic'
diff --git a/lib/eal/common/eal_common_errno.c b/lib/eal/common/eal_common_errno.c
index ef8f782abb..b30e2f0ad4 100644
--- a/lib/eal/common/eal_common_errno.c
+++ b/lib/eal/common/eal_common_errno.c
@@ -4,6 +4,7 @@
 
 /* Use XSI-compliant portable version of strerror_r() */
 #undef _GNU_SOURCE
+#define _POSIX_C_SOURCE 200809L
 
 #include <stdio.h>
 #include <string.h>
diff --git a/meson.build b/meson.build
index 39cb73846d..70b54f0c98 100644
--- a/meson.build
+++ b/meson.build
@@ -9,6 +9,7 @@ project('DPDK', 'c',
         license: 'BSD',
         default_options: [
             'buildtype=release',
+            'c_std=c11',
             'default_library=static',
             'warning_level=2',
         ],
-- 
2.39.2

Re: [PATCH v3] build: update DPDK to use C11 standard

[Tyler Retzlaff]

On Mon, Jul 31, 2023 at 05:58:11PM +0100, Bruce Richardson wrote:
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> 
> ---
> V3:
> * remove (now unneeded) use of -std=gnu99 in failsafe net driver.
> 
> V2:
> * Resubmit now that 23.11-rc0 patch applied
> * Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
>   definition of strerror_r() with c11 standard.
> ---

Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

if there is no objection from others i would like to suggest expedited
merge of this series to make it easy to take a dependency on it for
atomics changes.

thanks!

Re: [PATCH v3] build: update DPDK to use C11 standard

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]

Hi Bruce,

I see some failures for this series for our Ubuntu 20.04 containers. And,
our DTS testbeds which are on ubuntu 20.04 are skipping running
testsuites because they can't compile DPDK. So, that's why it has some
missing results for a couple of the Intel NICs. For context, I'll paste
below where the compile job terminates in one of our containerized compile
test runs. The GCC in use here is version 9.4, so it meets the requirements
as described in your patch as far as I can tell. I'll check it out more
tomorrow to see whether it's an infra failure, like some missing
dependencies. Please let me know if we expect to have no issues with 20.04
or if this is anticipated.

Thanks!

[1638/2730] Generating symbol file 'drivers/a715181@@rte_net_ixgbe@sha
/librte_net_ixgbe.so.24.0.symbols'.
[1639/2730] Compiling C object 'drivers/a715181@@tmp_rte_net_mlx4@sta
/net_mlx4_mlx4.c.o'.
FAILED: drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o
ccache cc -Idrivers/a715181@@tmp_rte_net_mlx4@sta -Idrivers -I../drivers
-Idrivers/net/mlx4 -I../drivers/net/mlx4 -Ilib/ethdev -I../lib/ethdev -I.
-I../ -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/telemetry/../metrics
-I../lib/telemetry/../metrics -Ilib/telemetry -I../lib/telemetry -Ilib/net
-I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool
-Ilib/ring -I../lib/ring -Ilib/meter -I../lib/meter -Idrivers/bus/pci
-I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci
-Idrivers/bus/vdev -I../drivers/bus/vdev -I/usr/include/libnl3
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Wextra -Werror -std=c11 -O3 -include rte_config.h -Wcast-qual -Wdeprecated
-Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition
-Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
-std=c11 -Wno-strict-prototypes -D_BSD_SOURCE -D_DEFAULT_SOURCE
-D_XOPEN_SOURCE=600 -UPEDANTIC -DRTE_LOG_DEFAULT_LOGTYPE=pmd.net.mlx4 -MD
-MQ 'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -MF
'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o.d' -o
'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -c
../drivers/net/mlx4/mlx4.c
In file included from ../drivers/net/mlx4/mlx4_rxtx.h:27,
                 from ../drivers/net/mlx4/mlx4.c:49:
../drivers/net/mlx4/mlx4_prm.h:111:8: error: redefinition of 'struct
mlx4_wqe_lso_seg'
  111 | struct mlx4_wqe_lso_seg {
      |        ^~~~~~~~~~~~~~~~
In file included from ../drivers/net/mlx4/mlx4_glue.h:16,
                 from ../drivers/net/mlx4/mlx4.c:46:
/usr/include/infiniband/mlx4dv.h:410:8: note: originally defined here
  410 | struct mlx4_wqe_lso_seg {
      |        ^~~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.

[-- Attachment #2: Type: text/html, Size: 3425 bytes --]

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
>    Hi Bruce,
>    I see some failures for this series for our Ubuntu 20.04 containers.
>    And, our DTS testbeds which are on ubuntu 20.04 are skipping running
>    testsuites because they can't compile DPDK. So, that's why it has some
>    missing results for a couple of the Intel NICs. For context, I'll paste
>    below where the compile job terminates in one of our containerized
>    compile test runs. The GCC in use here is version 9.4, so it meets the
>    requirements as described in your patch as far as I can tell. I'll
>    check it out more tomorrow to see whether it's an infra failure, like
>    some missing dependencies. Please let me know if we expect to have no
>    issues with 20.04 or if this is anticipated.
>    Thanks!

While not anticipated, this is why we have CI so these range of distros can
all be checked. There are a lot of failure reports from Ubuntu 20.04 so I
think this is a genuine issue. I will fire up a 20.04 VM myself and see
what I can find, and submit a new patch revision.

/Bruce

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
>    Hi Bruce,
>    I see some failures for this series for our Ubuntu 20.04 containers.
>    And, our DTS testbeds which are on ubuntu 20.04 are skipping running
>    testsuites because they can't compile DPDK. So, that's why it has some
>    missing results for a couple of the Intel NICs. For context, I'll paste
>    below where the compile job terminates in one of our containerized
>    compile test runs. The GCC in use here is version 9.4, so it meets the
>    requirements as described in your patch as far as I can tell. I'll
>    check it out more tomorrow to see whether it's an infra failure, like
>    some missing dependencies. Please let me know if we expect to have no
>    issues with 20.04 or if this is anticipated.
>    Thanks!
>    [1638/2730] Generating symbol file
>    'drivers/a715181@@rte_net_ixgbe@sha/librte_net_ixgbe.so.24.0.symbols'.
>    [1639/2730] Compiling C object
>    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o'.
>    FAILED: drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o
>    ccache cc -Idrivers/a715181@@tmp_rte_net_mlx4@sta -Idrivers
>    -I../drivers -Idrivers/net/mlx4 -I../drivers/net/mlx4 -Ilib/ethdev
>    -I../lib/ethdev -I. -I../ -Iconfig -I../config -Ilib/eal/include
>    -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include
>    -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common
>    -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs
>    -Ilib/telemetry/../metrics -I../lib/telemetry/../metrics
>    -Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
>    -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
>    -Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
>    -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev
>    -I../drivers/bus/vdev -I/usr/include/libnl3 -fdiagnostics-color=always
>    -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror
>    -std=c11 -O3 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
>    -Wformat-nonliteral -Wformat-security -Wmissing-declarations
>    -Wmissing-prototypes -Wnested-externs -Wold-style-definition
>    -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
>    -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
>    -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
>    -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
>    -std=c11 -Wno-strict-prototypes -D_BSD_SOURCE -D_DEFAULT_SOURCE
>    -D_XOPEN_SOURCE=600 -UPEDANTIC -DRTE_LOG_DEFAULT_LOGTYPE=pmd.net.mlx4
>    -MD -MQ 'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -MF
>    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o.d' -o
>    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -c
>    ../drivers/net/mlx4/mlx4.c
>    In file included from ../drivers/net/mlx4/mlx4_rxtx.h:27,
>                     from ../drivers/net/mlx4/mlx4.c:49:
>    ../drivers/net/mlx4/mlx4_prm.h:111:8: error: redefinition of 'struct
>    mlx4_wqe_lso_seg'
>      111 | struct mlx4_wqe_lso_seg {
>          |        ^~~~~~~~~~~~~~~~
>    In file included from ../drivers/net/mlx4/mlx4_glue.h:16,
>                     from ../drivers/net/mlx4/mlx4.c:46:
>    /usr/include/infiniband/mlx4dv.h:410:8: note: originally defined here
>      410 | struct mlx4_wqe_lso_seg {
>          |        ^~~~~~~~~~~~~~~~
>    ninja: build stopped: subcommand failed.

Hi again,

I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
everything seems to build ok.

Looking through the logs, though, there does appear to be a difference in
the configurations in the two cases. I suspect my Ubuntu has an updated
verbs package compared to the image you are using. In the log of the failed
build, I see:

	Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: NO 
	Configuring mlx4_autoconf.h using configuration

While building in my VM, I have:

	Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
	Configuring mlx4_autoconf.h using configuration

So my verbs mlx4 header has got a different set of definitions to those in
the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev package
version "28.0-1ubuntu1"

Can the CI image be updated to latest 20.04 packages?

/Bruce

Re: [PATCH v3] build: update DPDK to use C11 standard

[David Marchand]

On Tue, Aug 1, 2023 at 12:19 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
> >    Hi Bruce,
> >    I see some failures for this series for our Ubuntu 20.04 containers.
> >    And, our DTS testbeds which are on ubuntu 20.04 are skipping running
> >    testsuites because they can't compile DPDK. So, that's why it has some
> >    missing results for a couple of the Intel NICs. For context, I'll paste
> >    below where the compile job terminates in one of our containerized
> >    compile test runs. The GCC in use here is version 9.4, so it meets the
> >    requirements as described in your patch as far as I can tell. I'll
> >    check it out more tomorrow to see whether it's an infra failure, like
> >    some missing dependencies. Please let me know if we expect to have no
> >    issues with 20.04 or if this is anticipated.
> >    Thanks!
> >    [1638/2730] Generating symbol file
> >    'drivers/a715181@@rte_net_ixgbe@sha/librte_net_ixgbe.so.24.0.symbols'.
> >    [1639/2730] Compiling C object
> >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o'.
> >    FAILED: drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o
> >    ccache cc -Idrivers/a715181@@tmp_rte_net_mlx4@sta -Idrivers
> >    -I../drivers -Idrivers/net/mlx4 -I../drivers/net/mlx4 -Ilib/ethdev
> >    -I../lib/ethdev -I. -I../ -Iconfig -I../config -Ilib/eal/include
> >    -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include
> >    -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common
> >    -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs
> >    -Ilib/telemetry/../metrics -I../lib/telemetry/../metrics
> >    -Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
> >    -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
> >    -Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
> >    -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev
> >    -I../drivers/bus/vdev -I/usr/include/libnl3 -fdiagnostics-color=always
> >    -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror
> >    -std=c11 -O3 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
> >    -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> >    -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> >    -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> >    -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
> >    -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
> >    -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
> >    -std=c11 -Wno-strict-prototypes -D_BSD_SOURCE -D_DEFAULT_SOURCE
> >    -D_XOPEN_SOURCE=600 -UPEDANTIC -DRTE_LOG_DEFAULT_LOGTYPE=pmd.net.mlx4
> >    -MD -MQ 'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -MF
> >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o.d' -o
> >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -c
> >    ../drivers/net/mlx4/mlx4.c
> >    In file included from ../drivers/net/mlx4/mlx4_rxtx.h:27,
> >                     from ../drivers/net/mlx4/mlx4.c:49:
> >    ../drivers/net/mlx4/mlx4_prm.h:111:8: error: redefinition of 'struct
> >    mlx4_wqe_lso_seg'
> >      111 | struct mlx4_wqe_lso_seg {
> >          |        ^~~~~~~~~~~~~~~~
> >    In file included from ../drivers/net/mlx4/mlx4_glue.h:16,
> >                     from ../drivers/net/mlx4/mlx4.c:46:
> >    /usr/include/infiniband/mlx4dv.h:410:8: note: originally defined here
> >      410 | struct mlx4_wqe_lso_seg {
> >          |        ^~~~~~~~~~~~~~~~
> >    ninja: build stopped: subcommand failed.
>
> Hi again,
>
> I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
> everything seems to build ok.
>
> Looking through the logs, though, there does appear to be a difference in
> the configurations in the two cases. I suspect my Ubuntu has an updated
> verbs package compared to the image you are using. In the log of the failed
> build, I see:
>
>         Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
>         Configuring mlx4_autoconf.h using configuration
>
> While building in my VM, I have:
>
>         Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
>         Configuring mlx4_autoconf.h using configuration
>
> So my verbs mlx4 header has got a different set of definitions to those in
> the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev package
> version "28.0-1ubuntu1"
>
> Can the CI image be updated to latest 20.04 packages?
>
> /Bruce
>

I can reproduce the issue seen at UNH, with a 20.04.6 container and
the same libibverbs as you:
ii  libibverbs-dev:amd64               28.0-1ubuntu1
  amd64        Development files for the libibverbs library

So I suspect something is different in container images..

Pasting the (hopefully) relevant meson logs:

Running compile:
Working directory:  /root/dpdk/build/meson-private/tmp0ovvvd9g
Command line:  ccache cc -I/usr/include/libnl3
/root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c -o
/root/dpdk/build/meson-private/tmp0ovvvd9g/output.obj -pipe -c
-D_FILE_OFFSET_BITS=64 -O0 -std=c11

Code:
 #include <infiniband/mlx4dv.h>
        void bar(void) {
            struct mlx4_wqe_lso_seg foo;
            foo.mss_hdr_size;

        };
Compiler stdout:

Compiler stderr:
 In file included from /root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c:1:
/usr/include/infiniband/mlx4dv.h:176:2: error: unknown type name 'off_t'
  176 |  off_t   uar_mmap_offset;
      |  ^~~~~

Checking whether type "struct mlx4_wqe_lso_seg" has member
"mss_hdr_size" with dependencies libmlx4, libibverbs: NO


-- 
David Marchand

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

On Tue, Aug 01, 2023 at 12:35:21PM +0200, David Marchand wrote:
> On Tue, Aug 1, 2023 at 12:19 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
> > >    Hi Bruce,
> > >    I see some failures for this series for our Ubuntu 20.04 containers.
<snip>
> >
> > Hi again,
> >
> > I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
> > everything seems to build ok.
> >
> > Looking through the logs, though, there does appear to be a difference in
> > the configurations in the two cases. I suspect my Ubuntu has an updated
> > verbs package compared to the image you are using. In the log of the failed
> > build, I see:
> >
> >         Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> >         Configuring mlx4_autoconf.h using configuration
> >
> > While building in my VM, I have:
> >
> >         Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
> >         Configuring mlx4_autoconf.h using configuration
> >
> > So my verbs mlx4 header has got a different set of definitions to those in
> > the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev package
> > version "28.0-1ubuntu1"
> >
> > Can the CI image be updated to latest 20.04 packages?
> >
> > /Bruce
> >
> 
> I can reproduce the issue seen at UNH, with a 20.04.6 container and
> the same libibverbs as you:
> ii  libibverbs-dev:amd64               28.0-1ubuntu1
>   amd64        Development files for the libibverbs library
> 
> So I suspect something is different in container images..
> 
> Pasting the (hopefully) relevant meson logs:
> 
> Running compile:
> Working directory:  /root/dpdk/build/meson-private/tmp0ovvvd9g
> Command line:  ccache cc -I/usr/include/libnl3
> /root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c -o
> /root/dpdk/build/meson-private/tmp0ovvvd9g/output.obj -pipe -c
> -D_FILE_OFFSET_BITS=64 -O0 -std=c11
> 
> Code:
>  #include <infiniband/mlx4dv.h>
>         void bar(void) {
>             struct mlx4_wqe_lso_seg foo;
>             foo.mss_hdr_size;
> 
>         };
> Compiler stdout:
> 
> Compiler stderr:
>  In file included from /root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c:1:
> /usr/include/infiniband/mlx4dv.h:176:2: error: unknown type name 'off_t'
>   176 |  off_t   uar_mmap_offset;
>       |  ^~~~~
> 
> Checking whether type "struct mlx4_wqe_lso_seg" has member
> "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> 
Thanks. I'll dig some more.

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

On Tue, Aug 01, 2023 at 11:39:06AM +0100, Bruce Richardson wrote:
> On Tue, Aug 01, 2023 at 12:35:21PM +0200, David Marchand wrote:
> > On Tue, Aug 1, 2023 at 12:19 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
> > > >    Hi Bruce,
> > > >    I see some failures for this series for our Ubuntu 20.04 containers.
> <snip>
> > >
> > > Hi again,
> > >
> > > I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
> > > everything seems to build ok.
> > >
> > > Looking through the logs, though, there does appear to be a difference in
> > > the configurations in the two cases. I suspect my Ubuntu has an updated
> > > verbs package compared to the image you are using. In the log of the failed
> > > build, I see:
> > >
> > >         Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> > >         Configuring mlx4_autoconf.h using configuration
> > >
> > > While building in my VM, I have:
> > >
> > >         Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
> > >         Configuring mlx4_autoconf.h using configuration
> > >
> > > So my verbs mlx4 header has got a different set of definitions to those in
> > > the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev package
> > > version "28.0-1ubuntu1"
> > >
> > > Can the CI image be updated to latest 20.04 packages?
> > >
> > > /Bruce
> > >
> > 
> > I can reproduce the issue seen at UNH, with a 20.04.6 container and
> > the same libibverbs as you:
> > ii  libibverbs-dev:amd64               28.0-1ubuntu1
> >   amd64        Development files for the libibverbs library
> > 
> > So I suspect something is different in container images..
> > 
> > Pasting the (hopefully) relevant meson logs:
> > 
> > Running compile:
> > Working directory:  /root/dpdk/build/meson-private/tmp0ovvvd9g
> > Command line:  ccache cc -I/usr/include/libnl3
> > /root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c -o
> > /root/dpdk/build/meson-private/tmp0ovvvd9g/output.obj -pipe -c
> > -D_FILE_OFFSET_BITS=64 -O0 -std=c11
> > 
> > Code:
> >  #include <infiniband/mlx4dv.h>
> >         void bar(void) {
> >             struct mlx4_wqe_lso_seg foo;
> >             foo.mss_hdr_size;
> > 
> >         };
> > Compiler stdout:
> > 
> > Compiler stderr:
> >  In file included from /root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c:1:
> > /usr/include/infiniband/mlx4dv.h:176:2: error: unknown type name 'off_t'
> >   176 |  off_t   uar_mmap_offset;
> >       |  ^~~~~
> > 
> > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> > 
> Thanks. I'll dig some more.

I think the meson version may be the culprit here. In my meson log I don't
see the -std=c11 flag appended to the test compilation command.

Let me downgrade my meson version and see if I can reproduce.

/Bruce

RE: [PATCH v3] build: update DPDK to use C11 standard

[Ali Alnubani]

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Tuesday, August 1, 2023 1:51 PM
> To: David Marchand <david.marchand@redhat.com>
> Cc: Patrick Robb <probb@iol.unh.edu>; Tyler Retzlaff
> <roretzla@linux.microsoft.com>; dev@dpdk.org; Morten Brørup
> <mb@smartsharesystems.com>; NBU-Contact-Thomas Monjalon
> (EXTERNAL) <thomas@monjalon.net>
> Subject: Re: [PATCH v3] build: update DPDK to use C11 standard
> 
> On Tue, Aug 01, 2023 at 11:39:06AM +0100, Bruce Richardson wrote:
> > On Tue, Aug 01, 2023 at 12:35:21PM +0200, David Marchand wrote:
> > > On Tue, Aug 1, 2023 at 12:19 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > >
> > > > On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
> > > > >    Hi Bruce,
> > > > >    I see some failures for this series for our Ubuntu 20.04 containers.
> > <snip>
> > > >
> > > > Hi again,
> > > >
> > > > I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
> > > > everything seems to build ok.
> > > >
> > > > Looking through the logs, though, there does appear to be a difference in
> > > > the configurations in the two cases. I suspect my Ubuntu has an updated
> > > > verbs package compared to the image you are using. In the log of the
> failed
> > > > build, I see:
> > > >
> > > >         Checking whether type "struct mlx4_wqe_lso_seg" has member
> "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> > > >         Configuring mlx4_autoconf.h using configuration
> > > >
> > > > While building in my VM, I have:
> > > >
> > > >         Checking whether type "struct mlx4_wqe_lso_seg" has member
> "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
> > > >         Configuring mlx4_autoconf.h using configuration
> > > >
> > > > So my verbs mlx4 header has got a different set of definitions to those in
> > > > the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev
> package
> > > > version "28.0-1ubuntu1"
> > > >
> > > > Can the CI image be updated to latest 20.04 packages?
> > > >
> > > > /Bruce
> > > >
> > >
> > > I can reproduce the issue seen at UNH, with a 20.04.6 container and
> > > the same libibverbs as you:
> > > ii  libibverbs-dev:amd64               28.0-1ubuntu1
> > >   amd64        Development files for the libibverbs library
> > >
> > > So I suspect something is different in container images..
> > >
> > > Pasting the (hopefully) relevant meson logs:
> > >
> > > Running compile:
> > > Working directory:  /root/dpdk/build/meson-private/tmp0ovvvd9g
> > > Command line:  ccache cc -I/usr/include/libnl3
> > > /root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c -o
> > > /root/dpdk/build/meson-private/tmp0ovvvd9g/output.obj -pipe -c
> > > -D_FILE_OFFSET_BITS=64 -O0 -std=c11
> > >
> > > Code:
> > >  #include <infiniband/mlx4dv.h>
> > >         void bar(void) {
> > >             struct mlx4_wqe_lso_seg foo;
> > >             foo.mss_hdr_size;
> > >
> > >         };
> > > Compiler stdout:
> > >
> > > Compiler stderr:
> > >  In file included from /root/dpdk/build/meson-
> private/tmp0ovvvd9g/testfile.c:1:
> > > /usr/include/infiniband/mlx4dv.h:176:2: error: unknown type name 'off_t'
> > >   176 |  off_t   uar_mmap_offset;
> > >       |  ^~~~~
> > >
> > > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > > "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> > >
> > Thanks. I'll dig some more.
> 
> I think the meson version may be the culprit here. In my meson log I don't
> see the -std=c11 flag appended to the test compilation command.
> 
> Let me downgrade my meson version and see if I can reproduce.
> 
> /Bruce

Hello,

I see two other build failures.

On Ubuntu 20.04 with clang 10 and rdma-core v47.0 (built from source), I see errors similar to these:

drivers/common/mlx5/linux/mlx5_glue.h:58:6: error: redefinition of 'mlx5_ib_uapi_flow_action_packet_reformat_type'
[..]
drivers/common/mlx5/linux/mlx5_glue.h:59:6: error: redefinition of 'mlx5_ib_uapi_flow_table_type'
[..]
drivers/common/mlx5/linux/mlx5_glue.h:121:2: error: redefinition of enumerator 'MLX5DV_DR_ACTION_DEST_REFORMAT'
[..]

On Ubuntu 20.04 while cross compiling for ppc64le with powerpc64le-linux-gnu-gcc 9.4, I see:

[..]
lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration specifiers
[..]
lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is invalid
[..]
error: incompatible types when assigning to type '__vector unsigned char' {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka '__vector(4) __bool int'}
[..]
lib/acl/acl_run_altivec.h:66:4: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_sel'
[..]

Regards,
Ali

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

On Tue, Aug 01, 2023 at 12:42:36PM +0000, Ali Alnubani wrote:
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > Sent: Tuesday, August 1, 2023 1:51 PM
> > To: David Marchand <david.marchand@redhat.com>
> > Cc: Patrick Robb <probb@iol.unh.edu>; Tyler Retzlaff
> > <roretzla@linux.microsoft.com>; dev@dpdk.org; Morten Brørup
> > <mb@smartsharesystems.com>; NBU-Contact-Thomas Monjalon
> > (EXTERNAL) <thomas@monjalon.net>
> > Subject: Re: [PATCH v3] build: update DPDK to use C11 standard
> > 
> > On Tue, Aug 01, 2023 at 11:39:06AM +0100, Bruce Richardson wrote:
> > > On Tue, Aug 01, 2023 at 12:35:21PM +0200, David Marchand wrote:
> > > > On Tue, Aug 1, 2023 at 12:19 PM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:
> > > > >
> > > > > On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
> > > > > >    Hi Bruce,
> > > > > >    I see some failures for this series for our Ubuntu 20.04 containers.
> > > <snip>
> > > > >
> > > > > Hi again,
> > > > >
> > > > > I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
> > > > > everything seems to build ok.
> > > > >
> > > > > Looking through the logs, though, there does appear to be a difference in
> > > > > the configurations in the two cases. I suspect my Ubuntu has an updated
> > > > > verbs package compared to the image you are using. In the log of the
> > failed
> > > > > build, I see:
> > > > >
> > > > >         Checking whether type "struct mlx4_wqe_lso_seg" has member
> > "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> > > > >         Configuring mlx4_autoconf.h using configuration
> > > > >
> > > > > While building in my VM, I have:
> > > > >
> > > > >         Checking whether type "struct mlx4_wqe_lso_seg" has member
> > "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
> > > > >         Configuring mlx4_autoconf.h using configuration
> > > > >
> > > > > So my verbs mlx4 header has got a different set of definitions to those in
> > > > > the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev
> > package
> > > > > version "28.0-1ubuntu1"
> > > > >
> > > > > Can the CI image be updated to latest 20.04 packages?
> > > > >
> > > > > /Bruce
> > > > >
> > > >
> > > > I can reproduce the issue seen at UNH, with a 20.04.6 container and
> > > > the same libibverbs as you:
> > > > ii  libibverbs-dev:amd64               28.0-1ubuntu1
> > > >   amd64        Development files for the libibverbs library
> > > >
> > > > So I suspect something is different in container images..
> > > >
> > > > Pasting the (hopefully) relevant meson logs:
> > > >
> > > > Running compile:
> > > > Working directory:  /root/dpdk/build/meson-private/tmp0ovvvd9g
> > > > Command line:  ccache cc -I/usr/include/libnl3
> > > > /root/dpdk/build/meson-private/tmp0ovvvd9g/testfile.c -o
> > > > /root/dpdk/build/meson-private/tmp0ovvvd9g/output.obj -pipe -c
> > > > -D_FILE_OFFSET_BITS=64 -O0 -std=c11
> > > >
> > > > Code:
> > > >  #include <infiniband/mlx4dv.h>
> > > >         void bar(void) {
> > > >             struct mlx4_wqe_lso_seg foo;
> > > >             foo.mss_hdr_size;
> > > >
> > > >         };
> > > > Compiler stdout:
> > > >
> > > > Compiler stderr:
> > > >  In file included from /root/dpdk/build/meson-
> > private/tmp0ovvvd9g/testfile.c:1:
> > > > /usr/include/infiniband/mlx4dv.h:176:2: error: unknown type name 'off_t'
> > > >   176 |  off_t   uar_mmap_offset;
> > > >       |  ^~~~~
> > > >
> > > > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > > > "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> > > >
> > > Thanks. I'll dig some more.
> > 
> > I think the meson version may be the culprit here. In my meson log I don't
> > see the -std=c11 flag appended to the test compilation command.
> > 
> > Let me downgrade my meson version and see if I can reproduce.
> > 
> > /Bruce
> 
> Hello,
> 
> I see two other build failures.
> 
> On Ubuntu 20.04 with clang 10 and rdma-core v47.0 (built from source), I see errors similar to these:
> 
> drivers/common/mlx5/linux/mlx5_glue.h:58:6: error: redefinition of 'mlx5_ib_uapi_flow_action_packet_reformat_type'
> [..]
> drivers/common/mlx5/linux/mlx5_glue.h:59:6: error: redefinition of 'mlx5_ib_uapi_flow_table_type'
> [..]
> drivers/common/mlx5/linux/mlx5_glue.h:121:2: error: redefinition of enumerator 'MLX5DV_DR_ACTION_DEST_REFORMAT'
> [..]
> 

I believe I have a fix for these. The checks for the various structure
members need the driver "cflags" passed as args to the check, as the
std=c11 means that some things like off_t type are no longer defined (off_t
is posix)

> On Ubuntu 20.04 while cross compiling for ppc64le with powerpc64le-linux-gnu-gcc 9.4, I see:
> 
> [..]
> lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration specifiers
> [..]
> lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is invalid
> [..]
> error: incompatible types when assigning to type '__vector unsigned char' {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka '__vector(4) __bool int'}
> [..]
> lib/acl/acl_run_altivec.h:66:4: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_sel'
> [..]
> 

This I still need to investigate.

In the meantime, I'll do a new version to see if the Ubuntu 20.04 issues
with the mlx drivers goes away with my fix.

/Bruce

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

On Tue, Aug 01, 2023 at 12:42:36PM +0000, Ali Alnubani wrote:
<snip>
> 
> On Ubuntu 20.04 while cross compiling for ppc64le with powerpc64le-linux-gnu-gcc 9.4, I see:
> 
> [..]
> lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration specifiers
> [..]
> lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is invalid
> [..]
> error: incompatible types when assigning to type '__vector unsigned char' {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka '__vector(4) __bool int'}
> [..]
> lib/acl/acl_run_altivec.h:66:4: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_sel'
> [..]
> 
Hi Ali,

where can I get the full log for this error? Is it recorded in patchwork
under a particular test set? I see compile runs for loongarch and
aarch(64), but nothing listed for PPC.

/Bruce

RE: [PATCH v3] build: update DPDK to use C11 standard

[Ali Alnubani]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Tuesday, August 1, 2023 4:22 PM
> To: Ali Alnubani <alialnu@nvidia.com>
> Cc: David Marchand <david.marchand@redhat.com>; Patrick Robb
> <probb@iol.unh.edu>; Tyler Retzlaff <roretzla@linux.microsoft.com>;
> dev@dpdk.org; Morten Brørup <mb@smartsharesystems.com>; NBU-
> Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>
> Subject: Re: [PATCH v3] build: update DPDK to use C11 standard
> 
> On Tue, Aug 01, 2023 at 12:42:36PM +0000, Ali Alnubani wrote:
> <snip>
> >
> > On Ubuntu 20.04 while cross compiling for ppc64le with powerpc64le-linux-
> gnu-gcc 9.4, I see:
> >
> > [..]
> > lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration
> specifiers
> > [..]
> > lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is
> invalid
> > [..]
> > error: incompatible types when assigning to type '__vector unsigned char'
> {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka
> '__vector(4) __bool int'}
> > [..]
> > lib/acl/acl_run_altivec.h:66:4: error: invalid parameter combination for
> AltiVec intrinsic '__builtin_vec_sel'
> > [..]
> >
> Hi Ali,
> 
> where can I get the full log for this error? Is it recorded in patchwork
> under a particular test set? I see compile runs for loongarch and
> aarch(64), but nothing listed for PPC.

Hello Bruce,

I run this build internally. Attaching build log with more info about the environment.

Note: I'm using an out-of-tree cross file because the in-tree one doesn't set binaries.pkgconfig.

[-- Attachment #2: c11_ppc64le_build_log.txt --]
[-- Type: text/plain, Size: 55196 bytes --]

$ meson --werror --buildtype=debugoptimized --cross-file /tmp/ppc64le-power8-linux-gcc -Dexamples=all -Ddisable_drivers=*/cnxk,*/octeontx -Dc_args='-I/opt/cudart' /tmp/build-ppc64-gcc
The Meson build system
Version: 1.2.0
Source dir: /root/dpdk
Build dir: /tmp/build-ppc64-gcc
Build type: cross build
Program cat found: YES (/usr/bin/cat)
Project name: DPDK
Project version: 23.11.0-rc0
C compiler for the host machine: powerpc64le-linux-gnu-gcc (gcc 9.4.0 "powerpc64le-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0")
C linker for the host machine: powerpc64le-linux-gnu-gcc ld.bfd 2.34
C compiler for the build machine: ccache cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0")
C linker for the build machine: cc ld.bfd 2.34
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: ppc64
Host machine cpu: power8
Target machine cpu family: ppc64
Target machine cpu: power8
Message: ## Building in Developer Mode ##
Program pkg-config found: YES (/usr/bin/pkg-config)
Program check-symbols.sh found: YES (/root/dpdk/buildtools/check-symbols.sh)
Program options-ibverbs-static.sh found: YES (/root/dpdk/buildtools/options-ibverbs-static.sh)
Program objdump found: YES (/usr/bin/objdump)
Program python3 found: YES (/usr/bin/python3)
Program cat found: YES (/usr/bin/cat)
Checking for size of "void *" : 8 
Checking for size of "void *" : 8 
Library m found: YES
Library numa found: NO
Library fdt found: NO
Library execinfo found: NO
Has header "execinfo.h" : YES 
Found pkg-config: /usr/bin/powerpc64le-linux-gnu-pkg-config (0.29.1)
Run-time dependency libarchive found: NO (tried pkgconfig)
Run-time dependency libbsd found: NO (tried pkgconfig)
Run-time dependency jansson found: NO (tried pkgconfig)
Run-time dependency openssl found: NO (tried pkgconfig)
Run-time dependency libpcap found: NO (tried pkgconfig)
Library pcap found: NO
Compiler for C supports arguments -Wcast-qual: YES 
Compiler for C supports arguments -Wdeprecated: YES 
Compiler for C supports arguments -Wformat: YES 
Compiler for C supports arguments -Wformat-nonliteral: YES 
Compiler for C supports arguments -Wformat-security: YES 
Compiler for C supports arguments -Wmissing-declarations: YES 
Compiler for C supports arguments -Wmissing-prototypes: YES 
Compiler for C supports arguments -Wnested-externs: YES 
Compiler for C supports arguments -Wold-style-definition: YES 
Compiler for C supports arguments -Wpointer-arith: YES 
Compiler for C supports arguments -Wsign-compare: YES 
Compiler for C supports arguments -Wstrict-prototypes: YES 
Compiler for C supports arguments -Wundef: YES 
Compiler for C supports arguments -Wwrite-strings: YES 
Compiler for C supports arguments -Wno-address-of-packed-member: YES 
Compiler for C supports arguments -Wno-packed-not-aligned: YES 
Compiler for C supports arguments -Wno-missing-field-initializers: YES 
Compiler for C supports arguments -mcpu=power9: YES 
Compiler for C supports arguments -Wno-format-truncation: YES 
Message: lib/kvargs: Defining dependency "kvargs"
Message: lib/telemetry: Defining dependency "telemetry"
Checking for function "getentropy" : NO 
Message: lib/eal: Defining dependency "eal"
Message: lib/ring: Defining dependency "ring"
Message: lib/rcu: Defining dependency "rcu"
Message: lib/mempool: Defining dependency "mempool"
Message: lib/mbuf: Defining dependency "mbuf"
Message: lib/net: Defining dependency "net"
Message: lib/meter: Defining dependency "meter"
Message: lib/ethdev: Defining dependency "ethdev"
Message: lib/pci: Defining dependency "pci"
Message: lib/cmdline: Defining dependency "cmdline"
Message: lib/metrics: Defining dependency "metrics"
Message: lib/hash: Defining dependency "hash"
Message: lib/timer: Defining dependency "timer"
Message: lib/acl: Defining dependency "acl"
Message: lib/bbdev: Defining dependency "bbdev"
Message: lib/bitratestats: Defining dependency "bitratestats"
Run-time dependency libelf found: NO (tried pkgconfig)
lib/bpf/meson.build:36: WARNING: libelf is missing, rte_bpf_elf_load API will be disabled
lib/bpf/meson.build:43: WARNING: libpcap is missing, rte_bpf_convert API will be disabled
Message: lib/bpf: Defining dependency "bpf"
Message: lib/cfgfile: Defining dependency "cfgfile"
Message: lib/compressdev: Defining dependency "compressdev"
Message: lib/cryptodev: Defining dependency "cryptodev"
Message: lib/distributor: Defining dependency "distributor"
Message: lib/efd: Defining dependency "efd"
Message: lib/eventdev: Defining dependency "eventdev"
Message: lib/gpudev: Defining dependency "gpudev"
Message: lib/gro: Defining dependency "gro"
Message: lib/gso: Defining dependency "gso"
Message: lib/ip_frag: Defining dependency "ip_frag"
Message: lib/jobstats: Defining dependency "jobstats"
Message: lib/latencystats: Defining dependency "latencystats"
Message: lib/lpm: Defining dependency "lpm"
Message: lib/member: Defining dependency "member"
Message: lib/pcapng: Defining dependency "pcapng"
Compiler for C supports arguments -Wno-cast-qual: YES 
Message: lib/power: Defining dependency "power"
Message: lib/rawdev: Defining dependency "rawdev"
Message: lib/regexdev: Defining dependency "regexdev"
Message: lib/mldev: Defining dependency "mldev"
Message: lib/dmadev: Defining dependency "dmadev"
Message: lib/rib: Defining dependency "rib"
Message: lib/reorder: Defining dependency "reorder"
Message: lib/sched: Defining dependency "sched"
Message: lib/security: Defining dependency "security"
Message: lib/stack: Defining dependency "stack"
Has header "linux/userfaultfd.h" : YES 
Has header "linux/vduse.h" : NO 
Message: lib/vhost: Defining dependency "vhost"
Message: lib/ipsec: Defining dependency "ipsec"
Message: lib/pdcp: Defining dependency "pdcp"
Message: lib/fib: Defining dependency "fib"
Message: lib/port: Defining dependency "port"
Message: lib/pdump: Defining dependency "pdump"
Message: lib/table: Defining dependency "table"
Message: lib/pipeline: Defining dependency "pipeline"
Message: lib/graph: Defining dependency "graph"
Message: lib/node: Defining dependency "node"
Compiler for C supports arguments -Wno-format-truncation: YES (cached)
Message: drivers/common/cpt: Defining dependency "common_cpt"
Compiler for C supports arguments -Wno-cast-qual: YES (cached)
Compiler for C supports arguments -Wno-pointer-arith: YES 
Message: drivers/common/dpaax: Defining dependency "common_dpaax"
Compiler for C supports arguments -Wno-pointer-to-int-cast: YES 
Message: drivers/common/iavf: Defining dependency "common_iavf"
Message: drivers/common/idpf: Defining dependency "common_idpf"
Run-time dependency libmusdk found: NO (tried pkgconfig)
Message: drivers/bus/auxiliary: Defining dependency "bus_auxiliary"
Message: drivers/bus/cdx: Defining dependency "bus_cdx"
Compiler for C supports arguments -Wno-cast-qual: YES (cached)
Compiler for C supports arguments -Wno-pointer-arith: YES (cached)
Message: drivers/bus/dpaa: Defining dependency "bus_dpaa"
Message: drivers/bus/fslmc: Defining dependency "bus_fslmc"
Message: drivers/bus/ifpga: Defining dependency "bus_ifpga"
Message: drivers/bus/pci: Defining dependency "bus_pci"
Message: drivers/bus/platform: Defining dependency "bus_platform"
Message: drivers/bus/vdev: Defining dependency "bus_vdev"
Message: drivers/bus/vmbus: Defining dependency "bus_vmbus"
Compiler for C supports arguments -std=c11: YES 
Compiler for C supports arguments -Wno-strict-prototypes: YES 
Compiler for C supports arguments -D_BSD_SOURCE: YES 
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES 
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES 
Run-time dependency libmlx5 found: YES 1.24.48.0
Run-time dependency libibverbs found: YES 1.14.48.0
Library mtcr_ul found: NO
Header "infiniband/verbs.h" has symbol "IBV_FLOW_SPEC_ESP" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "IBV_RX_HASH_IPSEC_SPI" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "IBV_ACCESS_RELAXED_ORDERING " with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_create_flow_action_packet_reformat" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "IBV_FLOW_SPEC_MPLS" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "IBV_WQ_FLAGS_PCI_WRITE_END_PADDING" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "IBV_WQ_FLAG_RX_END_PADDING" with dependencies libmlx5, libibverbs: NO 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_query_devx_port" with dependencies libmlx5, libibverbs: NO 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_query_port" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_dest_ib_port" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_devx_obj_create" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_FLOW_ACTION_COUNTERS_DEVX" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_FLOW_ACTION_DEFAULT_MISS" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_devx_obj_query_async" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_devx_qp_query" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_pp_alloc" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_dest_devx_tir" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_devx_get_event" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_flow_meter" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5_MMAP_GET_NC_PAGES_CMD" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_DR_DOMAIN_TYPE_NIC_RX" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_DR_DOMAIN_TYPE_FDB" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_push_vlan" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_alloc_var" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5_OPCODE_ENHANCED_MPSW" with dependencies libmlx5, libibverbs: NO 
Header "infiniband/mlx5dv.h" has symbol "MLX5_OPCODE_SEND_EN" with dependencies libmlx5, libibverbs: NO 
Header "infiniband/mlx5dv.h" has symbol "MLX5_OPCODE_WAIT" with dependencies libmlx5, libibverbs: NO 
Header "infiniband/mlx5dv.h" has symbol "MLX5_OPCODE_ACCESS_ASO" with dependencies libmlx5, libibverbs: NO 
Header "linux/ethtool.h" has symbol "SUPPORTED_40000baseKR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "SUPPORTED_40000baseCR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "SUPPORTED_40000baseSR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "SUPPORTED_40000baseLR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "SUPPORTED_56000baseKR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "SUPPORTED_56000baseCR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "SUPPORTED_56000baseSR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "SUPPORTED_56000baseLR4_Full" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT" with dependencies libmlx5, libibverbs: YES 
Header "linux/ethtool.h" has symbol "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT" with dependencies libmlx5, libibverbs: YES 
Header "linux/if_link.h" has symbol "IFLA_NUM_VF" with dependencies libmlx5, libibverbs: YES 
Header "linux/if_link.h" has symbol "IFLA_EXT_MASK" with dependencies libmlx5, libibverbs: YES 
Header "linux/if_link.h" has symbol "IFLA_PHYS_SWITCH_ID" with dependencies libmlx5, libibverbs: YES 
Header "linux/if_link.h" has symbol "IFLA_PHYS_PORT_NAME" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NL_NLDEV" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NLDEV_CMD_GET" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NLDEV_CMD_PORT_GET" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NLDEV_ATTR_DEV_INDEX" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NLDEV_ATTR_DEV_NAME" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NLDEV_ATTR_PORT_INDEX" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NLDEV_ATTR_PORT_STATE" with dependencies libmlx5, libibverbs: YES 
Header "rdma/rdma_netlink.h" has symbol "RDMA_NLDEV_ATTR_NDEV_INDEX" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dump_dr_domain" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_flow_sampler" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_domain_set_reclaim_device_memory" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_dest_array" with dependencies libmlx5, libibverbs: YES 
Header "linux/devlink.h" has symbol "DEVLINK_GENL_NAME" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_aso" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "INFINIBAND_VERBS_H" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5_WQE_UMR_CTRL_FLAG_INLINE" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dump_dr_rule" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "MLX5DV_DR_ACTION_FLAGS_ASO_CT_DIRECTION_INITIATOR" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_domain_allow_duplicate_rules" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "ibv_reg_mr_iova" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "ibv_import_device" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_dr_action_create_dest_root_table" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/mlx5dv.h" has symbol "mlx5dv_create_steering_anchor" with dependencies libmlx5, libibverbs: YES 
Header "infiniband/verbs.h" has symbol "ibv_is_fork_initialized" with dependencies libmlx5, libibverbs: YES 
Checking whether type "struct mlx5dv_sw_parsing_caps" has member "sw_parsing_offloads" with dependencies libmlx5, libibverbs: YES 
Checking whether type "struct ibv_counter_set_init_attr" has member "counter_set_id" with dependencies libmlx5, libibverbs: NO 
Checking whether type "struct ibv_counters_init_attr" has member "comp_mask" with dependencies libmlx5, libibverbs: YES 
Checking whether type "struct mlx5dv_devx_uar" has member "mmap_off" with dependencies libmlx5, libibverbs: YES 
Checking whether type "struct mlx5dv_flow_matcher_attr" has member "ft_type" with dependencies libmlx5, libibverbs: YES 
Configuring mlx5_autoconf.h using configuration
Message: drivers/common/mlx5: Defining dependency "common_mlx5"
Run-time dependency libcrypto found: NO (tried pkgconfig)
Library IPSec_MB found: NO
Message: drivers/common/qat: Defining dependency "common_qat"
Compiler for C supports arguments -Wdisabled-optimization: YES 
Compiler for C supports arguments -Waggregate-return: YES 
Compiler for C supports arguments -Wbad-function-cast: YES 
Compiler for C supports arguments -Wno-sign-compare: YES 
Compiler for C supports arguments -Wno-unused-parameter: YES 
Compiler for C supports arguments -Wno-unused-variable: YES 
Compiler for C supports arguments -Wno-empty-body: YES 
Compiler for C supports arguments -Wno-unused-but-set-variable: YES 
Message: drivers/mempool/bucket: Defining dependency "mempool_bucket"
Message: drivers/mempool/dpaa: Defining dependency "mempool_dpaa"
Message: drivers/mempool/dpaa2: Defining dependency "mempool_dpaa2"
Message: drivers/mempool/ring: Defining dependency "mempool_ring"
Message: drivers/mempool/stack: Defining dependency "mempool_stack"
Compiler for C supports arguments -Wno-pointer-arith: YES (cached)
Message: drivers/dma/dpaa: Defining dependency "dma_dpaa"
Compiler for C supports arguments -Wno-pointer-arith: YES (cached)
Message: drivers/dma/dpaa2: Defining dependency "dma_dpaa2"
Message: drivers/dma/skeleton: Defining dependency "dma_skeleton"
Message: drivers/net/af_packet: Defining dependency "net_af_packet"
Run-time dependency libxdp found: NO (tried pkgconfig)
Run-time dependency libbpf found: NO (tried pkgconfig)
Library bpf found: NO
Has header "linux/if_xdp.h" : YES 
Message: drivers/net/ark: Defining dependency "net_ark"
Message: drivers/net/atlantic: Defining dependency "net_atlantic"
Message: drivers/net/avp: Defining dependency "net_avp"
Message: drivers/net/axgbe: Defining dependency "net_axgbe"
Run-time dependency zlib found: NO (tried pkgconfig)
Compiler for C supports arguments -DSUPPORT_CFA_HW_ALL=1: YES 
Message: drivers/net/bnxt: Defining dependency "net_bnxt"
Message: drivers/net/bonding: Defining dependency "net_bond"
Message: drivers/net/cpfl: Defining dependency "net_cpfl"
Message: drivers/net/cxgbe: Defining dependency "net_cxgbe"
Compiler for C supports arguments -Wno-pointer-arith: YES (cached)
Message: drivers/net/dpaa: Defining dependency "net_dpaa"
Message: drivers/net/dpaa2: Defining dependency "net_dpaa2"
Compiler for C supports arguments -Wno-uninitialized: YES 
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Compiler for C supports arguments -Wno-unused-variable: YES (cached)
Compiler for C supports arguments -Wno-misleading-indentation: YES 
Compiler for C supports arguments -Wno-implicit-fallthrough: YES 
Message: drivers/net/e1000: Defining dependency "net_e1000"
Message: drivers/net/ena: Defining dependency "net_ena"
Message: drivers/net/enetc: Defining dependency "net_enetc"
Message: drivers/net/enetfec: Defining dependency "net_enetfec"
Fetching value of define "__AVX2__" :  
Compiler for C supports arguments -mavx2: NO 
Message: drivers/net/enic: Defining dependency "net_enic"
Message: drivers/net/failsafe: Defining dependency "net_failsafe"
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Compiler for C supports arguments -Wno-unused-value: YES 
Compiler for C supports arguments -Wno-strict-aliasing: YES 
Compiler for C supports arguments -Wno-format-extra-args: YES 
Compiler for C supports arguments -Wno-unused-variable: YES (cached)
Compiler for C supports arguments -Wno-implicit-fallthrough: YES (cached)
Message: drivers/net/fm10k: Defining dependency "net_fm10k"
Message: drivers/net/gve: Defining dependency "net_gve"
Message: drivers/net/hinic: Defining dependency "net_hinic"
Compiler for C supports arguments -Wno-sign-compare: YES (cached)
Compiler for C supports arguments -Wno-unused-value: YES (cached)
Compiler for C supports arguments -Wno-format: YES 
Compiler for C supports arguments -Wno-format-security: YES 
Compiler for C supports arguments -Wno-format-nonliteral: YES 
Compiler for C supports arguments -Wno-strict-aliasing: YES (cached)
Compiler for C supports arguments -Wno-unused-but-set-variable: YES (cached)
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Message: drivers/net/i40e: Defining dependency "net_i40e"
Message: drivers/net/iavf: Defining dependency "net_iavf"
Compiler for C supports arguments -Wno-unused-value: YES (cached)
Compiler for C supports arguments -Wno-unused-but-set-variable: YES (cached)
Compiler for C supports arguments -Wno-unused-variable: YES (cached)
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Message: drivers/net/ice: Defining dependency "net_ice"
Message: drivers/net/idpf: Defining dependency "net_idpf"
Message: drivers/net/igc: Defining dependency "net_igc"
Message: drivers/net/ionic: Defining dependency "net_ionic"
Compiler for C supports arguments -Wno-unused-value: YES (cached)
Compiler for C supports arguments -Wno-unused-but-set-variable: YES (cached)
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Message: drivers/net/ixgbe: Defining dependency "net_ixgbe"
Message: Disabling kni [drivers/net/kni]: missing internal dependency "kni"
Message: drivers/net/memif: Defining dependency "net_memif"
Run-time dependency libmlx4 found: YES 1.0.48.0
Dependency libibverbs found: YES 1.14.48.0 (cached)
Compiler for C supports arguments -std=c11: YES (cached)
Compiler for C supports arguments -Wno-strict-prototypes: YES (cached)
Compiler for C supports arguments -D_BSD_SOURCE: YES (cached)
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES (cached)
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES (cached)
Header "infiniband/mlx4dv.h" has symbol "MLX4DV_SET_CTX_ATTR_BUF_ALLOCATORS" with dependencies libmlx4, libibverbs: YES 
Header "infiniband/mlx4dv.h" has symbol "MLX4DV_QP_MASK_UAR_MMAP_OFFSET" with dependencies libmlx4, libibverbs: YES 
Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: YES 
Configuring mlx4_autoconf.h using configuration
Message: drivers/net/mlx4: Defining dependency "net_mlx4"
Compiler for C supports arguments -std=c11: YES (cached)
Compiler for C supports arguments -Wno-strict-prototypes: YES (cached)
Compiler for C supports arguments -D_BSD_SOURCE: YES (cached)
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES (cached)
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES (cached)
Message: drivers/net/mlx5: Defining dependency "net_mlx5"
Run-time dependency libmusdk found: NO (tried pkgconfig)
Run-time dependency libmusdk found: NO (tried pkgconfig)
Message: drivers/net/netvsc: Defining dependency "net_netvsc"
Run-time dependency netcope-common found: NO (tried pkgconfig)
Message: drivers/net/nfp: Defining dependency "net_nfp"
Message: drivers/net/ngbe: Defining dependency "net_ngbe"
Message: drivers/net/null: Defining dependency "net_null"
Message: drivers/net/octeon_ep: Defining dependency "net_octeon_ep"
Compiler for C supports arguments -Wno-pointer-arith: YES (cached)
Message: drivers/net/pfe: Defining dependency "net_pfe"
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Compiler for C supports arguments -Wno-sign-compare: YES (cached)
Compiler for C supports arguments -Wno-missing-prototypes: YES 
Compiler for C supports arguments -Wno-cast-qual: YES (cached)
Compiler for C supports arguments -Wno-unused-function: YES 
Compiler for C supports arguments -Wno-unused-variable: YES (cached)
Compiler for C supports arguments -Wno-strict-aliasing: YES (cached)
Compiler for C supports arguments -Wno-missing-prototypes: YES (cached)
Compiler for C supports arguments -Wno-unused-value: YES (cached)
Compiler for C supports arguments -Wno-format-nonliteral: YES (cached)
Compiler for C supports arguments -Wno-shift-negative-value: YES 
Compiler for C supports arguments -Wno-unused-but-set-variable: YES (cached)
Compiler for C supports arguments -Wno-missing-declarations: YES 
Compiler for C supports arguments -Wno-maybe-uninitialized: YES 
Compiler for C supports arguments -Wno-strict-prototypes: YES (cached)
Compiler for C supports arguments -Wno-shift-negative-value: YES (cached)
Compiler for C supports arguments -Wno-implicit-fallthrough: YES (cached)
Compiler for C supports arguments -Wno-format-extra-args: YES (cached)
Compiler for C supports arguments -Wno-visibility: NO 
Compiler for C supports arguments -Wno-empty-body: YES (cached)
Compiler for C supports arguments -Wno-invalid-source-encoding: NO 
Compiler for C supports arguments -Wno-sometimes-uninitialized: NO 
Compiler for C supports arguments -Wno-pointer-bool-conversion: NO 
Compiler for C supports arguments -Wno-format-nonliteral: YES (cached)
Message: drivers/net/qede: Defining dependency "net_qede"
Message: drivers/net/ring: Defining dependency "net_ring"
Message: drivers/net/softnic: Defining dependency "net_softnic"
Header "linux/pkt_cls.h" has symbol "TCA_FLOWER_UNSPEC" : YES 
Header "linux/pkt_cls.h" has symbol "TCA_FLOWER_KEY_VLAN_PRIO" : YES 
Header "linux/pkt_cls.h" has symbol "TCA_BPF_UNSPEC" : YES 
Header "linux/pkt_cls.h" has symbol "TCA_BPF_FD" : YES 
Header "linux/tc_act/tc_bpf.h" has symbol "TCA_ACT_BPF_UNSPEC" : YES 
Header "linux/tc_act/tc_bpf.h" has symbol "TCA_ACT_BPF_FD" : YES 
Configuring tap_autoconf.h using configuration
Message: drivers/net/tap: Defining dependency "net_tap"
Compiler for C supports arguments -fno-prefetch-loop-arrays: YES 
Compiler for C supports arguments -Wno-maybe-uninitialized: YES (cached)
Message: drivers/net/thunderx: Defining dependency "net_thunderx"
Message: drivers/net/txgbe: Defining dependency "net_txgbe"
Compiler for C supports arguments -D_BSD_SOURCE: YES (cached)
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES (cached)
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES (cached)
Message: drivers/net/vdev_netvsc: Defining dependency "net_vdev_netvsc"
Message: drivers/net/vhost: Defining dependency "net_vhost"
Message: drivers/net/virtio: Defining dependency "net_virtio"
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Compiler for C supports arguments -Wno-unused-value: YES (cached)
Compiler for C supports arguments -Wno-strict-aliasing: YES (cached)
Compiler for C supports arguments -Wno-format-extra-args: YES (cached)
Message: drivers/net/vmxnet3: Defining dependency "net_vmxnet3"
Message: Disabling cnxk_bphy [drivers/raw/cnxk_bphy]: missing internal dependency "common_cnxk"
Message: Disabling cnxk_gpio [drivers/raw/cnxk_gpio]: missing internal dependency "common_cnxk"
Message: drivers/raw/dpaa2_cmdif: Defining dependency "raw_dpaa2_cmdif"
Message: drivers/raw/ntb: Defining dependency "raw_ntb"
Message: drivers/raw/skeleton: Defining dependency "raw_skeleton"
Run-time dependency libaarch64crypto found: NO (tried pkgconfig)
Message: drivers/crypto/bcmfs: Defining dependency "crypto_bcmfs"
Message: drivers/crypto/caam_jr: Defining dependency "crypto_caam_jr"
Run-time dependency libcrypto found: NO (tried pkgconfig)
Message: drivers/crypto/dpaa_sec: Defining dependency "crypto_dpaa_sec"
Message: drivers/crypto/dpaa2_sec: Defining dependency "crypto_dpaa2_sec"
Library IPSec_MB found: NO
Compiler for C supports arguments -std=c11: YES (cached)
Compiler for C supports arguments -Wno-strict-prototypes: YES (cached)
Compiler for C supports arguments -D_BSD_SOURCE: YES (cached)
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES (cached)
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES (cached)
Message: drivers/crypto/mlx5: Defining dependency "crypto_mlx5"
Run-time dependency libmusdk found: NO (tried pkgconfig)
Message: drivers/crypto/nitrox: Defining dependency "crypto_nitrox"
Message: drivers/crypto/null: Defining dependency "crypto_null"
Run-time dependency libcrypto found: NO (tried pkgconfig)
Message: drivers/crypto/scheduler: Defining dependency "crypto_scheduler"
Run-time dependency libwd_crypto found: NO (tried pkgconfig)
Run-time dependency libwd found: NO (tried pkgconfig)
Message: drivers/crypto/virtio: Defining dependency "crypto_virtio"
Run-time dependency libisal found: NO (tried pkgconfig)
Compiler for C supports arguments -std=c11: YES (cached)
Compiler for C supports arguments -Wno-strict-prototypes: YES (cached)
Compiler for C supports arguments -D_BSD_SOURCE: YES (cached)
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES (cached)
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES (cached)
Message: drivers/compress/mlx5: Defining dependency "compress_mlx5"
Run-time dependency zlib found: NO (tried pkgconfig)
Compiler for C supports arguments -std=c11: YES (cached)
Compiler for C supports arguments -Wno-strict-prototypes: YES (cached)
Compiler for C supports arguments -D_BSD_SOURCE: YES (cached)
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES (cached)
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES (cached)
Message: drivers/regex/mlx5: Defining dependency "regex_mlx5"
Message: Disabling cn9k [drivers/regex/cn9k]: missing internal dependency "common_cnxk"
Message: drivers/vdpa/ifc: Defining dependency "vdpa_ifc"
Compiler for C supports arguments -std=c11: YES (cached)
Compiler for C supports arguments -Wno-strict-prototypes: YES (cached)
Compiler for C supports arguments -D_BSD_SOURCE: YES (cached)
Compiler for C supports arguments -D_DEFAULT_SOURCE: YES (cached)
Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES (cached)
Message: drivers/vdpa/mlx5: Defining dependency "vdpa_mlx5"
Message: drivers/event/dpaa: Defining dependency "event_dpaa"
Message: drivers/event/dpaa2: Defining dependency "event_dpaa2"
Compiler for C supports arguments -Wno-format-nonliteral: YES (cached)
Message: drivers/event/dsw: Defining dependency "event_dsw"
Message: drivers/event/opdl: Defining dependency "event_opdl"
Message: drivers/event/skeleton: Defining dependency "event_skeleton"
Message: drivers/event/sw: Defining dependency "event_sw"
Message: drivers/baseband/acc: Defining dependency "baseband_acc"
Message: drivers/baseband/fpga_5gnr_fec: Defining dependency "baseband_fpga_5gnr_fec"
Message: drivers/baseband/fpga_lte_fec: Defining dependency "baseband_fpga_lte_fec"
Message: drivers/baseband/la12xx: Defining dependency "baseband_la12xx"
Message: drivers/baseband/null: Defining dependency "baseband_null"
Found CMake: NO
Run-time dependency flexran_sdk_turbo found: NO (tried pkgconfig and cmake)
Run-time dependency flexran_sdk_ldpc_decoder_5gnr found: NO (tried pkgconfig and cmake)
Message: drivers/baseband/turbo_sw: Defining dependency "baseband_turbo_sw"
Has header "cuda.h" : YES 
Has header "cudaTypedefs.h" : YES 
Has header "gdrapi.h" : NO 
Message: drivers/gpu/cuda: Defining dependency "gpu_cuda"
Compiler for C supports arguments -Wno-format-truncation: YES (cached)
Run-time dependency zlib found: NO (tried pkgconfig)
Message: hugepage availability: false
Program test_telemetry.sh found: YES (/root/dpdk/app/test/test_telemetry.sh)
Program doxygen found: YES (/usr/bin/doxygen)
Configuring doxy-api.conf using configuration
Program sphinx-build found: YES (/usr/bin/sphinx-build)
Compiler for C supports arguments -Wno-format-truncation: YES (cached)
Message: Missing dependency "flow_classify" for example "flow_classify"
Message: Skipping example "flow_classify"
Has header "sys/epoll.h" : YES 
Library pqos found: NO
Message: Skipping example "l2fwd-cat"
Library rt found: YES
Has header "sys/epoll.h" : YES (cached)
Has header "linux/virtio_blk.h" : YES 
Library virt found: NO
Run-time dependency jansson found: NO (tried pkgconfig)
Message: Skipping example "vm_power_manager"
Library virt found: NO
Message: Skipping example "guest_cli"
Configuring rte_build_config.h using configuration
Message: 
=================
Applications Enabled
=================

apps:
	pdump, proc-info, test-acl, test-bbdev, test-cmdline, test-compress-perf, test-crypto-perf, test-dma-perf, 
	test-eventdev, test-fib, test-flow-perf, test-gpudev, test-mldev, test-pipeline, test-pmd, test-regex, 
	test-sad, test-security-perf, 

Message: 
=================
Libraries Enabled
=================

libs:
	kvargs, telemetry, eal, ring, rcu, mempool, mbuf, net, 
	meter, ethdev, pci, cmdline, metrics, hash, timer, acl, 
	bbdev, bitratestats, bpf, cfgfile, compressdev, cryptodev, distributor, efd, 
	eventdev, gpudev, gro, gso, ip_frag, jobstats, latencystats, lpm, 
	member, pcapng, power, rawdev, regexdev, mldev, dmadev, rib, 
	reorder, sched, security, stack, vhost, ipsec, pdcp, fib, 
	port, pdump, table, pipeline, graph, node, 

Message: 
===============
Drivers Enabled
===============

common:
	cpt, dpaax, iavf, idpf, mlx5, qat, 
bus:
	auxiliary, cdx, dpaa, fslmc, ifpga, pci, platform, vdev, 
	vmbus, 
mempool:
	bucket, dpaa, dpaa2, ring, stack, 
dma:
	dpaa, dpaa2, skeleton, 
net:
	af_packet, ark, atlantic, avp, axgbe, bnxt, bond, cpfl, 
	cxgbe, dpaa, dpaa2, e1000, ena, enetc, enetfec, enic, 
	failsafe, fm10k, gve, hinic, i40e, iavf, ice, idpf, 
	igc, ionic, ixgbe, memif, mlx4, mlx5, netvsc, nfp, 
	ngbe, null, octeon_ep, pfe, qede, ring, softnic, tap, 
	thunderx, txgbe, vdev_netvsc, vhost, virtio, vmxnet3, 
raw:
	dpaa2_cmdif, ntb, skeleton, 
crypto:
	bcmfs, caam_jr, dpaa_sec, dpaa2_sec, mlx5, nitrox, null, scheduler, 
	virtio, 
compress:
	mlx5, 
regex:
	mlx5, 
ml:
	
vdpa:
	ifc, mlx5, 
event:
	dpaa, dpaa2, dsw, opdl, skeleton, sw, 
baseband:
	acc, fpga_5gnr_fec, fpga_lte_fec, la12xx, null, turbo_sw, 
gpu:
	cuda, 

Message: 
=================
Content Skipped
=================

apps:
	dumpcap:	missing dependency, "libpcap"
	
libs:
	kni:	explicitly disabled via build config (deprecated lib)
	flow_classify:	explicitly disabled via build config (deprecated lib)
	
drivers:
	common/mvep:	missing dependency, "libmusdk"
	common/octeontx:	explicitly disabled via build config
	common/cnxk:	explicitly disabled via build config
	crypto/qat:	missing dependency, libipsecmb or libcrypto
	common/sfc_efx:	only supported on x86_64 and aarch64
	mempool/cnxk:	explicitly disabled via build config
	mempool/octeontx:	explicitly disabled via build config
	dma/cnxk:	explicitly disabled via build config
	dma/hisilicon:	only supported on x86_64 and aarch64
	dma/idxd:	only supported on x86
	dma/ioat:	only supported on x86
	net/af_xdp:	missing dependency, "libxdp >=1.2.2" and "libbpf"
	net/bnx2x:	missing dependency, "zlib"
	net/cnxk:	explicitly disabled via build config
	net/hns3:	only supported on x86_64 and aarch64
	net/ipn3ke:	missing dependency, "libfdt"
	net/kni:	missing internal dependency, "kni" (deprecated lib)
	net/mana:	only supported on x86_64 Linux
	net/mvneta:	missing dependency, "libmusdk"
	net/mvpp2:	missing dependency, "libmusdk"
	net/nfb:	missing dependency, "libnfb"
	net/octeontx:	explicitly disabled via build config
	net/pcap:	missing dependency, "libpcap"
	net/sfc:	only supported on x86_64 and aarch64
	raw/cnxk_bphy:	missing internal dependency, "common_cnxk"
	raw/cnxk_gpio:	missing internal dependency, "common_cnxk"
	raw/ifpga:	missing dependency, "libfdt"
	crypto/armv8:	missing dependency, "libAArch64crypto"
	crypto/ccp:	missing dependency, "libcrypto"
	crypto/cnxk:	explicitly disabled via build config
	crypto/ipsec_mb:	missing dependency, "libIPSec_MB"
	crypto/mvsam:	missing dependency, "libmusdk"
	crypto/octeontx:	explicitly disabled via build config
	crypto/openssl:	missing dependency, "libcrypto"
	crypto/uadk:	missing dependency, "libwd"
	compress/isal:	missing dependency, "libisal"
	compress/octeontx:	explicitly disabled via build config
	compress/zlib:	missing dependency, "zlib"
	regex/cn9k:	missing internal dependency, "common_cnxk"
	ml/cnxk:	explicitly disabled via build config
	vdpa/sfc:	only supported on x86_64 and aarch64
	event/cnxk:	explicitly disabled via build config
	event/dlb2:	only supported on x86_64 Linux
	event/octeontx:	explicitly disabled via build config
	

Build targets in project: 671
NOTICE: Future-deprecated features used:
 * 0.58.0: {'meson.get_cross_property'}

DPDK 23.11.0-rc0

  User defined options
    Cross files    : /tmp/ppc64le-power8-linux-gcc
    buildtype      : debugoptimized
    werror         : True
    c_args         : -I/opt/cudart
    disable_drivers: */cnxk,*/octeontx
    examples       : all

Found ninja-1.10.0 at /usr/bin/ninja
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.

$ ninja -C /tmp/build-ppc64-gcc
ninja: Entering directory `/tmp/build-ppc64-gcc'
[1/2330] Compiling C object lib/librte_eal.a.p/eal_ppc_rte_hypervisor.c.o
[2/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_hypervisor.c.o
[3/2330] Compiling C object lib/librte_eal.a.p/eal_common_rte_version.c.o
[4/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_errno.c.o
[5/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_class.c.o
[6/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_cpuflags.c.o
[7/2330] Compiling C object lib/librte_eal.a.p/eal_common_rte_reciprocal.c.o
[8/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_hexdump.c.o
[9/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_log.c.o
[10/2330] Compiling C object lib/librte_eal.a.p/eal_unix_eal_unix_timer.c.o
[11/2330] Compiling C object lib/librte_eal.a.p/eal_ppc_rte_power_intrinsics.c.o
[12/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_debug.c.o
[13/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_uuid.c.o
[14/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_cpuflags.c.o
[15/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_string_fns.c.o
[16/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_timer.c.o
[17/2330] Compiling C object lib/librte_kvargs.a.p/kvargs_rte_kvargs.c.o
[18/2330] Linking static target lib/librte_kvargs.a
[19/2330] Compiling C object lib/librte_eal.a.p/eal_ppc_rte_cycles.c.o
[20/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_config.c.o
[21/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_timer.c.o
[22/2330] Compiling C object lib/librte_eal.a.p/eal_unix_eal_unix_thread.c.o
[23/2330] Compiling C object lib/librte_telemetry.a.p/telemetry_telemetry_data.c.o
[24/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_tailqs.c.o
[25/2330] Compiling C object lib/librte_eal.a.p/eal_unix_eal_debug.c.o
[26/2330] Compiling C object lib/librte_eal.a.p/eal_unix_eal_unix_memory.c.o
[27/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_launch.c.o
[28/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_bus.c.o
[29/2330] Compiling C object lib/librte_eal.a.p/eal_common_rte_keepalive.c.o
[30/2330] Compiling C object lib/librte_eal.a.p/eal_unix_eal_firmware.c.o
[31/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_thread.c.o
[32/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_vfio_mp_sync.c.o
[33/2330] Compiling C object lib/librte_eal.a.p/eal_common_rte_random.c.o
[34/2330] Compiling C object lib/librte_eal.a.p/eal_unix_eal_file.c.o
[35/2330] Compiling C object lib/librte_telemetry.a.p/telemetry_telemetry_legacy.c.o
[36/2330] Compiling C object lib/librte_eal.a.p/eal_ppc_rte_cpuflags.c.o
[37/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_mcfg.c.o
[38/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_lcore.c.o
[39/2330] Compiling C object lib/librte_eal.a.p/eal_unix_eal_filesystem.c.o
[40/2330] Compiling C object lib/librte_eal.a.p/eal_unix_rte_thread.c.o
[41/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_trace_ctf.c.o
[42/2330] Compiling C object lib/librte_ring.a.p/ring_rte_ring.c.o
[43/2330] Compiling C object lib/librte_eal.a.p/eal_common_malloc_elem.c.o
[44/2330] Compiling C object lib/librte_eal.a.p/eal_common_hotplug_mp.c.o
[45/2330] Linking static target lib/librte_ring.a
[46/2330] Compiling C object lib/librte_mempool.a.p/mempool_rte_mempool_ops_default.c.o
[47/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_memalloc.c.o
[48/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_interrupts.c.o
[49/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_log.c.o
[50/2330] Compiling C object lib/librte_net.a.p/net_rte_net_crc.c.o
[51/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_dynmem.c.o
[52/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_alarm.c.o
[53/2330] Compiling C object lib/librte_mbuf.a.p/mbuf_rte_mbuf_pool_ops.c.o
[54/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_trace_points.c.o
[55/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_memzone.c.o
[56/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_devargs.c.o
[57/2330] Compiling C object lib/librte_mbuf.a.p/mbuf_rte_mbuf_ptype.c.o
[58/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_trace.c.o
[59/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_thread.c.o
[60/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_trace_utils.c.o
[61/2330] Compiling C object lib/librte_mempool.a.p/mempool_rte_mempool_ops.c.o
[62/2330] Generating lib/kvargs.sym_chk with a custom command (wrapped by meson to capture output)
[63/2330] Compiling C object lib/librte_eal.a.p/eal_common_malloc_mp.c.o
[64/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_dev.c.o
[65/2330] Compiling C object lib/librte_net.a.p/net_rte_ether.c.o
[66/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_dev.c.o
[67/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_vt100.c.o
[68/2330] Compiling C object lib/librte_mempool.a.p/mempool_mempool_trace_points.c.o
[69/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_hugepage_info.c.o
[70/2330] Compiling C object lib/librte_meter.a.p/meter_rte_meter.c.o
[71/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_lcore.c.o
[72/2330] Linking target lib/librte_kvargs.so.24.0
[73/2330] Linking static target lib/librte_meter.a
[74/2330] Compiling C object lib/librte_power.a.p/power_power_common.c.o
[75/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_parse_portlist.c.o
[76/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_parse_string.c.o
[77/2330] Compiling C object lib/librte_pci.a.p/pci_rte_pci.c.o
[78/2330] Linking static target lib/librte_pci.a
[79/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline.c.o
[80/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_parse_num.c.o
[81/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_socket.c.o
[82/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_cirbuf.c.o
[83/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_os_unix.c.o
[84/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_parse_etheraddr.c.o
[85/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_ethdev_profile.c.o
[86/2330] Compiling C object lib/librte_eal.a.p/eal_common_rte_malloc.c.o
[87/2330] Generating symbol file lib/librte_kvargs.so.24.0.p/librte_kvargs.so.24.0.symbols
[88/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_parse.c.o
[89/2330] Compiling C object lib/librte_mbuf.a.p/mbuf_rte_mbuf_dyn.c.o
[90/2330] Compiling C object lib/librte_net.a.p/net_rte_net.c.o
[91/2330] Compiling C object lib/librte_net.a.p/net_rte_arp.c.o
[92/2330] Compiling C object lib/librte_eal.a.p/eal_common_malloc_heap.c.o
[93/2330] Linking static target lib/librte_net.a
[94/2330] Compiling C object lib/librte_acl.a.p/acl_acl_run_altivec.c.o
FAILED: lib/librte_acl.a.p/acl_acl_run_altivec.c.o 
powerpc64le-linux-gnu-gcc -Ilib/librte_acl.a.p -Ilib -I../../root/dpdk/lib -Ilib/acl -I../../root/dpdk/lib/acl -I. -I../../root/dpdk -Iconfig -I../../root/dpdk/config -Ilib/eal/include -I../../root/dpdk/lib/eal/include -Ilib/eal/linux/include -I../../root/dpdk/lib/eal/linux/include -Ilib/eal/ppc/include -I../../root/dpdk/lib/eal/ppc/include -Ilib/eal/common -I../../root/dpdk/lib/eal/common -Ilib/eal -I../../root/dpdk/lib/eal -Ilib/kvargs -I../../root/dpdk/lib/kvargs -Ilib/metrics -I../../root/dpdk/lib/metrics -Ilib/telemetry -I../../root/dpdk/lib/telemetry -I/opt/cudart -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O2 -g -include rte_config.h -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -mcpu=power8 -mtune=power8 -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation -DRTE_LOG_DEFAULT_LOGTYPE=lib.acl -MD -MQ lib/librte_acl.a.p/acl_acl_run_altivec.c.o -MF lib/librte_acl.a.p/acl_acl_run_altivec.c.o.d -o lib/librte_acl.a.p/acl_acl_run_altivec.c.o -c ../../root/dpdk/lib/acl/acl_run_altivec.c
In file included from ../../root/dpdk/lib/acl/acl_run_altivec.c:6:
../../root/dpdk/lib/acl/acl_run_altivec.h: In function 'resolve_priority_altivec':
../../root/dpdk/lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration specifiers
   44 |  __vector bool int selector;
      |                ^~~
../../root/dpdk/lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is invalid
   44 |  __vector bool int selector;
      |  ^~~~~~~~
../../root/dpdk/lib/acl/acl_run_altivec.h:65:4: note: use '-flax-vector-conversions' to permit conversions between vectors with differing element types or numbers of subparts
   65 |    selector = vec_cmpgt(priority1, priority);
      |    ^~~~~~~~
In file included from ../../root/dpdk/lib/eal/ppc/include/rte_altivec.h:10,
                 from ../../root/dpdk/lib/eal/ppc/include/rte_vect.h:9,
                 from ../../root/dpdk/lib/acl/rte_acl_osdep.h:37,
                 from ../../root/dpdk/lib/acl/rte_acl.h:14,
                 from ../../root/dpdk/lib/acl/acl_run.h:8,
                 from ../../root/dpdk/lib/acl/acl_run_altivec.h:6,
                 from ../../root/dpdk/lib/acl/acl_run_altivec.c:6:
../../root/dpdk/lib/acl/acl_run_altivec.h:65:15: error: incompatible types when assigning to type '__vector unsigned char' {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka '__vector(4) __bool int'}
   65 |    selector = vec_cmpgt(priority1, priority);
      |               ^~~~~~~~~
In file included from ../../root/dpdk/lib/acl/acl_run_altivec.c:6:
../../root/dpdk/lib/acl/acl_run_altivec.h:66:4: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_sel'
   66 |    results = vec_sel(results, results1, selector);
      |    ^~~~~~~
../../root/dpdk/lib/acl/acl_run_altivec.h:68:5: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_sel'
   68 |     selector);
      |     ^~~~~~~~
../../root/dpdk/lib/acl/acl_run_altivec.h: In function 'transition4':
../../root/dpdk/lib/acl/acl_run_altivec.h:113:16: error: two or more data types in declaration specifiers
  113 |  __vector bool int dfa_msk;
      |                ^~~
../../root/dpdk/lib/acl/acl_run_altivec.h:113:2: error: use of boolean types in AltiVec types is invalid
  113 |  __vector bool int dfa_msk;
      |  ^~~~~~~~
In file included from ../../root/dpdk/lib/eal/ppc/include/rte_altivec.h:10,
                 from ../../root/dpdk/lib/eal/ppc/include/rte_vect.h:9,
                 from ../../root/dpdk/lib/acl/rte_acl_osdep.h:37,
                 from ../../root/dpdk/lib/acl/rte_acl.h:14,
                 from ../../root/dpdk/lib/acl/acl_run.h:8,
                 from ../../root/dpdk/lib/acl/acl_run_altivec.h:6,
                 from ../../root/dpdk/lib/acl/acl_run_altivec.c:6:
../../root/dpdk/lib/acl/acl_run_altivec.h:137:12: error: incompatible types when assigning to type '__vector unsigned char' {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka '__vector(4) __bool int'}
  137 |  dfa_msk = vec_cmpeq(node_type, t);
      |            ^~~~~~~~~
In file included from ../../root/dpdk/lib/acl/acl_run_altivec.c:6:
../../root/dpdk/lib/acl/acl_run_altivec.h:167:2: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_sel'
  167 |  t = vec_sel(quad_ofs, dfa_ofs, dfa_msk);
      |  ^
[95/2330] Generating lib/ring.sym_chk with a custom command (wrapped by meson to capture output)
[96/2330] Compiling C object lib/librte_acl.a.p/acl_tb_mem.c.o
[97/2330] Compiling C object lib/librte_hash.a.p/hash_rte_fbk_hash.c.o
[98/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_fbarray.c.o
[99/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_parse_ipaddr.c.o
[100/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_rte_class_eth.c.o
[101/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_sff_telemetry.c.o
[102/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_sff_8472.c.o
[103/2330] Generating lib/pci.sym_chk with a custom command (wrapped by meson to capture output)
[104/2330] Compiling C object lib/librte_metrics.a.p/metrics_rte_metrics.c.o
[105/2330] Compiling C object lib/librte_eal.a.p/eal_common_rte_service.c.o
[106/2330] Generating lib/meter.sym_chk with a custom command (wrapped by meson to capture output)
[107/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_memory.c.o
[108/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_ethdev_private.c.o
[109/2330] Compiling C object lib/librte_bpf.a.p/bpf_bpf_load.c.o
[110/2330] Compiling C object lib/librte_metrics.a.p/metrics_rte_metrics_telemetry.c.o
[111/2330] Compiling C object lib/librte_bpf.a.p/bpf_bpf_stub.c.o
[112/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal.c.o
[113/2330] Compiling C object lib/librte_bpf.a.p/bpf_bpf.c.o
[114/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_proc.c.o
[115/2330] Compiling C object lib/librte_bpf.a.p/bpf_bpf_dump.c.o
[116/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_interrupts.c.o
[117/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_ethdev_driver.c.o
[118/2330] Compiling C object lib/librte_distributor.a.p/distributor_rte_distributor_match_generic.c.o
[119/2330] Compiling C object lib/librte_acl.a.p/acl_rte_acl.c.o
[120/2330] Compiling C object lib/librte_compressdev.a.p/compressdev_rte_compressdev_pmd.c.o
[121/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_memory.c.o
[122/2330] Generating lib/net.sym_chk with a custom command (wrapped by meson to capture output)
[123/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_rte_ethdev_cman.c.o
[124/2330] Compiling C object lib/librte_eventdev.a.p/eventdev_eventdev_private.c.o
[125/2330] Compiling C object lib/librte_bitratestats.a.p/bitratestats_rte_bitrate.c.o
[126/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_sff_8079.c.o
[127/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o
[128/2330] Compiling C object lib/librte_cryptodev.a.p/cryptodev_cryptodev_pmd.c.o
[129/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_sff_common.c.o
[130/2330] Compiling C object lib/librte_mempool.a.p/mempool_rte_mempool.c.o
[131/2330] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline_rdline.c.o
[132/2330] Compiling C object lib/librte_acl.a.p/acl_acl_gen.c.o
[133/2330] Compiling C object lib/librte_compressdev.a.p/compressdev_rte_comp.c.o
[134/2330] Compiling C object lib/librte_cfgfile.a.p/cfgfile_rte_cfgfile.c.o
[135/2330] Compiling C object lib/librte_acl.a.p/acl_acl_run_scalar.c.o
[136/2330] Compiling C object lib/librte_eal.a.p/eal_linux_eal_vfio.c.o
[137/2330] Compiling C object lib/librte_timer.a.p/timer_rte_timer.c.o
[138/2330] Compiling C object lib/librte_eventdev.a.p/eventdev_rte_event_ring.c.o
[139/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_sff_8636.c.o
[140/2330] Compiling C object lib/librte_compressdev.a.p/compressdev_rte_compressdev.c.o
[141/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_rte_ethdev_telemetry.c.o
[142/2330] Compiling C object lib/librte_distributor.a.p/distributor_rte_distributor_single.c.o
[143/2330] Compiling C object lib/librte_rcu.a.p/rcu_rte_rcu_qsbr.c.o
[144/2330] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_options.c.o
[145/2330] Compiling C object lib/librte_hash.a.p/hash_rte_thash.c.o
[146/2330] Compiling C object lib/librte_bpf.a.p/bpf_bpf_exec.c.o
[147/2330] Compiling C object lib/librte_distributor.a.p/distributor_rte_distributor.c.o
[148/2330] Compiling C object lib/librte_bbdev.a.p/bbdev_rte_bbdev.c.o
[149/2330] Compiling C object lib/librte_acl.a.p/acl_acl_bld.c.o
[150/2330] Compiling C object lib/librte_cryptodev.a.p/cryptodev_cryptodev_trace_points.c.o
[151/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_rte_mtr.c.o
[152/2330] Compiling C object lib/librte_telemetry.a.p/telemetry_telemetry.c.o
[153/2330] Compiling C object lib/librte_bpf.a.p/bpf_bpf_validate.c.o
[154/2330] Compiling C object lib/librte_bpf.a.p/bpf_bpf_pkt.c.o
[155/2330] Compiling C object lib/librte_eventdev.a.p/eventdev_eventdev_trace_points.c.o
[156/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_rte_tm.c.o
[157/2330] Compiling C object lib/librte_mbuf.a.p/mbuf_rte_mbuf.c.o
[158/2330] Compiling C object lib/librte_efd.a.p/efd_rte_efd.c.o
[159/2330] Compiling C object lib/librte_eventdev.a.p/eventdev_rte_event_timer_adapter.c.o
[160/2330] Compiling C object lib/librte_eventdev.a.p/eventdev_rte_event_crypto_adapter.c.o
[161/2330] Compiling C object lib/librte_eventdev.a.p/eventdev_rte_event_eth_tx_adapter.c.o
[162/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_rte_flow.c.o
[163/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_ethdev_trace_points.c.o
[164/2330] Compiling C object lib/librte_hash.a.p/hash_rte_cuckoo_hash.c.o
[165/2330] Compiling C object lib/librte_cryptodev.a.p/cryptodev_rte_cryptodev.c.o
[166/2330] Compiling C object lib/librte_eventdev.a.p/eventdev_rte_event_eth_rx_adapter.c.o
[167/2330] Compiling C object lib/librte_ethdev.a.p/ethdev_rte_ethdev.c.o
ninja: build stopped: subcommand failed.


Cross-file (/tmp/ppc64le-power8-linux-gcc):
"""
[binaries]
c = 'powerpc64le-linux-gnu-gcc'
cpp = 'powerpc64le-linux-gnu-cpp'
ar = 'powerpc64le-linux-gnu-gcc-ar'
strip = 'powerpc64le-linux-gnu-strip'
pkgconfig = 'powerpc64le-linux-gnu-pkg-config'

[host_machine]
system = 'linux'
cpu_family = 'ppc64'
cpu = 'power8'
endian = 'little'
"""

OS: Ubuntu 20.04.6 LTS
Compiler: powerpc64le-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
rdma-core: v47.0

Environment:
  CC=gcc
  PKG_CONFIG_PATH=:/opt/rdma-core/build-ppc64/lib/pkgconfig

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

+David Christensen

On Tue, Aug 01, 2023 at 01:47:19PM +0000, Ali Alnubani wrote:
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > Sent: Tuesday, August 1, 2023 4:22 PM
> > To: Ali Alnubani <alialnu@nvidia.com>
> > Cc: David Marchand <david.marchand@redhat.com>; Patrick Robb
> > <probb@iol.unh.edu>; Tyler Retzlaff <roretzla@linux.microsoft.com>;
> > dev@dpdk.org; Morten Brørup <mb@smartsharesystems.com>; NBU-
> > Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>
> > Subject: Re: [PATCH v3] build: update DPDK to use C11 standard
> > 
> > On Tue, Aug 01, 2023 at 12:42:36PM +0000, Ali Alnubani wrote:
> > <snip>
> > >
> > > On Ubuntu 20.04 while cross compiling for ppc64le with powerpc64le-linux-
> > gnu-gcc 9.4, I see:
> > >
> > > [..]
> > > lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration
> > specifiers
> > > [..]
> > > lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is
> > invalid
> > > [..]
> > > error: incompatible types when assigning to type '__vector unsigned char'
> > {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka
> > '__vector(4) __bool int'}
> > > [..]
> > > lib/acl/acl_run_altivec.h:66:4: error: invalid parameter combination for
> > AltiVec intrinsic '__builtin_vec_sel'
> > > [..]
> > >
> > Hi Ali,
> > 
> > where can I get the full log for this error? Is it recorded in patchwork
> > under a particular test set? I see compile runs for loongarch and
> > aarch(64), but nothing listed for PPC.
> 
> Hello Bruce,
> 
> I run this build internally. Attaching build log with more info about the environment.
> 
> Note: I'm using an out-of-tree cross file because the in-tree one doesn't set binaries.pkgconfig.

<snip>

> In file included from ../../root/dpdk/lib/acl/acl_run_altivec.c:6:
> ../../root/dpdk/lib/acl/acl_run_altivec.h: In function 'resolve_priority_altivec':
> ../../root/dpdk/lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration specifiers
>    44 |  __vector bool int selector;
>       |                ^~~
> ../../root/dpdk/lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is invalid
>    44 |  __vector bool int selector;
>       |  ^~~~~~~~

I don't know anything about altivec, unfortunately, and the use of "bool
int" together looks very strange. Adding PPC maintainer to thread.

David, can you perhaps help out with these issues?

Thanks,
/Bruce

Re: [PATCH v3] build: update DPDK to use C11 standard

[Bruce Richardson]

On Tue, Aug 01, 2023 at 03:00:06PM +0100, Bruce Richardson wrote:
> +David Christensen
> 
> On Tue, Aug 01, 2023 at 01:47:19PM +0000, Ali Alnubani wrote:
> > > -----Original Message-----
> > > From: Bruce Richardson <bruce.richardson@intel.com>
> > > Sent: Tuesday, August 1, 2023 4:22 PM
> > > To: Ali Alnubani <alialnu@nvidia.com>
> > > Cc: David Marchand <david.marchand@redhat.com>; Patrick Robb
> > > <probb@iol.unh.edu>; Tyler Retzlaff <roretzla@linux.microsoft.com>;
> > > dev@dpdk.org; Morten Brørup <mb@smartsharesystems.com>; NBU-
> > > Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>
> > > Subject: Re: [PATCH v3] build: update DPDK to use C11 standard
> > > 
> > > On Tue, Aug 01, 2023 at 12:42:36PM +0000, Ali Alnubani wrote:
> > > <snip>
> > > >
> > > > On Ubuntu 20.04 while cross compiling for ppc64le with powerpc64le-linux-
> > > gnu-gcc 9.4, I see:
> > > >
> > > > [..]
> > > > lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration
> > > specifiers
> > > > [..]
> > > > lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is
> > > invalid
> > > > [..]
> > > > error: incompatible types when assigning to type '__vector unsigned char'
> > > {aka '__vector(16) unsigned char'} from type '__vector __bool int' {aka
> > > '__vector(4) __bool int'}
> > > > [..]
> > > > lib/acl/acl_run_altivec.h:66:4: error: invalid parameter combination for
> > > AltiVec intrinsic '__builtin_vec_sel'
> > > > [..]
> > > >
> > > Hi Ali,
> > > 
> > > where can I get the full log for this error? Is it recorded in patchwork
> > > under a particular test set? I see compile runs for loongarch and
> > > aarch(64), but nothing listed for PPC.
> > 
> > Hello Bruce,
> > 
> > I run this build internally. Attaching build log with more info about the environment.
> > 
> > Note: I'm using an out-of-tree cross file because the in-tree one doesn't set binaries.pkgconfig.
> 
> <snip>
> 
> > In file included from ../../root/dpdk/lib/acl/acl_run_altivec.c:6:
> > ../../root/dpdk/lib/acl/acl_run_altivec.h: In function 'resolve_priority_altivec':
> > ../../root/dpdk/lib/acl/acl_run_altivec.h:44:16: error: two or more data types in declaration specifiers
> >    44 |  __vector bool int selector;
> >       |                ^~~
> > ../../root/dpdk/lib/acl/acl_run_altivec.h:44:2: error: use of boolean types in AltiVec types is invalid
> >    44 |  __vector bool int selector;
> >       |  ^~~~~~~~
> 
> I don't know anything about altivec, unfortunately, and the use of "bool
> int" together looks very strange. Adding PPC maintainer to thread.
> 
> David, can you perhaps help out with these issues?
>
Doing some google searching throws up this patch which looks relevant:
https://patches.dpdk.org/project/dpdk/patch/20180830115504.28608-1-christian.ehrhardt@canonical.com/

Re: [PATCH v3] build: update DPDK to use C11 standard

[Thomas Monjalon]

01/08/2023 12:19, Bruce Richardson:
> On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
> >    Hi Bruce,
> >    I see some failures for this series for our Ubuntu 20.04 containers.
> >    And, our DTS testbeds which are on ubuntu 20.04 are skipping running
> >    testsuites because they can't compile DPDK. So, that's why it has some
> >    missing results for a couple of the Intel NICs. For context, I'll paste
> >    below where the compile job terminates in one of our containerized
> >    compile test runs. The GCC in use here is version 9.4, so it meets the
> >    requirements as described in your patch as far as I can tell. I'll
> >    check it out more tomorrow to see whether it's an infra failure, like
> >    some missing dependencies. Please let me know if we expect to have no
> >    issues with 20.04 or if this is anticipated.
> >    Thanks!
> >    [1638/2730] Generating symbol file
> >    'drivers/a715181@@rte_net_ixgbe@sha/librte_net_ixgbe.so.24.0.symbols'.
> >    [1639/2730] Compiling C object
> >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o'.
> >    FAILED: drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o
> >    ccache cc -Idrivers/a715181@@tmp_rte_net_mlx4@sta -Idrivers
> >    -I../drivers -Idrivers/net/mlx4 -I../drivers/net/mlx4 -Ilib/ethdev
> >    -I../lib/ethdev -I. -I../ -Iconfig -I../config -Ilib/eal/include
> >    -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include
> >    -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common
> >    -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs
> >    -Ilib/telemetry/../metrics -I../lib/telemetry/../metrics
> >    -Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
> >    -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
> >    -Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
> >    -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev
> >    -I../drivers/bus/vdev -I/usr/include/libnl3 -fdiagnostics-color=always
> >    -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror
> >    -std=c11 -O3 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
> >    -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> >    -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> >    -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> >    -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
> >    -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
> >    -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
> >    -std=c11 -Wno-strict-prototypes -D_BSD_SOURCE -D_DEFAULT_SOURCE
> >    -D_XOPEN_SOURCE=600 -UPEDANTIC -DRTE_LOG_DEFAULT_LOGTYPE=pmd.net.mlx4
> >    -MD -MQ 'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -MF
> >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o.d' -o
> >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -c
> >    ../drivers/net/mlx4/mlx4.c
> >    In file included from ../drivers/net/mlx4/mlx4_rxtx.h:27,
> >                     from ../drivers/net/mlx4/mlx4.c:49:
> >    ../drivers/net/mlx4/mlx4_prm.h:111:8: error: redefinition of 'struct
> >    mlx4_wqe_lso_seg'
> >      111 | struct mlx4_wqe_lso_seg {
> >          |        ^~~~~~~~~~~~~~~~
> >    In file included from ../drivers/net/mlx4/mlx4_glue.h:16,
> >                     from ../drivers/net/mlx4/mlx4.c:46:
> >    /usr/include/infiniband/mlx4dv.h:410:8: note: originally defined here
> >      410 | struct mlx4_wqe_lso_seg {
> >          |        ^~~~~~~~~~~~~~~~
> >    ninja: build stopped: subcommand failed.
> 
> Hi again,
> 
> I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
> everything seems to build ok.
> 
> Looking through the logs, though, there does appear to be a difference in
> the configurations in the two cases. I suspect my Ubuntu has an updated
> verbs package compared to the image you are using. In the log of the failed
> build, I see:
> 
> 	Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: NO 
> 	Configuring mlx4_autoconf.h using configuration
> 
> While building in my VM, I have:
> 
> 	Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
> 	Configuring mlx4_autoconf.h using configuration
> 
> So my verbs mlx4 header has got a different set of definitions to those in
> the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev package
> version "28.0-1ubuntu1"
> 
> Can the CI image be updated to latest 20.04 packages?

I'm surprised there is such issue.
The autoconf mechanism should manage any old package.

Ali, do you have an idea what happens?

RE: [PATCH v3] build: update DPDK to use C11 standard

[Ali Alnubani]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, August 1, 2023 1:37 PM
> To: Patrick Robb <probb@iol.unh.edu>; Bruce Richardson
> <bruce.richardson@intel.com>; Ali Alnubani <alialnu@nvidia.com>
> Cc: Tyler Retzlaff <roretzla@linux.microsoft.com>; dev@dpdk.org; Morten
> Brørup <mb@smartsharesystems.com>; david.marchand@redhat.com;
> Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [PATCH v3] build: update DPDK to use C11 standard
> 
> 01/08/2023 12:19, Bruce Richardson:
> > On Mon, Jul 31, 2023 at 08:39:31PM -0400, Patrick Robb wrote:
> > >    Hi Bruce,
> > >    I see some failures for this series for our Ubuntu 20.04 containers.
> > >    And, our DTS testbeds which are on ubuntu 20.04 are skipping running
> > >    testsuites because they can't compile DPDK. So, that's why it has some
> > >    missing results for a couple of the Intel NICs. For context, I'll paste
> > >    below where the compile job terminates in one of our containerized
> > >    compile test runs. The GCC in use here is version 9.4, so it meets the
> > >    requirements as described in your patch as far as I can tell. I'll
> > >    check it out more tomorrow to see whether it's an infra failure, like
> > >    some missing dependencies. Please let me know if we expect to have no
> > >    issues with 20.04 or if this is anticipated.
> > >    Thanks!
> > >    [1638/2730] Generating symbol file
> > >
> 'drivers/a715181@@rte_net_ixgbe@sha/librte_net_ixgbe.so.24.0.symbols'.
> > >    [1639/2730] Compiling C object
> > >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o'.
> > >    FAILED: drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o
> > >    ccache cc -Idrivers/a715181@@tmp_rte_net_mlx4@sta -Idrivers
> > >    -I../drivers -Idrivers/net/mlx4 -I../drivers/net/mlx4 -Ilib/ethdev
> > >    -I../lib/ethdev -I. -I../ -Iconfig -I../config -Ilib/eal/include
> > >    -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include
> > >    -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common
> > >    -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs
> > >    -Ilib/telemetry/../metrics -I../lib/telemetry/../metrics
> > >    -Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
> > >    -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
> > >    -Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
> > >    -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev
> > >    -I../drivers/bus/vdev -I/usr/include/libnl3 -fdiagnostics-color=always
> > >    -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror
> > >    -std=c11 -O3 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
> > >    -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> > >    -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> > >    -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> > >    -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-
> aligned
> > >    -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
> > >    -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-
> truncation
> > >    -std=c11 -Wno-strict-prototypes -D_BSD_SOURCE -D_DEFAULT_SOURCE
> > >    -D_XOPEN_SOURCE=600 -UPEDANTIC -
> DRTE_LOG_DEFAULT_LOGTYPE=pmd.net.mlx4
> > >    -MD -MQ
> 'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -MF
> > >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o.d' -o
> > >    'drivers/a715181@@tmp_rte_net_mlx4@sta/net_mlx4_mlx4.c.o' -c
> > >    ../drivers/net/mlx4/mlx4.c
> > >    In file included from ../drivers/net/mlx4/mlx4_rxtx.h:27,
> > >                     from ../drivers/net/mlx4/mlx4.c:49:
> > >    ../drivers/net/mlx4/mlx4_prm.h:111:8: error: redefinition of 'struct
> > >    mlx4_wqe_lso_seg'
> > >      111 | struct mlx4_wqe_lso_seg {
> > >          |        ^~~~~~~~~~~~~~~~
> > >    In file included from ../drivers/net/mlx4/mlx4_glue.h:16,
> > >                     from ../drivers/net/mlx4/mlx4.c:46:
> > >    /usr/include/infiniband/mlx4dv.h:410:8: note: originally defined here
> > >      410 | struct mlx4_wqe_lso_seg {
> > >          |        ^~~~~~~~~~~~~~~~
> > >    ninja: build stopped: subcommand failed.
> >
> > Hi again,
> >
> > I've attempted to reproduce this on my Ubuntu 20.04 VM and failed,
> > everything seems to build ok.
> >
> > Looking through the logs, though, there does appear to be a difference in
> > the configurations in the two cases. I suspect my Ubuntu has an updated
> > verbs package compared to the image you are using. In the log of the failed
> > build, I see:
> >
> > 	Checking whether type "struct mlx4_wqe_lso_seg" has member
> "mss_hdr_size" with dependencies libmlx4, libibverbs: NO
> > 	Configuring mlx4_autoconf.h using configuration
> >
> > While building in my VM, I have:
> >
> > 	Checking whether type "struct mlx4_wqe_lso_seg" has member
> "mss_hdr_size" with dependencies libmlx4, libibverbs: YES (cached)
> > 	Configuring mlx4_autoconf.h using configuration
> >
> > So my verbs mlx4 header has got a different set of definitions to those in
> > the CI machine. My Ubuntu reports as 20.04.6 with libibverbs-dev package
> > version "28.0-1ubuntu1"
> >
> > Can the CI image be updated to latest 20.04 packages?
> 
> I'm surprised there is such issue.
> The autoconf mechanism should manage any old package.
> 
> Ali, do you have an idea what happens?
> 

28.0-1ubuntu1 is the latest for focal (20.04LTS), and I can reproduce with it as well.
https://packages.ubuntu.com/focal/libibverbs-dev

It's resolved for me with v4.

[PATCH v4] build: update DPDK to use C11 standard

[Bruce Richardson]

As previously announced, DPDK 23.11 will require a C11 supporting
compiler and will use the C11 standard in all builds.

Forcing use of the C standard, rather than the standard with
GNU extensions, means that some posix definitions which are not in
the C standard are unavailable by default. We fix this by ensuring
the correct defines or cflags are passed to the components that
need them.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
V4:
* pass cflags to the structure and definition checks in mlx* drivers
  to ensure posix definitions - as well as C-standard ones - are
  available.

V3:
* remove (now unneeded) use of -std=gnu99 in failsafe net driver.

V2:
* Resubmit now that 23.11-rc0 patch applied
* Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
  definition of strerror_r() with c11 standard.
---
 doc/guides/linux_gsg/sys_reqs.rst      |  3 ++-
 doc/guides/rel_notes/deprecation.rst   | 18 ------------------
 doc/guides/rel_notes/release_23_11.rst | 17 +++++++++++++++++
 drivers/common/mlx5/linux/meson.build  |  5 +++--
 drivers/net/failsafe/meson.build       |  1 -
 drivers/net/mlx4/meson.build           |  4 ++--
 lib/eal/common/eal_common_errno.c      |  1 +
 meson.build                            |  1 +
 8 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index dfeaf4e1c5..13be715933 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -27,7 +27,8 @@ Compilation of the DPDK
     The setup commands and installed packages needed on various systems may be different.
     For details on Linux distributions and the versions tested, please consult the DPDK Release Notes.
 
-*   General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+),
+*   General development tools including a C compiler supporting the C11 standard,
+    including standard atomics, for example: GCC (version 5.0+) or Clang (version 3.6+),
     and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK.
 
     * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 494b401cda..cc939d3c67 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,24 +17,6 @@ Other API and ABI deprecation notices are to be posted below.
 Deprecation Notices
 -------------------
 
-* C Compiler: From DPDK 23.11 onwards,
-  building DPDK will require a C compiler which supports the C11 standard,
-  including support for C11 standard atomics.
-
-  More specifically, the requirements will be:
-
-  * Support for flag "-std=c11" (or similar)
-  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
-
-  Please note:
-
-  * C11, including standard atomics, is supported from GCC version 5 onwards,
-    and is the default language version in that release
-    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
-  * C11 is the default compilation mode in Clang from version 3.6,
-    which also added support for standard atomics
-    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
-
 * build: Enabling deprecated libraries (``flow_classify``, ``kni``)
   won't be possible anymore through the use of the ``disable_libs`` build option.
   A new build option for deprecated libraries will be introduced instead.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 6b4dd21fd0..c8b9ed456c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -20,6 +20,23 @@ DPDK Release 23.11
       ninja -C build doc
       xdg-open build/doc/guides/html/rel_notes/release_23_11.html
 
+* Build Requirements: From DPDK 23.11 onwards,
+  building DPDK will require a C compiler which supports the C11 standard,
+  including support for C11 standard atomics.
+
+  More specifically, the requirements will be:
+
+  * Support for flag "-std=c11" (or similar)
+  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
+
+  Please note:
+
+  * C11, including standard atomics, is supported from GCC version 5 onwards,
+    and is the default language version in that release
+    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
+  * C11 is the default compilation mode in Clang from version 3.6,
+    which also added support for standard atomics
+    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
 
 New Features
 ------------
diff --git a/drivers/common/mlx5/linux/meson.build b/drivers/common/mlx5/linux/meson.build
index 15edc13041..b3a64547c5 100644
--- a/drivers/common/mlx5/linux/meson.build
+++ b/drivers/common/mlx5/linux/meson.build
@@ -231,11 +231,12 @@ if  libmtcr_ul_found
 endif
 
 foreach arg:has_sym_args
-    mlx5_config.set(arg[0], cc.has_header_symbol(arg[1], arg[2], dependencies: libs))
+    mlx5_config.set(arg[0], cc.has_header_symbol(arg[1], arg[2], dependencies: libs, args: cflags))
 endforeach
 foreach arg:has_member_args
     file_prefix = '#include <' + arg[1] + '>'
-    mlx5_config.set(arg[0], cc.has_member(arg[2], arg[3], prefix : file_prefix, dependencies: libs))
+    mlx5_config.set(arg[0],
+            cc.has_member(arg[2], arg[3], prefix : file_prefix, dependencies: libs, args: cflags))
 endforeach
 
 # Build Glue Library
diff --git a/drivers/net/failsafe/meson.build b/drivers/net/failsafe/meson.build
index 6013e13722..c1d361083b 100644
--- a/drivers/net/failsafe/meson.build
+++ b/drivers/net/failsafe/meson.build
@@ -7,7 +7,6 @@ if is_windows
     subdir_done()
 endif
 
-cflags += '-std=gnu99'
 cflags += '-D_DEFAULT_SOURCE'
 cflags += '-D_XOPEN_SOURCE=700'
 cflags += '-pedantic'
diff --git a/drivers/net/mlx4/meson.build b/drivers/net/mlx4/meson.build
index a038c1ec1b..3c5ee24186 100644
--- a/drivers/net/mlx4/meson.build
+++ b/drivers/net/mlx4/meson.build
@@ -103,12 +103,12 @@ has_sym_args = [
 config = configuration_data()
 foreach arg:has_sym_args
     config.set(arg[0], cc.has_header_symbol(arg[1], arg[2],
-        dependencies: libs))
+        dependencies: libs, args: cflags))
 endforeach
 foreach arg:has_member_args
     file_prefix = '#include <' + arg[1] + '>'
     config.set(arg[0], cc.has_member(arg[2], arg[3],
-        prefix: file_prefix, dependencies: libs))
+        prefix: file_prefix, dependencies: libs, args: cflags))
 endforeach
 configure_file(output : 'mlx4_autoconf.h', configuration : config)
 
diff --git a/lib/eal/common/eal_common_errno.c b/lib/eal/common/eal_common_errno.c
index ef8f782abb..b30e2f0ad4 100644
--- a/lib/eal/common/eal_common_errno.c
+++ b/lib/eal/common/eal_common_errno.c
@@ -4,6 +4,7 @@
 
 /* Use XSI-compliant portable version of strerror_r() */
 #undef _GNU_SOURCE
+#define _POSIX_C_SOURCE 200809L
 
 #include <stdio.h>
 #include <string.h>
diff --git a/meson.build b/meson.build
index 39cb73846d..70b54f0c98 100644
--- a/meson.build
+++ b/meson.build
@@ -9,6 +9,7 @@ project('DPDK', 'c',
         license: 'BSD',
         default_options: [
             'buildtype=release',
+            'c_std=c11',
             'default_library=static',
             'warning_level=2',
         ],
-- 
2.39.2

Re: [PATCH v4] build: update DPDK to use C11 standard

[David Marchand]

On Tue, Aug 1, 2023 at 3:16 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
>
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
> V4:
> * pass cflags to the structure and definition checks in mlx* drivers
>   to ensure posix definitions - as well as C-standard ones - are
>   available.

With this v4, mlx4 builds fine in my Ubuntu 20.04.6 container.
However, I think the mlx4dv.h includes are probably faulty: as this
header is using off_t, it should include sys/types.h in the first
place.
https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx4/mlx4dv.h#L36

This had been fixed in the mlx5 header in some rdma-core change in the
past: https://github.com/linux-rdma/rdma-core/commit/d2389b34ccc5


-- 
David Marchand

Re: [PATCH v4] build: update DPDK to use C11 standard

[Bruce Richardson]

On Tue, Aug 01, 2023 at 03:24:19PM +0200, David Marchand wrote:
> On Tue, Aug 1, 2023 at 3:16 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > As previously announced, DPDK 23.11 will require a C11 supporting
> > compiler and will use the C11 standard in all builds.
> >
> > Forcing use of the C standard, rather than the standard with
> > GNU extensions, means that some posix definitions which are not in
> > the C standard are unavailable by default. We fix this by ensuring
> > the correct defines or cflags are passed to the components that
> > need them.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> > V4:
> > * pass cflags to the structure and definition checks in mlx* drivers
> >   to ensure posix definitions - as well as C-standard ones - are
> >   available.
> 
> With this v4, mlx4 builds fine in my Ubuntu 20.04.6 container.
> However, I think the mlx4dv.h includes are probably faulty: as this
> header is using off_t, it should include sys/types.h in the first
> place.
> https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx4/mlx4dv.h#L36
> 
> This had been fixed in the mlx5 header in some rdma-core change in the
> past: https://github.com/linux-rdma/rdma-core/commit/d2389b34ccc5
> 
Even if that were fixed, I still think the correct behaviour in our build
here is to test the structures using the same flags as will be used to
build the final lib.

/Bruce

Re: [PATCH v4] build: update DPDK to use C11 standard

[David Marchand]

On Tue, Aug 1, 2023 at 3:29 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Tue, Aug 01, 2023 at 03:24:19PM +0200, David Marchand wrote:
> > On Tue, Aug 1, 2023 at 3:16 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > compiler and will use the C11 standard in all builds.
> > >
> > > Forcing use of the C standard, rather than the standard with
> > > GNU extensions, means that some posix definitions which are not in
> > > the C standard are unavailable by default. We fix this by ensuring
> > > the correct defines or cflags are passed to the components that
> > > need them.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > ---
> > > V4:
> > > * pass cflags to the structure and definition checks in mlx* drivers
> > >   to ensure posix definitions - as well as C-standard ones - are
> > >   available.
> >
> > With this v4, mlx4 builds fine in my Ubuntu 20.04.6 container.
> > However, I think the mlx4dv.h includes are probably faulty: as this
> > header is using off_t, it should include sys/types.h in the first
> > place.
> > https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx4/mlx4dv.h#L36
> >
> > This had been fixed in the mlx5 header in some rdma-core change in the
> > past: https://github.com/linux-rdma/rdma-core/commit/d2389b34ccc5
> >
> Even if that were fixed, I still think the correct behaviour in our build
> here is to test the structures using the same flags as will be used to
> build the final lib.

Yes, compiling for testing and using the structures must be aligned.


-- 
David Marchand

RE: [PATCH v4] build: update DPDK to use C11 standard

[Ali Alnubani]

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Tuesday, August 1, 2023 4:16 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Morten Brørup
> <mb@smartsharesystems.com>; Tyler Retzlaff
> <roretzla@linux.microsoft.com>
> Subject: [PATCH v4] build: update DPDK to use C11 standard
> 
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
> 
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---

By the way, I also see this build failure in RHEL 7:

[827/1011] Compiling C object app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o
FAILED: app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o
ccache cc -Iapp/dpdk-testpmd.p -Iapp -I../app -Iapp/test-pmd -I../app/test-pmd -Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -Ilib/meter -I../lib/meter -Ilib/cmdline -I../lib/cmdline -Ilib/bitratestats -I../lib/bitratestats -Ilib/bpf -I../lib/bpf -Ilib/gro -I../lib/gro -Ilib/gso -I../lib/gso -Ilib/latencystats -I../lib/latencystats -Ilib/pdump -I../lib/pdump -Ilib/pcapng -I../lib/pcapng -Idrivers/net/mlx5 -I../drivers/net/mlx5 -Idrivers/net/mlx5/linux -I../drivers/net/mlx5/linux -Idrivers/net/mlx5/hws -I../drivers/net/mlx5/hws -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/hash -I../lib/hash -Ilib/rcu -I../lib/rcu -Idrivers/common/mlx5 -I../drivers/common/mlx5 -Idrivers/common/mlx5/linux -I../drivers/common/mlx5/linux -Idrivers/bus/auxiliary -I../drivers/bus/auxiliary -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O3 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -march=native -DALLOW_EXPERIMENTAL_API -Wno-deprecated-declarations -MD -MQ app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o -MF app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o.d -o app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o -c ../app/test-pmd/cmdline_flow.c
../app/test-pmd/cmdline_flow.c: In function ‘parse_vc_spec’:
../app/test-pmd/cmdline_flow.c:1035:37: error: array initialized from non-constant array expression
 #define NEXT_ENTRY(...) (const enum index []){ __VA_ARGS__, ZERO, }
                                     ^
../app/test-pmd/cmdline_flow.c:8049:38: note: in expansion of macro ‘NEXT_ENTRY’
   static const enum index prefix[] = NEXT_ENTRY(COMMON_PREFIX);
                                      ^
../app/test-pmd/cmdline_flow.c: In function ‘parse_vc_action_rss_type’:
../app/test-pmd/cmdline_flow.c:1035:37: error: array initialized from non-constant array expression
 #define NEXT_ENTRY(...) (const enum index []){ __VA_ARGS__, ZERO, }
                                     ^
../app/test-pmd/cmdline_flow.c:8391:35: note: in expansion of macro ‘NEXT_ENTRY’
  static const enum index next[] = NEXT_ENTRY(ACTION_RSS_TYPE);
                                   ^
../app/test-pmd/cmdline_flow.c: In function ‘parse_vc_action_rss_queue’:
../app/test-pmd/cmdline_flow.c:1035:37: error: array initialized from non-constant array expression
 #define NEXT_ENTRY(...) (const enum index []){ __VA_ARGS__, ZERO, }
                                     ^
../app/test-pmd/cmdline_flow.c:8435:35: note: in expansion of macro ‘NEXT_ENTRY’
  static const enum index next[] = NEXT_ENTRY(ACTION_RSS_QUEUE);
                                   ^
[834/1011] Compiling C object app/dpdk-testpmd.p/test-pmd_config.c.o
ninja: build stopped: subcommand failed.

Meson: 1.2.0
Gcc: 4.8.5

Re: [PATCH v4] build: update DPDK to use C11 standard

[Bruce Richardson]

On Tue, Aug 01, 2023 at 03:47:03PM +0000, Ali Alnubani wrote:
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > Sent: Tuesday, August 1, 2023 4:16 PM
> > To: dev@dpdk.org
> > Cc: Bruce Richardson <bruce.richardson@intel.com>; Morten Brørup
> > <mb@smartsharesystems.com>; Tyler Retzlaff
> > <roretzla@linux.microsoft.com>
> > Subject: [PATCH v4] build: update DPDK to use C11 standard
> > 
> > As previously announced, DPDK 23.11 will require a C11 supporting
> > compiler and will use the C11 standard in all builds.
> > 
> > Forcing use of the C standard, rather than the standard with
> > GNU extensions, means that some posix definitions which are not in
> > the C standard are unavailable by default. We fix this by ensuring
> > the correct defines or cflags are passed to the components that
> > need them.
> > 
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> 
> By the way, I also see this build failure in RHEL 7:
> 
It's my understanding that we no longer support the default compilers in
RHEL 7, since gcc 4.8.5 doesn't support the necessary c11 standard atomics.

/Bruce

Re: [PATCH v4] build: update DPDK to use C11 standard

[Tyler Retzlaff]

On Tue, Aug 01, 2023 at 04:50:45PM +0100, Bruce Richardson wrote:
> On Tue, Aug 01, 2023 at 03:47:03PM +0000, Ali Alnubani wrote:
> > > -----Original Message-----
> > > From: Bruce Richardson <bruce.richardson@intel.com>
> > > Sent: Tuesday, August 1, 2023 4:16 PM
> > > To: dev@dpdk.org
> > > Cc: Bruce Richardson <bruce.richardson@intel.com>; Morten Brørup
> > > <mb@smartsharesystems.com>; Tyler Retzlaff
> > > <roretzla@linux.microsoft.com>
> > > Subject: [PATCH v4] build: update DPDK to use C11 standard
> > > 
> > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > compiler and will use the C11 standard in all builds.
> > > 
> > > Forcing use of the C standard, rather than the standard with
> > > GNU extensions, means that some posix definitions which are not in
> > > the C standard are unavailable by default. We fix this by ensuring
> > > the correct defines or cflags are passed to the components that
> > > need them.
> > > 
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > ---
> > 
> > By the way, I also see this build failure in RHEL 7:
> > 
> It's my understanding that we no longer support the default compilers in
> RHEL 7, since gcc 4.8.5 doesn't support the necessary c11 standard atomics.

yes, support is being dropped for RHEL 7

http://mails.dpdk.org/archives/dev/2023-February/263516.html

it seems like now that we are in 23.11 merge window the CI pipelines for
the unsupported targets can be decomissioned?

> 
> /Bruce

Re: [PATCH v4] build: update DPDK to use C11 standard

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

On Tue, Aug 1, 2023 at 12:20 PM Tyler Retzlaff <roretzla@linux.microsoft.com>
wrote:

>
> yes, support is being dropped for RHEL 7
>
> http://mails.dpdk.org/archives/dev/2023-February/263516.html
>
> it seems like now that we are in 23.11 merge window the CI pipelines for
> the unsupported targets can be decomissioned?
>
> >
> > /Bruce
>
The Community Lab will discontinue CI testing on RHEL7 at start of day
tomorrow.

[-- Attachment #2: Type: text/html, Size: 893 bytes --]

Re: [PATCH v4] build: update DPDK to use C11 standard

[David Marchand]

On Tue, Aug 1, 2023 at 10:12 PM Patrick Robb <probb@iol.unh.edu> wrote:
> On Tue, Aug 1, 2023 at 12:20 PM Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
>>
>>
>> yes, support is being dropped for RHEL 7

in the main branch.

>>
>> http://mails.dpdk.org/archives/dev/2023-February/263516.html
>>
>> it seems like now that we are in 23.11 merge window the CI pipelines for
>> the unsupported targets can be decomissioned?
>
> The Community Lab will discontinue CI testing on RHEL7 at start of day tomorrow

What about the LTS releases testing?


-- 
David Marchand

Re: [PATCH v4] build: update DPDK to use C11 standard

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

On Wed, Aug 2, 2023 at 2:32 AM David Marchand <david.marchand@redhat.com>
wrote:

> What about the LTS releases testing?
>
>
> --
> David Marchand
>
>
Okay, we will disable rhel7 testing for dpdk main and next branches, but
leave testing on for the LTS releases.

[-- Attachment #2: Type: text/html, Size: 579 bytes --]

Re: [PATCH v4] build: update DPDK to use C11 standard

[David Marchand]

On Wed, Aug 2, 2023 at 3:41 PM Patrick Robb <probb@iol.unh.edu> wrote:
> On Wed, Aug 2, 2023 at 2:32 AM David Marchand <david.marchand@redhat.com> wrote:
>>
>> What about the LTS releases testing?
>
> Okay, we will disable rhel7 testing for dpdk main and next branches, but leave testing on for the LTS releases.

Thank you Patrick.


-- 
David Marchand

[PATCH v5] build: update DPDK to use C11 standard

[Bruce Richardson]

As previously announced, DPDK 23.11 will require a C11 supporting
compiler and will use the C11 standard in all builds.

Forcing use of the C standard, rather than the standard with
GNU extensions, means that some posix definitions which are not in
the C standard are unavailable by default. We fix this by ensuring
the correct defines or cflags are passed to the components that
need them.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
V5:
* Fix build issues with bool type in altivec code, due to bool type
  being in C11. Use __bool for altivec-specific version instead.

V4:
* pass cflags to the structure and definition checks in mlx* drivers
  to ensure posix definitions - as well as C-standard ones - are
  available.

V3:
* remove (now unneeded) use of -std=gnu99 in failsafe net driver.

V2:
* Resubmit now that 23.11-rc0 patch applied
* Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
  definition of strerror_r() with c11 standard.

---
 doc/guides/linux_gsg/sys_reqs.rst      |  3 ++-
 doc/guides/rel_notes/deprecation.rst   | 18 ------------------
 doc/guides/rel_notes/release_23_11.rst | 17 +++++++++++++++++
 drivers/common/mlx5/linux/meson.build  |  5 +++--
 drivers/net/failsafe/meson.build       |  1 -
 drivers/net/mlx4/meson.build           |  4 ++--
 lib/acl/acl_run_altivec.h              |  4 ++--
 lib/eal/common/eal_common_errno.c      |  1 +
 meson.build                            |  1 +
 9 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index dfeaf4e1c5..13be715933 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -27,7 +27,8 @@ Compilation of the DPDK
     The setup commands and installed packages needed on various systems may be different.
     For details on Linux distributions and the versions tested, please consult the DPDK Release Notes.
 
-*   General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+),
+*   General development tools including a C compiler supporting the C11 standard,
+    including standard atomics, for example: GCC (version 5.0+) or Clang (version 3.6+),
     and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK.
 
     * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 494b401cda..cc939d3c67 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,24 +17,6 @@ Other API and ABI deprecation notices are to be posted below.
 Deprecation Notices
 -------------------
 
-* C Compiler: From DPDK 23.11 onwards,
-  building DPDK will require a C compiler which supports the C11 standard,
-  including support for C11 standard atomics.
-
-  More specifically, the requirements will be:
-
-  * Support for flag "-std=c11" (or similar)
-  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
-
-  Please note:
-
-  * C11, including standard atomics, is supported from GCC version 5 onwards,
-    and is the default language version in that release
-    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
-  * C11 is the default compilation mode in Clang from version 3.6,
-    which also added support for standard atomics
-    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
-
 * build: Enabling deprecated libraries (``flow_classify``, ``kni``)
   won't be possible anymore through the use of the ``disable_libs`` build option.
   A new build option for deprecated libraries will be introduced instead.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 6b4dd21fd0..c8b9ed456c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -20,6 +20,23 @@ DPDK Release 23.11
       ninja -C build doc
       xdg-open build/doc/guides/html/rel_notes/release_23_11.html
 
+* Build Requirements: From DPDK 23.11 onwards,
+  building DPDK will require a C compiler which supports the C11 standard,
+  including support for C11 standard atomics.
+
+  More specifically, the requirements will be:
+
+  * Support for flag "-std=c11" (or similar)
+  * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
+
+  Please note:
+
+  * C11, including standard atomics, is supported from GCC version 5 onwards,
+    and is the default language version in that release
+    (Ref: https://gcc.gnu.org/gcc-5/changes.html)
+  * C11 is the default compilation mode in Clang from version 3.6,
+    which also added support for standard atomics
+    (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
 
 New Features
 ------------
diff --git a/drivers/common/mlx5/linux/meson.build b/drivers/common/mlx5/linux/meson.build
index 15edc13041..b3a64547c5 100644
--- a/drivers/common/mlx5/linux/meson.build
+++ b/drivers/common/mlx5/linux/meson.build
@@ -231,11 +231,12 @@ if  libmtcr_ul_found
 endif
 
 foreach arg:has_sym_args
-    mlx5_config.set(arg[0], cc.has_header_symbol(arg[1], arg[2], dependencies: libs))
+    mlx5_config.set(arg[0], cc.has_header_symbol(arg[1], arg[2], dependencies: libs, args: cflags))
 endforeach
 foreach arg:has_member_args
     file_prefix = '#include <' + arg[1] + '>'
-    mlx5_config.set(arg[0], cc.has_member(arg[2], arg[3], prefix : file_prefix, dependencies: libs))
+    mlx5_config.set(arg[0],
+            cc.has_member(arg[2], arg[3], prefix : file_prefix, dependencies: libs, args: cflags))
 endforeach
 
 # Build Glue Library
diff --git a/drivers/net/failsafe/meson.build b/drivers/net/failsafe/meson.build
index 6013e13722..c1d361083b 100644
--- a/drivers/net/failsafe/meson.build
+++ b/drivers/net/failsafe/meson.build
@@ -7,7 +7,6 @@ if is_windows
     subdir_done()
 endif
 
-cflags += '-std=gnu99'
 cflags += '-D_DEFAULT_SOURCE'
 cflags += '-D_XOPEN_SOURCE=700'
 cflags += '-pedantic'
diff --git a/drivers/net/mlx4/meson.build b/drivers/net/mlx4/meson.build
index a038c1ec1b..3c5ee24186 100644
--- a/drivers/net/mlx4/meson.build
+++ b/drivers/net/mlx4/meson.build
@@ -103,12 +103,12 @@ has_sym_args = [
 config = configuration_data()
 foreach arg:has_sym_args
     config.set(arg[0], cc.has_header_symbol(arg[1], arg[2],
-        dependencies: libs))
+        dependencies: libs, args: cflags))
 endforeach
 foreach arg:has_member_args
     file_prefix = '#include <' + arg[1] + '>'
     config.set(arg[0], cc.has_member(arg[2], arg[3],
-        prefix: file_prefix, dependencies: libs))
+        prefix: file_prefix, dependencies: libs, args: cflags))
 endforeach
 configure_file(output : 'mlx4_autoconf.h', configuration : config)
 
diff --git a/lib/acl/acl_run_altivec.h b/lib/acl/acl_run_altivec.h
index 4556e1503b..3c30466d2d 100644
--- a/lib/acl/acl_run_altivec.h
+++ b/lib/acl/acl_run_altivec.h
@@ -41,7 +41,7 @@ resolve_priority_altivec(uint64_t transition, int n,
 {
 	uint32_t x;
 	xmm_t results, priority, results1, priority1;
-	__vector bool int selector;
+	__vector __bool int selector;
 	xmm_t *saved_results, *saved_priority;
 
 	for (x = 0; x < categories; x += RTE_ACL_RESULTS_MULTIPLIER) {
@@ -110,7 +110,7 @@ transition4(xmm_t next_input, const uint64_t *trans,
 	xmm_t in, node_type, r, t;
 	xmm_t dfa_ofs, quad_ofs;
 	xmm_t *index_mask, *tp;
-	__vector bool int dfa_msk;
+	__vector __bool int dfa_msk;
 	__vector signed char zeroes = {};
 	union {
 		uint64_t d64[2];
diff --git a/lib/eal/common/eal_common_errno.c b/lib/eal/common/eal_common_errno.c
index ef8f782abb..b30e2f0ad4 100644
--- a/lib/eal/common/eal_common_errno.c
+++ b/lib/eal/common/eal_common_errno.c
@@ -4,6 +4,7 @@
 
 /* Use XSI-compliant portable version of strerror_r() */
 #undef _GNU_SOURCE
+#define _POSIX_C_SOURCE 200809L
 
 #include <stdio.h>
 #include <string.h>
diff --git a/meson.build b/meson.build
index 39cb73846d..70b54f0c98 100644
--- a/meson.build
+++ b/meson.build
@@ -9,6 +9,7 @@ project('DPDK', 'c',
         license: 'BSD',
         default_options: [
             'buildtype=release',
+            'c_std=c11',
             'default_library=static',
             'warning_level=2',
         ],
-- 
2.39.2

Re: [PATCH v5] build: update DPDK to use C11 standard

[Bruce Richardson]

On Wed, Aug 02, 2023 at 01:31:34PM +0100, Bruce Richardson wrote:
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
> 
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
> V5:
> * Fix build issues with bool type in altivec code, due to bool type
>   being in C11. Use __bool for altivec-specific version instead.
> 
Just a note on the altivec builds: from my testing on latest ubuntu with
"powerpc64le-linux-gnu-gcc (Ubuntu 12.3.0-1ubuntu1~23.04)", there are quite
a few warnings/errors building the current DPDK mainline. This patch
doesn't fix any of those errors, but neither does it add any new ones,
as far as I can see! However, we may need some more PPC fixes and updated
CI coverage to catch these issues sooner in future.

/Bruce

RE: [PATCH v5] build: update DPDK to use C11 standard

[Ali Alnubani]

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Wednesday, August 2, 2023 3:32 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Morten Brørup
> <mb@smartsharesystems.com>; Tyler Retzlaff
> <roretzla@linux.microsoft.com>
> Subject: [PATCH v5] build: update DPDK to use C11 standard
> 
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
> 
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
> V5:
> * Fix build issues with bool type in altivec code, due to bool type
>   being in C11. Use __bool for altivec-specific version instead.
> 
> V4:
> * pass cflags to the structure and definition checks in mlx* drivers
>   to ensure posix definitions - as well as C-standard ones - are
>   available.
> 
> V3:
> * remove (now unneeded) use of -std=gnu99 in failsafe net driver.
> 
> V2:
> * Resubmit now that 23.11-rc0 patch applied
> * Add _POSIX_C_SOURCE macro to eal_common_errno.c to get POSIX
>   definition of strerror_r() with c11 standard.
> 
> ---

Tested-by: Ali Alnubani <alialnu@nvidia.com>

Thanks,
Ali

Re: [PATCH v5] build: update DPDK to use C11 standard

[David Marchand]

On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> As previously announced, DPDK 23.11 will require a C11 supporting
> compiler and will use the C11 standard in all builds.
>
> Forcing use of the C standard, rather than the standard with
> GNU extensions, means that some posix definitions which are not in
> the C standard are unavailable by default. We fix this by ensuring
> the correct defines or cflags are passed to the components that
> need them.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Tested-by: Ali Alnubani <alialnu@nvidia.com>

The CI results look good.

Applied, thanks!


-- 
David Marchand

Re: [PATCH v5] build: update DPDK to use C11 standard

[Thomas Monjalon]

03/08/2023 15:36, David Marchand:
> On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > As previously announced, DPDK 23.11 will require a C11 supporting
> > compiler and will use the C11 standard in all builds.
> >
> > Forcing use of the C standard, rather than the standard with
> > GNU extensions, means that some posix definitions which are not in
> > the C standard are unavailable by default. We fix this by ensuring
> > the correct defines or cflags are passed to the components that
> > need them.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Tested-by: Ali Alnubani <alialnu@nvidia.com>
> 
> The CI results look good.
> 
> Applied, thanks!

The compiler support is updated, that's fine.
Should we go further and document some major Linux distributions?
One concern is to make clear RHEL 7 is not supported anymore.
Should it be a release note?

Re: [PATCH v5] build: update DPDK to use C11 standard

[Stephen Hemminger]

On Thu, 10 Aug 2023 15:34:43 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 03/08/2023 15:36, David Marchand:
> > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:  
> > >
> > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > compiler and will use the C11 standard in all builds.
> > >
> > > Forcing use of the C standard, rather than the standard with
> > > GNU extensions, means that some posix definitions which are not in
> > > the C standard are unavailable by default. We fix this by ensuring
> > > the correct defines or cflags are passed to the components that
> > > need them.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>  
> > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > 
> > The CI results look good.
> > 
> > Applied, thanks!  
> 
> The compiler support is updated, that's fine.
> Should we go further and document some major Linux distributions?
> One concern is to make clear RHEL 7 is not supported anymore.
> Should it be a release note?
> 
> 

Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
Also, is it possible to add automated check in build for compiler version?

Re: [PATCH v5] build: update DPDK to use C11 standard

[Bruce Richardson]

On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> On Thu, 10 Aug 2023 15:34:43 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 03/08/2023 15:36, David Marchand:
> > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:  
> > > >
> > > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > > compiler and will use the C11 standard in all builds.
> > > >
> > > > Forcing use of the C standard, rather than the standard with
> > > > GNU extensions, means that some posix definitions which are not in
> > > > the C standard are unavailable by default. We fix this by ensuring
> > > > the correct defines or cflags are passed to the components that
> > > > need them.
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>  
> > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > 
> > > The CI results look good.
> > > 
> > > Applied, thanks!  
> > 
> > The compiler support is updated, that's fine.
> > Should we go further and document some major Linux distributions?
> > One concern is to make clear RHEL 7 is not supported anymore.
> > Should it be a release note?
> > 

Well, DPDK currently is still building fine on Centos 7 for me, so let's
hold off on claiming anything until it's definitely broken.

> > 
> 
> Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
> Also, is it possible to add automated check in build for compiler version?

I'd be a little careful about what we claim, and I think current docs are
accurate vs our original plans. What we didn't plan to support was the GCC
and Clang compiler versions in RHEL 7, but if one installs an updated GCC,
for example, the build should be fine on RHEL 7.

Now, though, we are having to re-evaluate our use of stdatomics, which
means we may not actually break RHEL 7 compatibility after all. We'll have
to "watch this space" as the saying goes!

Overall, I think the approach of build-time checks is the best, but not
for specific versions, but instead for capabilities. If/when we add support
for stdatomics to DPDK builds on Linux/BSD, at that point we put in the
initial compiler checks a suitable check for them being present and output
a suitable error if not found.

/Bruce

Re: [PATCH v5] build: update DPDK to use C11 standard

[Thomas Monjalon]

10/08/2023 18:35, Bruce Richardson:
> On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > On Thu, 10 Aug 2023 15:34:43 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> > 
> > > 03/08/2023 15:36, David Marchand:
> > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:  
> > > > >
> > > > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > > > compiler and will use the C11 standard in all builds.
> > > > >
> > > > > Forcing use of the C standard, rather than the standard with
> > > > > GNU extensions, means that some posix definitions which are not in
> > > > > the C standard are unavailable by default. We fix this by ensuring
> > > > > the correct defines or cflags are passed to the components that
> > > > > need them.
> > > > >
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>  
> > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > 
> > > > The CI results look good.
> > > > 
> > > > Applied, thanks!  
> > > 
> > > The compiler support is updated, that's fine.
> > > Should we go further and document some major Linux distributions?
> > > One concern is to make clear RHEL 7 is not supported anymore.
> > > Should it be a release note?
> > > 
> 
> Well, DPDK currently is still building fine on Centos 7 for me, so let's
> hold off on claiming anything until it's definitely broken.
> 
> > > 
> > 
> > Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
> > Also, is it possible to add automated check in build for compiler version?
> 
> I'd be a little careful about what we claim, and I think current docs are
> accurate vs our original plans. What we didn't plan to support was the GCC
> and Clang compiler versions in RHEL 7, but if one installs an updated GCC,
> for example, the build should be fine on RHEL 7.
> 
> Now, though, we are having to re-evaluate our use of stdatomics, which
> means we may not actually break RHEL 7 compatibility after all. We'll have
> to "watch this space" as the saying goes!
> 
> Overall, I think the approach of build-time checks is the best, but not
> for specific versions, but instead for capabilities. If/when we add support
> for stdatomics to DPDK builds on Linux/BSD, at that point we put in the
> initial compiler checks a suitable check for them being present and output
> a suitable error if not found.

OK looks good

Re: [PATCH v5] build: update DPDK to use C11 standard

[Stephen Hemminger]

On Thu, 10 Aug 2023 18:49:09 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 10/08/2023 18:35, Bruce Richardson:
> > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:  
> > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >   
> > > > 03/08/2023 15:36, David Marchand:  
> > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > <bruce.richardson@intel.com> wrote:    
> > > > > >
> > > > > > As previously announced, DPDK 23.11 will require a C11 supporting
> > > > > > compiler and will use the C11 standard in all builds.
> > > > > >
> > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > GNU extensions, means that some posix definitions which are not in
> > > > > > the C standard are unavailable by default. We fix this by ensuring
> > > > > > the correct defines or cflags are passed to the components that
> > > > > > need them.
> > > > > >
> > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>    
> > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > 
> > > > > The CI results look good.
> > > > > 
> > > > > Applied, thanks!    
> > > > 
> > > > The compiler support is updated, that's fine.
> > > > Should we go further and document some major Linux distributions?
> > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > Should it be a release note?
> > > >   
> > 
> > Well, DPDK currently is still building fine on Centos 7 for me, so let's
> > hold off on claiming anything until it's definitely broken.
> >   
> > > >   
> > > 
> > > Should be addressed in linux/sys_reqs.rst as well as deprecation notice.
> > > Also, is it possible to add automated check in build for compiler version?  
> > 
> > I'd be a little careful about what we claim, and I think current docs are
> > accurate vs our original plans. What we didn't plan to support was the GCC
> > and Clang compiler versions in RHEL 7, but if one installs an updated GCC,
> > for example, the build should be fine on RHEL 7.
> > 
> > Now, though, we are having to re-evaluate our use of stdatomics, which
> > means we may not actually break RHEL 7 compatibility after all. We'll have
> > to "watch this space" as the saying goes!
> > 
> > Overall, I think the approach of build-time checks is the best, but not
> > for specific versions, but instead for capabilities. If/when we add support
> > for stdatomics to DPDK builds on Linux/BSD, at that point we put in the
> > initial compiler checks a suitable check for them being present and output
> > a suitable error if not found.  
> 
> OK looks good

Note: RHEL 7 official end of maintenance support is not until June 2024.

RE: [PATCH v5] build: update DPDK to use C11 standard

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 10 August 2023 19.03
> 
> On Thu, 10 Aug 2023 18:49:09 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 10/08/2023 18:35, Bruce Richardson:
> > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >
> > > > > 03/08/2023 15:36, David Marchand:
> > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > >
> > > > > > > As previously announced, DPDK 23.11 will require a C11
> supporting
> > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > >
> > > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > > GNU extensions, means that some posix definitions which are
> not in
> > > > > > > the C standard are unavailable by default. We fix this by
> ensuring
> > > > > > > the correct defines or cflags are passed to the components
> that
> > > > > > > need them.
> > > > > > >
> > > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > >
> > > > > > The CI results look good.
> > > > > >
> > > > > > Applied, thanks!
> > > > >
> > > > > The compiler support is updated, that's fine.
> > > > > Should we go further and document some major Linux distributions?
> > > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > > Should it be a release note?
> > > > >
> > >
> > > Well, DPDK currently is still building fine on Centos 7 for me, so
> let's
> > > hold off on claiming anything until it's definitely broken.
> > >
> > > > >
> > > >
> > > > Should be addressed in linux/sys_reqs.rst as well as deprecation
> notice.
> > > > Also, is it possible to add automated check in build for compiler
> version?
> > >
> > > I'd be a little careful about what we claim, and I think current docs
> are
> > > accurate vs our original plans. What we didn't plan to support was
> the GCC
> > > and Clang compiler versions in RHEL 7, but if one installs an updated
> GCC,
> > > for example, the build should be fine on RHEL 7.
> > >
> > > Now, though, we are having to re-evaluate our use of stdatomics,
> which
> > > means we may not actually break RHEL 7 compatibility after all. We'll
> have
> > > to "watch this space" as the saying goes!
> > >
> > > Overall, I think the approach of build-time checks is the best, but
> not
> > > for specific versions, but instead for capabilities. If/when we add
> support
> > > for stdatomics to DPDK builds on Linux/BSD, at that point we put in
> the
> > > initial compiler checks a suitable check for them being present and
> output
> > > a suitable error if not found.

Exactly. Capabilities checks is the right way to go when cross compiling.

> >
> > OK looks good
> 
> Note: RHEL 7 official end of maintenance support is not until June 2024.
> 

It was agreed to abandon RHEL 7, mainly driven by the need for C11 stdatomic.h, which is not supported by the GCC C compiler included with RHEL 7. So it pains me to admit that Stephen has a valid point here, after it turned out that the GCC g++ is not C11 compatible.

Regardless, I think that DPDK 23.11 support for RHEL 7 should be limited to "might work on RHEL 7", rather than guaranteed support for RHEL 7 (which would require DPDK CI to resume testing on RHEL 7).

IIRC, there was also the argument that DPDK 23.11 LTS support ends after June 2024.

Here's another argument for abandoning RHEL 7: RHEL 7 uses Linux Kernel 3.10. Although DPDK requires Linux Kernel >= 4.14, we promise backwards compatibility for RHEL/CentOS 7. Do we really still want to do that? (Note: RHEL 8 uses Linux Kernel 4.18.)

While we're discussing the Linux Kernel version required... Is it documented anywhere why a specific Linux Kernel version is required by DPDK? Or more specifically: Is it documented anywhere which DPDK features require which specific Linux Kernel versions?

Re: [PATCH v5] build: update DPDK to use C11 standard

[Tyler Retzlaff]

On Thu, Aug 10, 2023 at 08:17:23PM +0200, Morten Brørup wrote:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Thursday, 10 August 2023 19.03
> > 
> > On Thu, 10 Aug 2023 18:49:09 +0200
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> > 
> > > 10/08/2023 18:35, Bruce Richardson:
> > > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > >
> > > > > > 03/08/2023 15:36, David Marchand:
> > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > > >
> > > > > > > > As previously announced, DPDK 23.11 will require a C11
> > supporting
> > > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > > >
> > > > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > > > GNU extensions, means that some posix definitions which are
> > not in
> > > > > > > > the C standard are unavailable by default. We fix this by
> > ensuring
> > > > > > > > the correct defines or cflags are passed to the components
> > that
> > > > > > > > need them.
> > > > > > > >
> > > > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > > >
> > > > > > > The CI results look good.
> > > > > > >
> > > > > > > Applied, thanks!
> > > > > >
> > > > > > The compiler support is updated, that's fine.
> > > > > > Should we go further and document some major Linux distributions?
> > > > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > > > Should it be a release note?
> > > > > >
> > > >
> > > > Well, DPDK currently is still building fine on Centos 7 for me, so
> > let's
> > > > hold off on claiming anything until it's definitely broken.
> > > >
> > > > > >
> > > > >
> > > > > Should be addressed in linux/sys_reqs.rst as well as deprecation
> > notice.
> > > > > Also, is it possible to add automated check in build for compiler
> > version?
> > > >
> > > > I'd be a little careful about what we claim, and I think current docs
> > are
> > > > accurate vs our original plans. What we didn't plan to support was
> > the GCC
> > > > and Clang compiler versions in RHEL 7, but if one installs an updated
> > GCC,
> > > > for example, the build should be fine on RHEL 7.
> > > >
> > > > Now, though, we are having to re-evaluate our use of stdatomics,
> > which
> > > > means we may not actually break RHEL 7 compatibility after all. We'll
> > have
> > > > to "watch this space" as the saying goes!
> > > >
> > > > Overall, I think the approach of build-time checks is the best, but
> > not
> > > > for specific versions, but instead for capabilities. If/when we add
> > support
> > > > for stdatomics to DPDK builds on Linux/BSD, at that point we put in
> > the
> > > > initial compiler checks a suitable check for them being present and
> > output
> > > > a suitable error if not found.
> 
> Exactly. Capabilities checks is the right way to go when cross compiling.
> 
> > >
> > > OK looks good
> > 
> > Note: RHEL 7 official end of maintenance support is not until June 2024.
> > 
> 
> It was agreed to abandon RHEL 7, mainly driven by the need for C11 stdatomic.h, which is not supported by the GCC C compiler included with RHEL 7. So it pains me to admit that Stephen has a valid point here, after it turned out that the GCC g++ is not C11 compatible.

we would substantially reduce porting delta to retain C11, there are a
number of other things that help with portability from C11 that we can
utilized that i hadn't brought up before since it had been resolved to
adopt it.

it would be really unfortunate to say we aren't going to require C11
since that would cause me to have to bring a lot more conditional
compile into the tree.

just fyi

> 
> Regardless, I think that DPDK 23.11 support for RHEL 7 should be limited to "might work on RHEL 7", rather than guaranteed support for RHEL 7 (which would require DPDK CI to resume testing on RHEL 7).
> 
> IIRC, there was also the argument that DPDK 23.11 LTS support ends after June 2024.
> 
> Here's another argument for abandoning RHEL 7: RHEL 7 uses Linux Kernel 3.10. Although DPDK requires Linux Kernel >= 4.14, we promise backwards compatibility for RHEL/CentOS 7. Do we really still want to do that? (Note: RHEL 8 uses Linux Kernel 4.18.)
> 
> While we're discussing the Linux Kernel version required... Is it documented anywhere why a specific Linux Kernel version is required by DPDK? Or more specifically: Is it documented anywhere which DPDK features require which specific Linux Kernel versions?
> 

Re: [PATCH v5] build: update DPDK to use C11 standard

[Bruce Richardson]

On Thu, Aug 10, 2023 at 03:34:43PM -0700, Tyler Retzlaff wrote:
> On Thu, Aug 10, 2023 at 08:17:23PM +0200, Morten Brørup wrote:
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Thursday, 10 August 2023 19.03
> > > 
> > > On Thu, 10 Aug 2023 18:49:09 +0200
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > 
> > > > 10/08/2023 18:35, Bruce Richardson:
> > > > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger wrote:
> > > > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > >
> > > > > > > 03/08/2023 15:36, David Marchand:
> > > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > > > >
> > > > > > > > > As previously announced, DPDK 23.11 will require a C11
> > > supporting
> > > > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > > > >
> > > > > > > > > Forcing use of the C standard, rather than the standard with
> > > > > > > > > GNU extensions, means that some posix definitions which are
> > > not in
> > > > > > > > > the C standard are unavailable by default. We fix this by
> > > ensuring
> > > > > > > > > the correct defines or cflags are passed to the components
> > > that
> > > > > > > > > need them.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > > > >
> > > > > > > > The CI results look good.
> > > > > > > >
> > > > > > > > Applied, thanks!
> > > > > > >
> > > > > > > The compiler support is updated, that's fine.
> > > > > > > Should we go further and document some major Linux distributions?
> > > > > > > One concern is to make clear RHEL 7 is not supported anymore.
> > > > > > > Should it be a release note?
> > > > > > >
> > > > >
> > > > > Well, DPDK currently is still building fine on Centos 7 for me, so
> > > let's
> > > > > hold off on claiming anything until it's definitely broken.
> > > > >
> > > > > > >
> > > > > >
> > > > > > Should be addressed in linux/sys_reqs.rst as well as deprecation
> > > notice.
> > > > > > Also, is it possible to add automated check in build for compiler
> > > version?
> > > > >
> > > > > I'd be a little careful about what we claim, and I think current docs
> > > are
> > > > > accurate vs our original plans. What we didn't plan to support was
> > > the GCC
> > > > > and Clang compiler versions in RHEL 7, but if one installs an updated
> > > GCC,
> > > > > for example, the build should be fine on RHEL 7.
> > > > >
> > > > > Now, though, we are having to re-evaluate our use of stdatomics,
> > > which
> > > > > means we may not actually break RHEL 7 compatibility after all. We'll
> > > have
> > > > > to "watch this space" as the saying goes!
> > > > >
> > > > > Overall, I think the approach of build-time checks is the best, but
> > > not
> > > > > for specific versions, but instead for capabilities. If/when we add
> > > support
> > > > > for stdatomics to DPDK builds on Linux/BSD, at that point we put in
> > > the
> > > > > initial compiler checks a suitable check for them being present and
> > > output
> > > > > a suitable error if not found.
> > 
> > Exactly. Capabilities checks is the right way to go when cross compiling.
> > 
> > > >
> > > > OK looks good
> > > 
> > > Note: RHEL 7 official end of maintenance support is not until June 2024.
> > > 
> > 
> > It was agreed to abandon RHEL 7, mainly driven by the need for C11 stdatomic.h, which is not supported by the GCC C compiler included with RHEL 7. So it pains me to admit that Stephen has a valid point here, after it turned out that the GCC g++ is not C11 compatible.
> 
> we would substantially reduce porting delta to retain C11, there are a
> number of other things that help with portability from C11 that we can
> utilized that i hadn't brought up before since it had been resolved to
> adopt it.
> 
> it would be really unfortunate to say we aren't going to require C11
> since that would cause me to have to bring a lot more conditional
> compile into the tree.
> 
> just fyi
>
As far as I know we are requiring C11, and the meson.build file on main
tree currently has set the minimum for that. We just haven't got code in
there yet that uses the C11 atomics, which is the bit that is missing from
the RHEL 7 compiler.

I agree that we should not actually actively support RHEL 7 - I just
wouldn't call attention to the fact that it's no longer supported if it
still happens to work. Once we actually break it, I'm all for documenting
that it's not supported. [NOTE: I both cases, I'm not saying that we call
it out explicitly as supported either - I'm just talking about a release
note entry saying the opposite!]

/Bruce

RE: [PATCH v5] build: update DPDK to use C11 standard

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Friday, 11 August 2023 10.53
> 
> On Thu, Aug 10, 2023 at 03:34:43PM -0700, Tyler Retzlaff wrote:
> > On Thu, Aug 10, 2023 at 08:17:23PM +0200, Morten Brørup wrote:
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Thursday, 10 August 2023 19.03
> > > >
> > > > On Thu, 10 Aug 2023 18:49:09 +0200
> > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >
> > > > > 10/08/2023 18:35, Bruce Richardson:
> > > > > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger
> wrote:
> > > > > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > > >
> > > > > > > > 03/08/2023 15:36, David Marchand:
> > > > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > > > > >
> > > > > > > > > > As previously announced, DPDK 23.11 will require a C11
> > > > supporting
> > > > > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > > > > >
> > > > > > > > > > Forcing use of the C standard, rather than the
> standard with
> > > > > > > > > > GNU extensions, means that some posix definitions
> which are
> > > > not in
> > > > > > > > > > the C standard are unavailable by default. We fix this
> by
> > > > ensuring
> > > > > > > > > > the correct defines or cflags are passed to the
> components
> > > > that
> > > > > > > > > > need them.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Bruce Richardson
> <bruce.richardson@intel.com>
> > > > > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > > Acked-by: Tyler Retzlaff
> <roretzla@linux.microsoft.com>
> > > > > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > > > > >
> > > > > > > > > The CI results look good.
> > > > > > > > >
> > > > > > > > > Applied, thanks!
> > > > > > > >
> > > > > > > > The compiler support is updated, that's fine.
> > > > > > > > Should we go further and document some major Linux
> distributions?
> > > > > > > > One concern is to make clear RHEL 7 is not supported
> anymore.
> > > > > > > > Should it be a release note?
> > > > > > > >
> > > > > >
> > > > > > Well, DPDK currently is still building fine on Centos 7 for
> me, so
> > > > let's
> > > > > > hold off on claiming anything until it's definitely broken.
> > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Should be addressed in linux/sys_reqs.rst as well as
> deprecation
> > > > notice.
> > > > > > > Also, is it possible to add automated check in build for
> compiler
> > > > version?
> > > > > >
> > > > > > I'd be a little careful about what we claim, and I think
> current docs
> > > > are
> > > > > > accurate vs our original plans. What we didn't plan to support
> was
> > > > the GCC
> > > > > > and Clang compiler versions in RHEL 7, but if one installs an
> updated
> > > > GCC,
> > > > > > for example, the build should be fine on RHEL 7.
> > > > > >
> > > > > > Now, though, we are having to re-evaluate our use of
> stdatomics,
> > > > which
> > > > > > means we may not actually break RHEL 7 compatibility after
> all. We'll
> > > > have
> > > > > > to "watch this space" as the saying goes!
> > > > > >
> > > > > > Overall, I think the approach of build-time checks is the
> best, but
> > > > not
> > > > > > for specific versions, but instead for capabilities. If/when
> we add
> > > > support
> > > > > > for stdatomics to DPDK builds on Linux/BSD, at that point we
> put in
> > > > the
> > > > > > initial compiler checks a suitable check for them being
> present and
> > > > output
> > > > > > a suitable error if not found.
> > >
> > > Exactly. Capabilities checks is the right way to go when cross
> compiling.
> > >
> > > > >
> > > > > OK looks good
> > > >
> > > > Note: RHEL 7 official end of maintenance support is not until June
> 2024.
> > > >
> > >
> > > It was agreed to abandon RHEL 7, mainly driven by the need for C11
> stdatomic.h, which is not supported by the GCC C compiler included with
> RHEL 7. So it pains me to admit that Stephen has a valid point here,
> after it turned out that the GCC g++ is not C11 compatible.
> >
> > we would substantially reduce porting delta to retain C11, there are a
> > number of other things that help with portability from C11 that we can
> > utilized that i hadn't brought up before since it had been resolved to
> > adopt it.
> >
> > it would be really unfortunate to say we aren't going to require C11
> > since that would cause me to have to bring a lot more conditional
> > compile into the tree.
> >
> > just fyi
> >
> As far as I know we are requiring C11, and the meson.build file on main
> tree currently has set the minimum for that. We just haven't got code in
> there yet that uses the C11 atomics, which is the bit that is missing
> from
> the RHEL 7 compiler.
> 
> I agree that we should not actually actively support RHEL 7 - I just
> wouldn't call attention to the fact that it's no longer supported if it
> still happens to work. Once we actually break it, I'm all for
> documenting
> that it's not supported. [NOTE: I both cases, I'm not saying that we
> call
> it out explicitly as supported either - I'm just talking about a release
> note entry saying the opposite!]

If I was using RHEL 7, and DPDK degraded the RHEL 7 support level (e.g. not testing it in CI anymore) with a release, I would certainly want this to be highlighted in the release notes! "Not known to be broken, might work" and "passed validation" are two very different things in a production environment. :-)

Anyway, Bruce's point is valid; it's not binary, so let's not scare RHEL 7 users more than we have to.

> 
> /Bruce