[4/4] devtools: add Windows cross-build test with MinGW

Message ID 20200614225747.3839569-5-thomas@monjalon.net (mailing list archive)
State Superseded, archived
Delegated to: David Marchand
Headers
Series add PPC and Windows to meson test |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/travis-robot success Travis build: passed
ci/Intel-compilation success Compilation OK

Commit Message

Thomas Monjalon June 14, 2020, 10:57 p.m. UTC
  The Meson cross file is renamed from meson_mingw.txt to cross-mingw,
and is added to test-meson-builds.sh.

The only example supported on Windows so far is "helloworld",
that's why the default list of examples is overriden.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 config/x86/{meson_mingw.txt => cross-mingw} | 0
 devtools/test-meson-builds.sh               | 3 +++
 doc/guides/windows_gsg/build_dpdk.rst       | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)
 rename config/x86/{meson_mingw.txt => cross-mingw} (100%)
  

Comments

Thomas Monjalon June 14, 2020, 11:09 p.m. UTC | #1
15/06/2020 00:57, Thomas Monjalon:
> The Meson cross file is renamed from meson_mingw.txt to cross-mingw,
> and is added to test-meson-builds.sh.
> 
> The only example supported on Windows so far is "helloworld",
> that's why the default list of examples is overriden.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---

There is a warning with MinGW on Linux:

In file included from lib/librte_eal/include/rte_eal.h:15,
                 from lib/librte_eal/common/eal_common_options.c:26:
lib/librte_eal/common/eal_common_options.c:
	In function ‘eal_adjust_config’:
lib/librte_eal/windows/include/sched.h:63:55: error:
	‘default_set._bits[1]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   63 |   (dst)->_bits[_i] = (src1)->_bits[_i] & (src2)->_bits[_i]; \
      |                                                       ^


% x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc (GCC) 10.1.0


It looks to be a false positive, but we need to find a way to remove
the warning with a code change.

This workaround in lib/librte_eal/common/eal_common_options.c
makes 200% sure the default_set is initialized:

-       if (pthread_getaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
-                               &default_set))
-               CPU_ZERO(&default_set);
-
+       CPU_ZERO(&default_set);
+       pthread_getaffinity_np(pthread_self(),
+                       sizeof default_set, &default_set);
  
Dmitry Kozlyuk June 15, 2020, 1:05 a.m. UTC | #2
> It looks to be a false positive, but we need to find a way to remove
> the warning with a code change.
> 
> This workaround in lib/librte_eal/common/eal_common_options.c
> makes 200% sure the default_set is initialized:
> 
> -       if (pthread_getaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
> -                               &default_set))
> -               CPU_ZERO(&default_set);
> -
> +       CPU_ZERO(&default_set);
> +       pthread_getaffinity_np(pthread_self(),
> +                       sizeof default_set, &default_set);
>

Doesn't look like a false-positive to me. That's where it's been spotted
and explained before:

	https://mails.dpdk.org/archives/dev/2020-May/168634.html

And this series eliminates it along with other improvements:

	http://patchwork.dpdk.org/patch/70727/
  
Thomas Monjalon June 15, 2020, 7:51 a.m. UTC | #3
15/06/2020 03:05, Dmitry Kozlyuk:
> > It looks to be a false positive, but we need to find a way to remove
> > the warning with a code change.
> > 
> > This workaround in lib/librte_eal/common/eal_common_options.c
> > makes 200% sure the default_set is initialized:
> > 
> > -       if (pthread_getaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
> > -                               &default_set))
> > -               CPU_ZERO(&default_set);
> > -
> > +       CPU_ZERO(&default_set);
> > +       pthread_getaffinity_np(pthread_self(),
> > +                       sizeof default_set, &default_set);
> >
> 
> Doesn't look like a false-positive to me. That's where it's been spotted
> and explained before:
> 
> 	https://mails.dpdk.org/archives/dev/2020-May/168634.html
> 
> And this series eliminates it along with other improvements:
> 
> 	http://patchwork.dpdk.org/patch/70727/

I see.
So the fix must be explained (and probably a separate patch).
  

Patch

diff --git a/config/x86/meson_mingw.txt b/config/x86/cross-mingw
similarity index 100%
rename from config/x86/meson_mingw.txt
rename to config/x86/cross-mingw
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 1cde17a2e5..52635c73d1 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -200,6 +200,9 @@  if [ "$ok" = "false" ] ; then
 fi
 build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine $use_shared
 
+# x86 MinGW
+build build-x86-mingw $srcdir/config/x86/cross-mingw -Dexamples=helloworld
+
 # generic armv8a with clang as host compiler
 f=$srcdir/config/arm/arm64_armv8_linux_gcc
 export CC="clang"
diff --git a/doc/guides/windows_gsg/build_dpdk.rst b/doc/guides/windows_gsg/build_dpdk.rst
index d46e84e3fb..d517f08f0d 100644
--- a/doc/guides/windows_gsg/build_dpdk.rst
+++ b/doc/guides/windows_gsg/build_dpdk.rst
@@ -109,7 +109,7 @@  Depending on the distribution, paths in this file may need adjustments.
 
 .. code-block:: console
 
-    meson --cross-file config/x86/meson_mingw.txt -Dexamples=helloworld build
+    meson --cross-file config/x86/cross-mingw -Dexamples=helloworld build
     ninja -C build