Arch Linux User Repository

@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

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.