Arch Linux User Repository

Another update: downgrading to mingw-w64-gcc-13.1.0-1 and mingw-w64-binutils-2.39-1 seems to fix the regression.

@kokokoshka: thanks for reporting. It looks like the breakage is caused by a regression in mingw-w64-openssl.

edit: I initially wrote that downgrading to mingw-w64-openssl-3.3.1 would solve the isuse but that doesn't appear to be the case. All rebuilds of older packages seem to have increased in size. Maybe it's due to a change in compiler settings. This might be quite annoying to debug...

Tried to use this library. Unfortunately, even test case don't work. Did the build on two different machines. On one it's partially works, but crashes after curl_easy_init call. On another it does following:

0024:err:module:loader_init "libcurl-4.dll" failed to initialize, aborting
0024:err:module:loader_init Initializing dlls for L"Z:\\home\\kokokoshka\\simple.exe" failed, status c0000005

In Windows it's crashes with unknown error too.

Hi everyone. I just adopted this package and updated it to version 8.9.1.

I verified that basic functionality works with the following sample code (note that I changed the HTTPS url to HTTP, because certificates aren't located automatically):

cat >simple.c <<EOF
#include <stdio.h>
#include <curl/curl.h>

int main(void)
{
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
    curl_easy_setopt(curl, CURLOPT_URL, "http://example.com");
    /* example.com is redirected, so we tell libcurl to follow redirection */
    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);

    /* Perform the request, res gets the return code */
    res = curl_easy_perform(curl);
    /* Check for errors */
    if(res != CURLE_OK)
      fprintf(stderr, "curl_easy_perform() failed: %s\n",
              curl_easy_strerror(res));

    /* always cleanup */
    curl_easy_cleanup(curl);
  }
  return 0;
}
EOF

To build and run a dynamically linked binary:

x86_64-w64-mingw32-gcc -o simple simple.c -lcurl
WINEPATH=/usr/x86_64-w64-mingw32/bin ./simple.exe

To build and run a statically linked binary:

x86_64-w64-mingw32-gcc -static -o simple simple.c $(x86_64-w64-mingw32-pkg-config --static --cflags --libs libcurl | sed  's/-R/-Wl,-rpath,/g')
./simple.exe

Let me know if these use cases don't work, and feel free to suggest patches to improve the package.

@maksverver

I'm aware. I just wanted to provide logs-like info instead of explaining basic stuff.

And it's all the product of pkg-config and co. I didn't fiddle with stuff until I arrived at the whopping 38 long list.

At the end of the day, I got a working static build. So, I'm good.

@MoSal: just FYI, the error you saw occurred because -lcrypt32 must come after -lcrypto.

It's not really clear why removing -lbcrypt causes more libraries to be added to the link line, but maybe it's because some later configure test fails.

The list of libraries is really redundant: you mentioned 25 before the change, and 38 after the change, but in reality there are only 19 unique ones, and although it's theoretically possible to create situations where libraries must be included more than once, this is very rare in practice, so the link line could be simplified a lot if only the libraries were listed in the correct order.

@drakkan: The problem still persists for me after updating to version 8.8.0. I still recommend the CHOST patch as a workaround.

Note the line "checking whether we are cross compiling..." which is "no" for me, but "yes" for you (as it should). Check configure.log for the reason:

configure:5109: checking whether we are cross compiling
configure:5117: i686-w64-mingw32-gcc -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  -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS  -Wl,-O1,--sort-common,--as-needed -fstack-protector  conftest.c  >&5
configure:5121: $? = 0
configure:5128: ./conftest.exe
configure:5132: $? = 0
configure:5147: result: no

The issue exists only if Windows executables can be executed directly with e.g. ./conftest.exe (i.e., without calling wine explicitly!) I'm guessing this doesn't work inside chroots, so you get the correct result because conftest.exe fails.

@drakkan

The other part of patch 4 and the other patch are still needed.

Note that they are not the only changes needed. My build script currently has this:

  if [[ $pkg == "mingw-w64-libpsl" ]]; then
    sed -i 's|-meson |&--default-library=both |' PKGBUILD
  elif [[ $pkg == "mingw-w64-zstd" ]]; then
    sed -i 's|STATIC=OFF|STATIC=ON|' PKGBUILD
  elif [[ $pkg == "mingw-w64-curl" ]]; then
    sed -i -e "s|'mingw-w64-libssh2'||" -e 's|--with-libssh2||' PKGBUILD
  fi

Removing libssh2 may not be required. I just removed it first while debugging and didn't add it back because I don't need it.

@maksverver I build in a chroot but it is not clean, wine is installed and I cannot reproduce the reported issue.

pacman -Q | grep wine
mingw-w64-wine 1-9
wine 9.11-1

Please compare your configure output with mine

@MoSal, removed static build patches, they were very old, maybe they are not needed anymore

From 0004-more-static-fixes.patch:

diff -urN curl-7.84.0/configure.ac.orig curl-7.84.0/configure.ac
--- curl-7.84.0/configure.ac.orig   2022-06-30 18:13:08.954675200 +0200
+++ curl-7.84.0/configure.ac    2022-06-30 18:18:29.024823500 +0200
@@ -1914,7 +1914,7 @@

 dnl link required libraries for USE_WIN32_CRYPTO or USE_SCHANNEL
 if test "x$USE_WIN32_CRYPTO" = "x1" -o "x$USE_SCHANNEL" = "x1"; then
-  LIBS="-ladvapi32 -lcrypt32 $LIBS"
+  LIBS="-ladvapi32 -lcrypt32 -lbcrypt $LIBS"
 fi

 case "x$OPENSSL_ENABLED$GNUTLS_ENABLED$NSS_ENABLED$MBEDTLS_ENABLED$WOLFSSL_ENABLED$SCHANNEL_ENABLED$SECURETRANSPORT_ENABLED$BEARSSL_ENABLED$AMISSL_ENABLED$RUSTLS_ENABLED"

What is this supposed to fix? Because it breaks static builds for me (linking libcurl against other software). Removing that part of the patch fixes the build.

Building without libssh2, and starting with -lcurl, here is the broken vs. working param list (25 -ls vs 38 -ls)!

Broken

 '-lcurl',
 '-lnghttp2',
 '-lidn2',
 '-lpsl',
 '-lbcrypt',
 '-ladvapi32',
 '-lcrypt32',
 '-lbcrypt',
 '-lssl',
 '-lcrypto',
 '-lssl',
 '-lcrypto',
 '-lgdi32',
 '-lwldap32',
 '-lzstd',
 '-lzstd',
 '-lbrotlidec',
 '-lz',
 '-lws2_32',
 '-lidn2',
 '-liconv',
 '-lunistring',
 '-lbrotlidec',
 '-lbrotlicommon',
 '-lpthread',

Working

 '-lcurl',
 '-lnghttp2',
 '-lidn2',
 '-lpsl',
 '-lbcrypt',
 '-ladvapi32',
 '-lcrypt32',
 '-lssl',
 '-lcrypto',
 '-lgdi32',
 '-lwldap32',
 '-lzstd',
 '-lbrotlidec',
 '-lz',
 '-lws2_32',
 '-lnghttp2',
 '-lidn2',
 '-lpsl',
 '-lbcrypt',
 '-ladvapi32',
 '-lcrypt32',
 '-lssl',
 '-lcrypto',
 '-lssl',
 '-lcrypto',
 '-lgdi32',
 '-lwldap32',
 '-lzstd',
 '-lzstd',
 '-lbrotlidec',
 '-lz',
 '-lws2_32',
 '-lidn2',
 '-liconv',
 '-lunistring',
 '-lbrotlidec',
 '-lbrotlicommon',
 '-lpthread',

Error:

/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/x86_64-w64-mingw32/lib/libcrypto.a(libdefault-lib-winstore_store.obj):(.text+0xb7): undefined reference to `__imp_CertFindCertificateInStore'
/usr/lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/x86_64-w64-mingw32/lib/libcrypto.a(libdefault-lib-winstore_store.obj):(.text+0x5eb): undefined reference to `__imp_CertOpenSystemStoreW'
collect2: error: ld returned 1 exit status