Okay I understand better now how we ended up with an older mingw64 version. The DPDK Docs for windows compile direct folks over to (https://sourceforge.net/projects/mingw-w64/files/) to get the prebuilt binaries, but the latest toolchain published there is Mingw64 v8.*, whereas the current version is v11.*. So, when we upgraded to the "latest" published version, we upgraded to that v8.* from years ago. If you look at the mingw64 website downloads page (https://www.mingw-w64.org/downloads/), it directs people over to winlibs.com to download the prebuilt binaries for v11.
I have replaced the Windows Server 2019 CI VM's old mingw64 binaries with the new (v11.*) ones downloaded from winlibs.com, and I see that Stephen's patch now passes the compile test. I can issue a retest for your series once I am all done making the update for the server 2022 machine too. I guess this also raises the question of whether the DPDK docs for the windows mingw64 compile process should be updated to point to winlibs.com instead of sourceforge.net (only has the source code). https://doc.dpdk.org/guides/windows_gsg/build_dpdk.html#option-2-mingw-w64-toolchain On Thu, Jul 25, 2024 at 3:06 PM Patrick Robb <pr...@iol.unh.edu> wrote: > > Hi Stephen, > > This is a UNH Lab system. > > We review our systems for updates once every 4 months. The idea is we > do it early in each DPDK release's development cycle. So, we update > Dockerfiles (for container environments), we apply updates where > needed to persistent systems (for VMs, or baremetal servers). > Obviously the Mingw version for the windows system was a check we have > not been doing. Thank you for spotting this and letting us know. > > We will apply the update and let you know when it's ready. > > > On Thu, Jul 25, 2024 at 11:03 AM Stephen Hemminger > <step...@networkplumber.org> wrote: > > > > > > > > This warning is due to a very old version of Mingw installed in CI system. > > > > ==== 20 line log output for Windows Server 2019 (dpdk_mingw64_compile): ==== > > In file included from ..\lib\net/rte_ip.h:21, > > from ../lib/net/rte_dissect.c:20: > > C:/mingw64/mingw64/x86_64-w64-mingw32/include/ws2tcpip.h:447:63: note: > > expected 'PVOID' {aka 'void *'} but argument is of type 'const uint8_t *' > > {aka 'const unsigned char *'} > > WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr, LPSTR > > pStringBuf, size_t StringBufSize); > > ~~~~~~^~~~~ > > ../lib/net/rte_dissect.c:292:29: error: passing argument 2 of 'inet_ntop' > > discards 'const' qualifier from pointer target type > > [-Werror=discarded-qualifiers] > > inet_ntop(AF_INET6, ip6_hdr->dst_addr, dbuf, sizeof(dbuf)); > > ~~~~~~~^~~~~~~~~~ > > In file included from ..\lib\net/rte_ip.h:21, > > from ../lib/net/rte_dissect.c:20: > > C:/mingw64/mingw64/x86_64-w64-mingw32/include/ws2tcpip.h:447:63: note: > > expected 'PVOID' {aka 'void *'} but argument is of type 'const uint8_t *' > > {aka 'const unsigned char *'} > > WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr, LPSTR > > pStringBuf, size_t StringBufSize); > > ~~~~~~^~~~~ > > > > It was fixed upstream in Mingw 4 years ago.
