See attached patch.

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Kleis Auke Wolthuizen <github@kleisauke.nl>
Date: Fri, 14 Feb 2025 17:20:40 +0100
Subject: [PATCH 1/1] configure: make pthread bits optional

Specifically Windows does not need require this.

Regressed since the migration of the build system to autosetup.

diff --git a/autosetup/sqlite-config.tcl b/autosetup/sqlite-config.tcl
index 1111111..2222222 100644
--- a/autosetup/sqlite-config.tcl
+++ b/autosetup/sqlite-config.tcl
@@ -383,7 +383,7 @@ proc sqlite-handle-soname {} {
 }
 
 ########################################################################
-# If --enable-thresafe is set, this adds -DSQLITE_THREADSAFE=1 to
+# If --enable-threadsafe is set, this adds -DSQLITE_THREADSAFE=1 to
 # OPT_FEATURE_FLAGS and sets LDFLAGS_PTHREAD to the linker flags
 # needed for linking pthread. If --enable-threadsafe is not set, adds
 # -DSQLITE_THREADSAFE=0 to OPT_FEATURE_FLAGS and sets LDFLAGS_PTHREAD
@@ -393,14 +393,15 @@ proc sqlite-handle-threadsafe {} {
   proj-if-opt-truthy threadsafe {
     msg-result yes
     sqlite-add-feature-flag -DSQLITE_THREADSAFE=1
-    if {![proj-check-function-in-lib pthread_create pthread]
-        || ![proj-check-function-in-lib pthread_mutexattr_init pthread]} {
-      user-error "Missing required pthread bits"
+    proj-check-function-in-lib pthread_mutexattr_init pthread
+    if {[proj-check-function-in-lib pthread_create pthread]} {
+      define LDFLAGS_PTHREAD [get-define lib_pthread_create]
+      undefine lib_pthread_create
+      # Recall that LDFLAGS_PTHREAD might be empty even if pthreads if
+      # found because it's in -lc on some platforms.
+    } else {
+      define LDFLAGS_PTHREAD ""
     }
-    define LDFLAGS_PTHREAD [get-define lib_pthread_create]
-    undefine lib_pthread_create
-    # Recall that LDFLAGS_PTHREAD might be empty even if pthreads if
-    # found because it's in -lc on some platforms.
   } {
     msg-result no
     sqlite-add-feature-flag -DSQLITE_THREADSAFE=0

make pthread bits optional

An equivalent patch was just applied to trunk and the 3.49 branch. Summary: failure to find pthreads is only fatal if --enable-threadsafe is specifically passed in.

(Ah, there's a missing "yes" in that output in one case but that'll be fixed soon.)

Thank you for the report!

Thanks for the quick response and patch.

However, I don't think that patch is entirely correct for Win32. The SQLITE_THREADSAFE feature flag shouldn't be disabled if pthreads is unavailable, as Windows can use _beginthreadex() and _endthreadex() instead (see the SQLITE_OS_WIN_THREADS definition for reference).

However, I don't think that patch is entirely correct for Win32. The SQLITE_THREADSAFE feature flag shouldn't be disabled if pthreads is unavailable, as Windows can use _beginthreadex() and _endthreadex() instead (see the SQLITE_OS_WIN_THREADS definition for reference).

Fair point. We don't officially support non-native Windows builds and the native Windows builds don't use the configure script, but i will tinker with this on msys2 over the weekend.

but i will tinker with this on msys2 over the weekend.

@Kleis it turns out that this patch coincidentally works as-is on msys2 and cygwin. Both give me the same results:

$ ./configure --all
...
Support threadsafe operation? Checking for libs...
Checking libs for pthread_create...none needed
Checking libs for pthread_mutexattr_init...none needed
...
Library feature flags: ...<snip>... -DSQLITE_THREADSAFE=1

Tested environments:

$ uname -a
MSYS_NT-10.0-26100 hplite 3.5.4-0bc1222b.x86_64 2024-12-05 09:27 UTC x86_64 Msys

$ uname -a
CYGWIN_NT-10.0-26100 hplite 3.5.7-1.x86_64 2025-01-29 19:46 UTC x86_64 Cygwin

Did you have another environment in mind where pthreads is not available but _beginthreadex() and friends are?

The native/MSVC builds don't use the configure script, so will use whatever options are defined in Makefile.msc.

This is for https://github.com/libvips/build-win64-mxe, which uses https://github.com/mxe/mxe as its base environment but swaps GCC and binutils with Clang and other LLVM-based tools.

We admittedly don't put much effort into supporting cross-compilation because we don't have the collective bandwidth to test and support even a small subset of the potential platform combinations. Our stance is that "custom builds require custom solutions," and the amalgamation source distribution makes it trivial to build the library however a given user might need.

+ if [ x.dll = x$(T.dll) ]; then

After looking more closely at msys2 and cygwin, that is apparently the preferred approach for those, so the install rules/docs will be patched for that today.

Thank you!