Re: How does CI system get updated?

[Patrick Robb <probb@iol.unh.edu>]

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 <probb@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
> <stephen@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.