Arch Linux User Repository

@drakkan: I verified it does build in a clean chroot, and I also figured out why.

The configure script tries to detect if it's cross-compiling, by trying to build and run a trivial binary (search config.log for "checking whether we are cross compiling"). When wine isn't installed, this fails, so the configure script sets cross_compiling=yes, and skips further runtime checks, including the runtime check for getaddrinfo(): https://github.com/curl/curl/blob/cfc65fd1ee164113e4b342f2e57e36fdc07c87fd/m4/curl-functions.m4#L1770-L1810

So the build fails only if wine is already installed on the build host, which is unfortunate, because people interested in mingw packages are likely to have wine installed too.

@frecco2, @maksverver can you replicate the reported issue in a clean chroot? The automatic build here worked and wine is not listed as dependency. Anyway I'll try to reproduce and apply the proposed fix or another one when I have some free time. Thank you

@maksverver, I had the same problem. Thanks for the patch!

The current version (8.7.1-1) fails to build for me.

The build fails with:

  CC       libcurl_la-altsvc.lo
In file included from ../../lib/altsvc.c:28:
../../lib/curl_setup.h:624:4: error: #error "Unexpected build: IPv6 is enabled but getaddrinfo was not found."
  624 | #  error "Unexpected build: IPv6 is enabled but getaddrinfo was not found."
      |    ^~~~~

But the root cause is that the configure test for getaddrinfo() has failed:

configure:38226: checking if getaddrinfo seems to work
configure:38346: sh ./run-compiler -o conftest.exe -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fcf-protection -Werror-implicit-function-declaration -Wno-system-headers -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -I/usr/i686-w64-mingw32/include -Wl,-O1,--sort-common,--as-needed -fstack-protector  -L/usr/i686-w64-mingw32/lib conftest.c -lnghttp2 -lidn2 -lssh2 -lssh2 -lcrypt32 -lbcrypt -lws2_32 -lpsl -lbcrypt -ladvapi32 -lcrypt32 -lbcrypt -lssl -lcrypto -lssl -lcrypto -lgdi32 -lwldap32 -lzstd -lzstd -lbrotlidec -lbrotlidec -lz -lws2_32  >&5
configure:38346: $? = 0
configure:38346: ./conftest.exe
006c:err:ole:start_rpcss Failed to start RpcSs service
0024:err:module:import_dll Library libssp-0.dll (which is needed by L"Z:\\home\\maks\\build\\mingw-w64-curl.orig\\src\\curl-8.7.1\\build-i686-w64-mingw32-static\\conftest.exe") not found
0024:err:module:loader_init Importing dlls for L"Z:\\home\\maks\\build\\mingw-w64-curl.orig\\src\\curl-8.7.1\\build-i686-w64-mingw32-static\\conftest.exe" failed, status c0000135
configure:38346: $? = 53
configure: program exited with status 53

The problem is that -fstack-protector flag (which is added to LDFLAGS by /usr/bin/mingw-env) adds a dependency on libssp-0.dll, but that file exists under /usr/i686-w64-mingw32/bin/, NOT /usr/i686-w64-mingw32/lib/.

I was able to work around it by adding the binary directory to WINEPATH before running configure, like so:

--- PKGBUILD.orig   2024-03-30 15:43:29.066584869 +0100
+++ PKGBUILD    2024-03-30 16:22:18.173164563 +0100
@@ -39,16 +39,16 @@
 build() {
   cd "${srcdir}"/${pkgname#mingw-w64-}-${pkgver}
   for _arch in ${_architectures}; do
     configure_args="--with-openssl --enable-ipv6 --with-libidn2 --with-libssh2 --without-ca-bundle --without-random --with-libpsl --with-brotli --with-zstd"
     mkdir -p build-${_arch}-static && pushd build-${_arch}-static
-    ${_arch}-configure $configure_args \
+    WINEPATH=/usr/${_arch}/bin ${_arch}-configure $configure_args \
       --enable-static --disable-shared ..
     make
     popd
     mkdir -p build-${_arch} && pushd build-${_arch}
-    ${_arch}-configure $configure_args \
+    WINEPATH=/usr/${_arch}/bin ${_arch}-configure $configure_args \
       --disable-static --enable-shared ..
     make
     popd
   done
 }

Not sure if that's the correct way to fix it, but I thought I'd share it in case anyone else finds this useful.

Note that WINEPATH being unset is not a problem when running the final executable, because curl.exe gets installed in the bin/ directory that also contains libssp-0.dll, and Wine searches for libraries in the executable's directory by default.

could you bump the release number ? I found out it needs a rebuild after the libpsl update

curl.exe does work indeed, but not my example at https://raw.githubusercontent.com/xantares/pkgtest/master/test/t_curl.c

I found out it is due to libpsl, could psl be disabled until this is fixed, see:

https://aur.archlinux.org/packages/mingw-w64-libpsl#comment-907281

@xantares, locally compiled curl.exe works for me, I also tested the curl build from here and it works too. Do you have issues using curl as library in your project while curl.exe works for you?

there may be a problem when the dll loads, enven on a simple example:

Mingw-w64 runtime failure: 32 bit pseudo relocation at 0000000000C7BBEC out of range, targeting 00000001DE6928E0, yielding the value 00000001DDA16CF0.

I can reproduce @Heziode issue: because I have mingw-w64-libssh2 installed, the test for finding a replacement for in_addr_t is trying to link with -lssh2, which fails because the libraries provided by mingw-w64-libssh2 are incorrectly named (liblibssh2.dll.a of libssh2.dll.a).