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.

It appears that MSYS2 provides libwinpthread-1.dll, with many packages depending on it:
https://packages.msys2.org/packages/mingw-w64-x86_64-libwinpthread-git

However, I intentionally avoided using it in our repository to prevent shipping libwinpthread-1.dll to end users, especially since all our dependencies support native Win32 thread/mutex implementations.

For full transparency, SQLite also needed this patch:

--- a/main.mk
+++ b/main.mk
@@ -1438,8 +1438,9 @@ all: so
 # unnecessary unless we want to set SONAME to libsqlite3.so.3, which
 # is also unnecessary.
 #
-# N.B. different transformations are applied on systems where $(T.dll)
-# is ".dylib" and none of the following docs apply on such systems.
+# N.B. this is skipped entirely where $(T.dll) is ".dll" or different
+# transformations are applied on systems where $(T.dll) is ".dylib"
+# and none of the following docs apply on such systems.
 #
 # The link named libsqlite3.so.0 is provided in an attempt to reduce
 # downstream disruption when performing upgrades from pre-3.48 to a
@@ -1482,7 +1483,9 @@ install-so-1: $(install-dir.lib) $(libsqlite3.SO)
 	fi
 	@echo "Setting up $(libsqlite3.SO) version symlinks..."; \
 	cd "$(install-dir.lib)" || exit $$?; \
-	if [ x.dylib = x$(T.dll) ]; then \
+	if [ x.dll = x$(T.dll) ]; then \
+		echo "... none needed"; \
+	elif [ x.dylib = x$(T.dll) ]; then \
 		rm -f libsqlite3.0$(T.dll) libsqlite3.$(PACKAGE_VERSION)$(T.dll) || exit $$?; \
 		dllname=libsqlite3.$(PACKAGE_VERSION)$(T.dll); \
 		mv $(libsqlite3.SO) $$dllname || exit $$?; \

See e.g. commit https://github.com/libvips/build-win64-mxe/commit/098b4c91a0815f3a4ea1b7f00db58ef04822d918 for reference.

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!