> I think having the choice between GCC and Clang for Windows is very cool.
>
> When starting the Windows port, I asked the fundamental question of the
> supported compilers. The answer was MinGW adds "non-standard" DLLs:
> https://mails.dpdk.org/archives/dev/2019-January/124236.html
Indeed, it does add a pthread implementation DLL, I even documented it. It
presents no technical or legal trouble though.
> Now the question is to know which one is the easiest to use?
The issues are a few (almost all in this message), after they are resolved,
there is no significant difference. With MinGW, more things work out of the
box. It also allows for immediate cross-compilation from Linux, which is
important while Windows drivers are unstable and can crash the system hard.
> If I understand well, MinGW brings the missing parts we are trying
> to add in the DPDK repository for compliance with POSIX libraries.
Yes, having pthread implementation out-of-the-box helps with porting EAL.
Clang can use external pthread, e. g. winpthreads [0] (not to be confused with
winpthread without S). MinGW doesn't aim to provide POSIX support, it only
brings the parts required for GCC toolchain.
Clang has structure alignment issue, which is a show-stopper for rte_mbuf,
because its carefully crafted layout is broken and becomes 3 cache-lines
instead of two:
https://bugs.llvm.org/show_bug.cgi?id=24383
For GCC, there is a way force rte_mbuf layout:
https://github.com/PlushBeaver/dpdk/commit/37f052cb18d1d5d425818196d5e1d15a7ada0de0
GCC, in its turn, has an AVX bug, although it can be worked around by
force-inlining functions in rte_acl (as I did):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
[0]:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/
--
Dmitry Kozlyuk
