mbox series

[0/6] MinGW-w64 support

Message ID 20200131030744.19596-1-dmitry.kozliuk@gmail.com (mailing list archive)
Headers
Series MinGW-w64 support |

Message

Dmitry Kozlyuk Jan. 31, 2020, 3:07 a.m. UTC
  This patch series add support for building DPDK using MinGW-w64.

MinGW-w64 provides GNU toolchain and independent platform SDK on
Windows. It also supports cross-compilation to Windows from POSIX
systems by providing cross tollchains and libraries [0]. It does NOT
emulate a full POSIX environment, like Cygwin or MSYS do.

There are advantages in using MinGW-w64 in addition to Clang:

1. Cross-compilation out-of-the-box. MinGW-w64 is provides a pthread
   implementation, GNU getopt, and Windows platform SDK.

2. Easier porting of POSIX applications using DPDK to Windows, because
   application code can use the same benefits as mentioned above.

3. Having both primary compilers enabled on Windows provides more
   diagnostics and generally prevents non-portable code.

[0]: http://mingw-w64.org

Dmitry Kozlyuk (6):
  eal: introduce portable format attribute
  eal: use portable format attribute
  cmdline: use portable format attribute
  build: MinGW-w64 support for Meson
  build: add cross-file for MinGW-w64
  doc: guide for Windows build using MinGW-w64

 config/meson.build                          | 14 +++++
 doc/guides/windows_gsg/build_dpdk.rst       | 57 +++++++++++++++++----
 lib/librte_cmdline/cmdline.h                |  4 +-
 lib/librte_eal/common/include/rte_common.h  | 17 +++++-
 lib/librte_eal/common/include/rte_debug.h   |  2 +-
 lib/librte_eal/common/include/rte_devargs.h |  2 +-
 lib/librte_eal/common/include/rte_log.h     |  4 +-
 lib/librte_eal/meson.build                  |  3 ++
 lib/meson.build                             |  8 ++-
 meson_mingw.txt                             | 14 +++++
 10 files changed, 108 insertions(+), 17 deletions(-)
 create mode 100644 meson_mingw.txt
  

Comments

Narcisa Ana Maria Vasile Feb. 5, 2020, 1:49 a.m. UTC | #1
Hi Dmitry, 

Thanks for the patches! I was able to compile and run natively, after applying the Meson patch that you mentioned.

I'm having some trouble with cross-compilation:

python3 meson.py -Dexamples=helloworld ../../dpdk/build ../../dpdk --cross-file ../../dpdk/meson_mingw.txt
The Meson build system
Version: 0.53.1
Source dir: /mnt/d/dpdk
Build dir: /mnt/d/dpdk/build
Build type: cross build
Program cat found: YES (/bin/cat)
Project name: DPDK
Project version: 20.02.0-rc1
C compiler for the build machine: cc (gcc 7.4.0 "cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0")
C linker for the build machine: cc GNU ld.bfd 2.30

meson.build:4:0: ERROR: Unable to determine dynamic linker

Any ideas on how to fix this issue?

Thanks,
Narcisa Vasile

-----Original Message-----
From: dev <dev-bounces@dpdk.org> On Behalf Of Dmitry Kozlyuk
Sent: Thursday, January 30, 2020 7:08 PM
To: dev@dpdk.org
Cc: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>; Bruce Richardson <bruce.richardson@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Olivier Matz <olivier.matz@6wind.com>; Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>; Omar Cardona <ocardona@microsoft.com>; Pallavi Kadam <pallavi.kadam@intel.com>; Ranjit Menon <ranjit.menon@intel.com>; John McNamara <john.mcnamara@intel.com>; Marko Kovacevic <marko.kovacevic@intel.com>
Subject: [EXTERNAL] [dpdk-dev] [PATCH 0/6] MinGW-w64 support

This patch series add support for building DPDK using MinGW-w64.

MinGW-w64 provides GNU toolchain and independent platform SDK on Windows. It also supports cross-compilation to Windows from POSIX systems by providing cross tollchains and libraries [0]. It does NOT emulate a full POSIX environment, like Cygwin or MSYS do.

There are advantages in using MinGW-w64 in addition to Clang:

1. Cross-compilation out-of-the-box. MinGW-w64 is provides a pthread
   implementation, GNU getopt, and Windows platform SDK.

2. Easier porting of POSIX applications using DPDK to Windows, because
   application code can use the same benefits as mentioned above.

3. Having both primary compilers enabled on Windows provides more
   diagnostics and generally prevents non-portable code.

[0]: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmingw-w64.org&amp;data=02%7C01%7CNarcisa.Vasile%40microsoft.com%7C9ecc756fe41941539c3208d7a5fac686%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160368803628802&amp;sdata=GcrGNIMkp0PjfmOXoKkbdA4ttMYQLv3cB24riDfPx%2Fk%3D&amp;reserved=0

Dmitry Kozlyuk (6):
  eal: introduce portable format attribute
  eal: use portable format attribute
  cmdline: use portable format attribute
  build: MinGW-w64 support for Meson
  build: add cross-file for MinGW-w64
  doc: guide for Windows build using MinGW-w64

 config/meson.build                          | 14 +++++
 doc/guides/windows_gsg/build_dpdk.rst       | 57 +++++++++++++++++----
 lib/librte_cmdline/cmdline.h                |  4 +-
 lib/librte_eal/common/include/rte_common.h  | 17 +++++-
 lib/librte_eal/common/include/rte_debug.h   |  2 +-
 lib/librte_eal/common/include/rte_devargs.h |  2 +-
 lib/librte_eal/common/include/rte_log.h     |  4 +-
 lib/librte_eal/meson.build                  |  3 ++
 lib/meson.build                             |  8 ++-
 meson_mingw.txt                             | 14 +++++
 10 files changed, 108 insertions(+), 17 deletions(-)  create mode 100644 meson_mingw.txt

--
2.25.0
  
Dmitry Kozlyuk Feb. 5, 2020, 5:43 a.m. UTC | #2
Hi Narcisa,

> I'm having some trouble with cross-compilation:
> 
> python3 meson.py -Dexamples=helloworld ../../dpdk/build ../../dpdk --cross-file ../../dpdk/meson_mingw.txt
> The Meson build system
> Version: 0.53.1
> Source dir: /mnt/d/dpdk
> Build dir: /mnt/d/dpdk/build
> Build type: cross build
> Program cat found: YES (/bin/cat)
> Project name: DPDK
> Project version: 20.02.0-rc1
> C compiler for the build machine: cc (gcc 7.4.0 "cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0")
> C linker for the build machine: cc GNU ld.bfd 2.30
> 
> meson.build:4:0: ERROR: Unable to determine dynamic linker
> 
> Any ideas on how to fix this issue?

Use Meson 0.52, version 0.53 introduced this regression among others:
https://github.com/mesonbuild/meson/issues/6431
DPDK CI also has Meson version pinned to 0.52, see
http://mails.dpdk.org/archives/dev/2020-January/154357.html
I find it handy to switch Meson versions via pip3.

Here's Meson 0.52 output:

> $ meson --cross-file meson_mingw.txt build/cross/mingw
> The Meson build system
> Version: 0.52.0
> Source dir: /home/dmitry/src/dpdk.clean
> Build dir: /home/dmitry/src/dpdk.clean/build/cross/mingw
> Build type: cross build
> Program cat found: YES (/usr/bin/cat)
> Project name: DPDK
> Project version: 20.02.0-rc1
> C compiler for the build machine: cc (gcc 9.2.0 "cc (GCC) 9.2.0")
> C linker for the build machine: GNU ld.bfd 2.33.1
> C compiler for the host machine: /usr/bin/x86_64-w64-mingw32-gcc (gcc 9.2.0
> "x86_64-w64-mingw32-gcc (GCC) 9.2.0") 
> C linker for the host machine: GNU ld.bfd 2.33.1

As you can see, it correctly picks up CC and LD for host machine, unlike 0.53.
  
David Marchand Feb. 5, 2020, 9:26 a.m. UTC | #3
On Wed, Feb 5, 2020 at 6:43 AM Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> wrote:
>
> Hi Narcisa,
>
> > I'm having some trouble with cross-compilation:
> >
> > python3 meson.py -Dexamples=helloworld ../../dpdk/build ../../dpdk --cross-file ../../dpdk/meson_mingw.txt
> > The Meson build system
> > Version: 0.53.1
> > Source dir: /mnt/d/dpdk
> > Build dir: /mnt/d/dpdk/build
> > Build type: cross build
> > Program cat found: YES (/bin/cat)
> > Project name: DPDK
> > Project version: 20.02.0-rc1
> > C compiler for the build machine: cc (gcc 7.4.0 "cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0")
> > C linker for the build machine: cc GNU ld.bfd 2.30
> >
> > meson.build:4:0: ERROR: Unable to determine dynamic linker
> >
> > Any ideas on how to fix this issue?
>
> Use Meson 0.52, version 0.53 introduced this regression among others:
> https://github.com/mesonbuild/meson/issues/6431
> DPDK CI also has Meson version pinned to 0.52, see
> http://mails.dpdk.org/archives/dev/2020-January/154357.html
> I find it handy to switch Meson versions via pip3.

Err, we decided to pin to 0.47.1 as it is the documented minimal
supported version.
http://inbox.dpdk.org/dev/20200108110251.20916-1-david.marchand@redhat.com/

So the CI is stuck to the 0.47.1 version, not 0.52.
Do you need something from a newer meson for Windows support? That
would have to be documented.


--
David Marchand
  
Dmitry Kozlyuk Feb. 5, 2020, 8:59 p.m. UTC | #4
> > Use Meson 0.52, version 0.53 introduced this regression among others:
> > https://github.com/mesonbuild/meson/issues/6431
> > DPDK CI also has Meson version pinned to 0.52, see
> > http://mails.dpdk.org/archives/dev/2020-January/154357.html
> > I find it handy to switch Meson versions via pip3.  
> 
> Err, we decided to pin to 0.47.1 as it is the documented minimal
> supported version.
> http://inbox.dpdk.org/dev/20200108110251.20916-1-david.marchand@redhat.com/
> 
> So the CI is stuck to the 0.47.1 version, not 0.52.
> Do you need something from a newer meson for Windows support? That
> would have to be documented.

My bad, can't tell why I decided that 0.52 was pinned. I verified building
with Meson 0.47.1, both cross and native, and it works well.

Apologies to Narcisa for misguidance.
  
Narcisa Ana Maria Vasile Feb. 5, 2020, 9:02 p.m. UTC | #5
On 2/5/2020 12:59 PM, Dmitry Kozlyuk wrote:

Use Meson 0.52, version 0.53 introduced this regression among others:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmesonbuild%2Fmeson%2Fissues%2F6431&amp;data=02%7C01%7CNarcisa.Vasile%40microsoft.com%7C3a156299509a4e20c63108d7aa7e5cf0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165332017516796&amp;sdata=eOx4P6FJLWzC7pmpS%2F0xvA2VzjFJ0YCrxRc7ris%2BKhU%3D&amp;reserved=0
DPDK CI also has Meson version pinned to 0.52, see
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2020-January%2F154357.html&amp;data=02%7C01%7CNarcisa.Vasile%40microsoft.com%7C3a156299509a4e20c63108d7aa7e5cf0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165332017516796&amp;sdata=Z87jGpDhGqBVdYWXg0b66kTuOr5x0byCPM9TUel5dZ0%3D&amp;reserved=0
I find it handy to switch Meson versions via pip3.



Err, we decided to pin to 0.47.1 as it is the documented minimal
supported version.
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox.dpdk.org%2Fdev%2F20200108110251.20916-1-david.marchand%40redhat.com%2F&amp;data=02%7C01%7CNarcisa.Vasile%40microsoft.com%7C3a156299509a4e20c63108d7aa7e5cf0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165332017516796&amp;sdata=361djaQtaBeKN%2B9Fjg5IjuQ2dhfjCg0eMlHBVZA3aqw%3D&amp;reserved=0

So the CI is stuck to the 0.47.1 version, not 0.52.
Do you need something from a newer meson for Windows support? That
would have to be documented.



My bad, can't tell why I decided that 0.52 was pinned. I verified building
with Meson 0.47.1, both cross and native, and it works well.

Apologies to Narcisa for misguidance.


No worries, I also cross-compiled using both 0.47.1 and 0.52.0. I was able to generate the helloworld executable and ran it successfully. Thanks!

I did have to apply your patch "eal/windows: refine public interface" before applying the "MinGW-w64 support" patch set, to avoid the errors caused by including "Windows.h" in rte_os.h. So, I guess this patch needs to come first and then the patchset for mingw can be applied.
  
Dmitry Kozlyuk Feb. 5, 2020, 9:21 p.m. UTC | #6
> I did have to apply your patch "eal/windows: refine public interface" before applying the "MinGW-w64 support" patch set, to avoid the errors caused by including "Windows.h" in rte_os.h. So, I guess this patch needs to come first and then the patchset for mingw can be applied.

The cause of the error you've encountered is case-dependent Linux filesystem.
Existing code includes <Windows.h> (capital W), but MinGW-w64 on Linux
packages <windows.h> (lowercase W). I missed it because Windows.h is manually
symlinked to windows.h on my system. Same goes for <BaseTsd.h>.

Thanks for pointing this out, I think it's more appropriate to change
filename case in this patchset v2, because the need for this change is caused
by adding MinGW cross-compilation capability.