Skip to contentSkip to conversation

How does CI system get updated?

DISCUSSION Stephen Hemminger 2 participants 4 messages Jul 25, 2024 – Jul 26, 2024

lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw

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.

Quoted 21 lines · Stephen Hemminger

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.

#2 lore raw

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

Quoted 38 lines · Patrick Robb

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.

Quoted 21 lines · Stephen Hemminger

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.

#3 lore raw
Quoted 16 lines · On Fri, 26 Jul 2024 12:34:25 -0400 Patrick Robb <[email protected]> wrote:

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.

Quoted 5 lines

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

Yes, projects move we need to keep links up to date.