Arch Linux User Repository

I would recommend against modifying /etc/makepkg.conf or other global system files. Any hacks applied there are likely to cause problems when compiling other packages, and in ways that may be very difficult to detect. Since the bug is specific to this package, any fixes or workarounds should be made in this package or upstream, not in the global system configuration.

Digging a bit deeper, I found another fix that I think is even cleaner than setting WINEPATH:

--- PKGBUILD.orig   2024-04-08 17:34:27.924474576 +0200
+++ PKGBUILD    2024-04-08 17:33:41.717364277 +0200
@@ -38,6 +38,7 @@

 build() {
   cd "${srcdir}"/${pkgname#mingw-w64-}-${pkgver}
+  export CHOST=$(./config.guess)
   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

The reason this works is that i686-w64-mingw32-configure invokes the configure script like this:

${config_path}/configure \
  --host=i686-w64-mingw32 --target=i686-w64-mingw32 --build="$CHOST" \
  --prefix=/usr/i686-w64-mingw32 --libdir=/usr/i686-w64-mingw32/lib --includedir=/usr/i686-w64-mingw32/include \
  --enable-shared --enable-static "$@"

Normally, CHOST is empty, and when --build is empty, the curl configure script tries to guess whether it's cross-compiling as discussed before. But when --build is nonempty and different from --host, then the configure script decides, correctly, that it's cross-compiling and does not perform any runtime checks, which is what we want.

The advantage of this fix compared to setting WINEPATH just in case wine is installed, is that with this fix no runtime checks are performed, regardless of whether wine is installed or not, so the configure process works the same in the clean chroot as on a live system with wine installed.

If you need to add such workaround then probably /etc/makepkg.conf (which actually can contain arbitrary variables) is the right place. Maybe it is also better to get rid of /usr/lib/binfmt.d/wine.conf which apparently is part of the regular wine package.

...which also suggests another workaround: sabotaging wine e.g. by running export WINEPREFIX=/nonexistent before makepkg will cause the build to behave the same as in the clean chroot. But good luck figuring that out from the error message alone!

@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?