curl_addrinfo.c error: 'getaddrinfo' undeclared in old-MinGW CI builds #9214

bagder · 2022-07-26T22:08:07Z

The appveyor CI builds with cmake using Visual Studio 2022 are permafailing since a while back. See log

The compiler errors are:

C:/projects/curl/lib/curl_addrinfo.c: In function 'Curl_getaddrinfo_ex':
C:/projects/curl/lib/curl_addrinfo.c:192:5: error: implicit declaration of function 'freeaddrinfo'; did you mean 'getaddrinfo'? [-Werror=implicit-function-declaration]
  192 |     freeaddrinfo(aihead);
      |     ^~~~~~~~~~~~
      |     getaddrinfo
C:/projects/curl/lib/curl_addrinfo.c:192:5: error: nested extern declaration of 'freeaddrinfo' [-Werror=nested-externs]
C:/projects/curl/lib/curl_addrinfo.c: In function 'curl_dbg_getaddrinfo':
C:/projects/curl/lib/curl_addrinfo.c:556:14: error: 'getaddrinfo' undeclared (first use in this function); did you mean 'addrinfo'?
  556 |   int res = (getaddrinfo)(hostname, service, hints, result);
      |              ^~~~~~~~~~~
      |              addrinfo
C:/projects/curl/lib/curl_addrinfo.c:556:14: note: each undeclared identifier is reported only once for each function it appears in
cc1.exe: all warnings being treated as errors
make[2]: *** [lib/CMakeFiles/libcurl.dir/build.make:242: lib/CMakeFiles/libcurl.dir/curl_addrinfo.c.obj] Error 1

The text was updated successfully, but these errors were encountered:

gvanem · 2022-07-27T05:56:57Z

Looks like a _WIN32_WINNT >= 0x0602 is not set on AppVeyor. But I fail to understand which SDK is used and how CMake uses it.

Edit. From the above log, it seems to use the old SDK under C:\Program Files\Microsoft SDKs\Windows\v7.1.

mback2k · 2022-08-15T06:08:53Z

Ping @MarcelRaad

MarcelRaad · 2022-08-15T08:20:43Z

This is the classic MinGW build, which uses MinGW's own SDK and defaults to _WIN32_WINNT = 0x500.
The output clearly says "-- Looking for freeaddrinfo - not found", so we shouldn't try to use it. I haven't investigated yet what broke it.

MarcelRaad · 2022-08-15T15:54:15Z

8ba22ff removed forcing _WIN32_WINNT to 0x501, which previously made getaddrinfo and freeaddrinfo available for classic MinGW.
But why does

curl/CMakeLists.txt

Line 1069 in d48dd15

check_symbol_exists(getaddrinfo "${CURL_INCLUDES}" HAVE_GETADDRINFO)

set HAVE_GETADDRINFO? The autotools builds correctly determines it to be unavailable, and I currently don't have a CMake setup usable with classic MinGW 😕

vszakats · 2022-08-15T18:14:55Z

@MarcelRaad: In CMake/Platforms/WindowsCache.cmake there is this:

    if(ENABLE_IPV6)
      set(HAVE_GETADDRINFO 1)
    else()
      set(HAVE_GETADDRINFO 0)
    endif()

Can it be related to this issue?

(Half-guessing, so this may totally be wrong, but this file seems to be offering predefined configuration values for Windows, and for these, the actual test is not performed?)

The Visual Studio 2022 / cmake / msys build has failed to build for months. Removing it. Fixes #9214

Fixes #9214 Suggested-by: Marcel Raad

[TODO: commit message] Ref: curl#9393 Ref: curl#9214 Closes #xxxx Fixes #xxxx

Commit d08ee3c (in 2013) added logic that automatically assumed `getaddrinfo()` to be present for builds with IPv6 enabled. As it turns out, certain toolchains (e.g. classic MSYS) by default target older Windows versions, and thus do not support `getaddrinfo()` out of the box. This fact was masked for a while by CMake builds forcing a newer Windows version, but that logic got deleted in commit 8ba22ff. Since then, some builds started failing due to IPv6 enabled, `HAVE_GETADDRINFO` being set, but `getaddrinfo()` in fact missing. It also turns out that IPv6 works without `getaddrinfo()` since commit 67a08dc (from 2019, via curl#4662). So, to resolve all this, we can now revert the initial commit, thus restoring correct `getaddrinfo()` detection and support IPv6 regardless of its outcome. Reported-by: Daniel Stenberg Fixes curl#9214 Fixes curl#9393 Fixes curl#9395 Closes curl#9396

Commit d08ee3c (in 2013) added logic that automatically assumed `getaddrinfo()` to be present for builds with IPv6 enabled. As it turns out, certain toolchains (e.g. "original" MinGW) by default target older Windows versions, and thus do not support `getaddrinfo()` out of the box. The issue was masked for a while by CMake builds forcing a newer Windows version, but that logic got deleted in commit 8ba22ff. Since then, some CI builds started failing due to IPv6 enabled, `HAVE_GETADDRINFO` set, but `getaddrinfo()` in fact missing. It also turns out that IPv6 works without `getaddrinfo()` since commit 67a08dc (from 2019, via curl#4662). So, to resolve all this, we can now revert the initial commit, thus restoring `getaddrinfo()` detection and support IPv6 regardless of its outcome. Reported-by: Daniel Stenberg Fixes curl#9214 Closes curl#9396

1. Re-enable `HAVE_GETADDRINFO` detection on Windows Commit d08ee3c (in 2013) added logic that automatically assumed `getaddrinfo()` to be present for builds with IPv6 enabled. As it turns out, certain toolchains (e.g. original MinGW) by default target older Windows versions, and thus do not support `getaddrinfo()` out of the box. The issue was masked for a while by CMake builds forcing a newer Windows version, but that logic got deleted in commit 8ba22ff. Since then, some CI builds started failing due to IPv6 enabled, `HAVE_GETADDRINFO` set, but `getaddrinfo()` in fact missing. It also turns out that IPv6 works without `getaddrinfo()` since commit 67a08dc (from 2019, via curl#4662). So, to resolve all this, we can now revert the initial commit, thus restoring `getaddrinfo()` detection and support IPv6 regardless of its outcome. Reported-by: Daniel Stenberg 2. Omit `bcrypt` with original MinGW Original (aka old/legacy) MinGW versions do not support `bcrypt` (introduced with Vista). We already have logic to handle that in `lib/rand.c` and autotools builds, where we do not call the unsupported API and do not link `bcrypt`, respectively, when using old MinGW. This patch ports that logic to CMake, fixing the link error: `c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: cannot find -lbcrypt` Ref: curl#9396 (comment) Ref: https://ci.appveyor.com/project/curlorg/curl/builds/44624888/job/40vle84cn4vle7s0#L508 Regression since 7617251 Fixes curl#9214 Fixes curl#9393 Fixes curl#9395 Closes curl#9396

1. Re-enable `HAVE_GETADDRINFO` detection on Windows Commit d08ee3c (in 2013) added logic that automatically assumed `getaddrinfo()` to be present for builds with IPv6 enabled. As it turns out, certain toolchains (e.g. original MinGW) by default target older Windows versions, and thus do not support `getaddrinfo()` out of the box. The issue was masked for a while by CMake builds forcing a newer Windows version, but that logic got deleted in commit 8ba22ff. Since then, some CI builds started failing due to IPv6 enabled, `HAVE_GETADDRINFO` set, but `getaddrinfo()` in fact missing. It also turns out that IPv6 works without `getaddrinfo()` since commit 67a08dc (from 2019, via curl#4662). So, to resolve all this, we can now revert the initial commit, thus restoring `getaddrinfo()` detection and support IPv6 regardless of its outcome. Reported-by: Daniel Stenberg 2. Omit `bcrypt` with original MinGW Original (aka old/legacy) MinGW versions do not support `bcrypt` (introduced with Vista). We already have logic to handle that in `lib/rand.c` and autotools builds, where we do not call the unsupported API and do not link `bcrypt`, respectively, when using original MinGW. This patch ports that logic to CMake, fixing the link error: `c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: cannot find -lbcrypt` Ref: https://ci.appveyor.com/project/curlorg/curl/builds/44624888/job/40vle84cn4vle7s0#L508 Regression since 7617251 Fixes curl#9214 Fixes curl#9393 Fixes curl#9395 Closes curl#9396

1. Re-enable `HAVE_GETADDRINFO` detection on Windows Commit d08ee3c (in 2013) added logic that automatically assumed `getaddrinfo()` to be present for builds with IPv6 enabled. As it turns out, certain toolchains (e.g. original MinGW) by default target older Windows versions, and thus do not support `getaddrinfo()` out of the box. The issue was masked for a while by CMake builds forcing a newer Windows version, but that logic got deleted in commit 8ba22ff. Since then, some CI builds started failing due to IPv6 enabled, `HAVE_GETADDRINFO` set, but `getaddrinfo()` in fact missing. It also turns out that IPv6 works without `getaddrinfo()` since commit 67a08dc (from 2019, via curl#4662). So, to resolve all this, we can now revert the initial commit, thus restoring `getaddrinfo()` detection and support IPv6 regardless of its outcome. Reported-by: Daniel Stenberg 2. Omit `bcrypt` with original MinGW Original (aka legacy/old) MinGW versions do not support `bcrypt` (introduced with Vista). We already have logic to handle that in `lib/rand.c` and autotools builds, where we do not call the unsupported API and do not link `bcrypt`, respectively, when using original MinGW. This patch ports that logic to CMake, fixing the link error: `c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: cannot find -lbcrypt` Ref: https://ci.appveyor.com/project/curlorg/curl/builds/44624888/job/40vle84cn4vle7s0#L508 Regression since 7617251 Fixes curl#9214 Fixes curl#9393 Fixes curl#9395 Closes curl#9396

bagder added build cmake Windows Windows-specific CI Continuous Integration labels Jul 26, 2022

bagder mentioned this issue Aug 14, 2022

cmake-build issue with getaddrinfo #9313

Closed

bagder added a commit that referenced this issue Aug 30, 2022

appveyor: remove permafailing CI build

95e67f3

The Visual Studio 2022 / cmake / msys build has failed to build for months. Removing it. Fixes #9214

bagder mentioned this issue Aug 30, 2022

appveyor: remove permafailing CI build #9393

Closed

bagder added a commit that referenced this issue Aug 30, 2022

appveyor: pass target windows version to MSVS 2022 + cmake + msys build

cf104c8

Fixes #9214 Suggested-by: Marcel Raad

bagder mentioned this issue Aug 30, 2022

appveyor: pass target windows version to MSVS 2022 + cmake + msys build #9395

Closed

vszakats mentioned this issue Aug 30, 2022

cmake: fix original MinGW builds #9396

Closed

vszakats added a commit to vszakats/curl that referenced this issue Aug 30, 2022

cmake: re-enable HAVE_GETADDRINFO detection on Windows

10864f4

[TODO: commit message] Ref: curl#9393 Ref: curl#9214 Closes #xxxx Fixes #xxxx

vszakats changed the title ~~curl_addrinfo.c error: 'getaddrinfo' undeclared in Visual Studio 2022 CI builds~~ curl_addrinfo.c error: 'getaddrinfo' undeclared in MSYS-classic CI builds Aug 30, 2022

vszakats changed the title ~~curl_addrinfo.c error: 'getaddrinfo' undeclared in MSYS-classic CI builds~~ curl_addrinfo.c error: 'getaddrinfo' undeclared in legacy MinGW CI builds Aug 30, 2022

vszakats changed the title ~~curl_addrinfo.c error: 'getaddrinfo' undeclared in legacy MinGW CI builds~~ curl_addrinfo.c error: 'getaddrinfo' undeclared in old-MinGW CI builds Aug 30, 2022

vszakats closed this as completed in 7cd400a Aug 31, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

curl_addrinfo.c error: 'getaddrinfo' undeclared in old-MinGW CI builds #9214

curl_addrinfo.c error: 'getaddrinfo' undeclared in old-MinGW CI builds #9214

bagder commented Jul 26, 2022

gvanem commented Jul 27, 2022 •

edited

mback2k commented Aug 15, 2022

MarcelRaad commented Aug 15, 2022 •

edited

MarcelRaad commented Aug 15, 2022 •

edited

vszakats commented Aug 15, 2022 •

edited

curl_addrinfo.c error: 'getaddrinfo' undeclared in old-MinGW CI builds #9214

curl_addrinfo.c error: 'getaddrinfo' undeclared in old-MinGW CI builds #9214

Comments

bagder commented Jul 26, 2022

gvanem commented Jul 27, 2022 • edited

mback2k commented Aug 15, 2022

MarcelRaad commented Aug 15, 2022 • edited

MarcelRaad commented Aug 15, 2022 • edited

vszakats commented Aug 15, 2022 • edited

gvanem commented Jul 27, 2022 •

edited

MarcelRaad commented Aug 15, 2022 •

edited

MarcelRaad commented Aug 15, 2022 •

edited

vszakats commented Aug 15, 2022 •

edited