"-pthreads" is a compiler and linker flag. On some platforms it enables various macros in C/C++ headers. It is the "I am using threads" command line switch.

As such, a poor test can silently fail (== appear to not need -pthread), resulting in code that is compiled as single-threaded code.

Silently compiling to single-threaded code is a far worse outcome than an annoying warning on compiler+platform combinations where -pthread is superfluous.

@jgarzik "-pthread" is a compiler and linker flag: no. This only applies to good old GNU gcc and GNU linker world only (compare pthreads(7) on GNU/Linux: On Linux, programs that use the Pthreads API should be compiled using cc -pthread.). But it is a bit different on OS X. You don't need any compiler/linker flags because all system libs contain threads support. See https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/pthread.3.html#//apple_ref/doc/man/3/pthread for more details - especially the section INSTALLATION: "The default system libraries include pthread functions. No additional libraries or CFLAGS are necessary to use these interfaces."
"Silent compilation as single thread" is thus not possible on OS X and this PR is Darwin/OS X only anyway.

@paveljanik I am well aware of that. My comment remains applicable. You must consider the case of building with gcc + third party libraries on OSX that trigger different thread/non-thread behavior at compile time.

The entire app stack on OSX needs to be verified free of MT behavior switching in headers, not just the system libs. e.g. Boost in particular is very sensitive on OSX, and is header-heavy.

But this is "solved" in ax_pthread.m4 already IMO, where it checks thread functionality (not completely though, of course) with the provided compiler/libs and auto-selects the needed flags.
When I think more about it, ax_pthread.m4 macros should be changed to distinguish between compile time and linking time. Of course written for GNU world, where compile and link time are the same...

On OS X:

Pavels-MacBook-Pro:tmp pavel$ gcc -pthread conftest.c

but:

Pavels-MacBook-Pro:tmp pavel$ gcc -pthread -o conftest.o -c conftest.c
Pavels-MacBook-Pro:tmp pavel$ gcc -pthread conftest.o
clang: warning: argument unused during compilation: '-pthread'
Pavels-MacBook-Pro:tmp pavel$ 

Ie. when clang is used to compile&link, it doesn't emit warning. Compile alone is OK but link alone emits warning.
I think this doesn't have a solution right now and I should close this PR and report the problem to ax_pthread.m4 authors. Other opinions?

diff --git a/src/Makefile.am b/src/Makefile.am
index d6ac6e1..d7968bd 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,5 +1,6 @@
 DIST_SUBDIRS = secp256k1
-AM_LDFLAGS = $(PTHREAD_CFLAGS) $(LIBTOOL_LDFLAGS)
+AM_LDFLAGS = $(PTHREAD_LIBS) $(LIBTOOL_LDFLAGS)
+AM_CFLAGS = $(PTHREAD_CFLAGS)


 if EMBEDDED_LEVELDB

Isn't that all that needs to be done? The m4 macro already does all kinds of checking for us, we just weren't using the output correctly. Clang is perfectly happy to eat "-pthreads" for compile, it just doesn't like it in the link-line.

@theuni yes, this is all to be done. Thank you! Will you PR it or should I use it here?

+1 @theuni

@paveljanik You're welcome to just take that here, to keep the discussion in one place.

Done. Thank you again.

Travis failed: https://travis-ci.org/bitcoin/bitcoin/jobs/44878072 on ARM.

Looks like -pthread is missing when linking or something similar... But can't test easily. Adding debugging prints to configure.

Yup, confirmed:

configure: The contents of configured PTHREAD_CFLAGS: -pthread
configure: The contents of configured PTHREAD_LIBS: 
configure: The contents of configured PTHREAD_CC: arm-linux-gnueabihf-gcc

@theuni Any hint now?

Other platforms are OK. On all of them, _LIBS is empty, e.g.:

configure: The contents of configured PTHREAD_CFLAGS: -pthread
configure: The contents of configured PTHREAD_LIBS: 
configure: The contents of configured PTHREAD_CC: gcc -m64

Well that's annoying. I had assumed that the m4 would treat LIBS as LDFLAGS, sticking linker options (-pthread) in LIBS as needed. But upon closer inspection, it doesn't even try to compile without linking! It just assumes you'll forward CFLAGS to the linker, which explains why I had it setup that way to begin with.

After trying a few things and checking deep in some docs, I now agree with @jgarzik. Your original suggestion was probably the correct thing to do, but it's just not worth doing for us. I'd rather leave a harmless warning around than risk trouble in the future.

See https://savannah.gnu.org/patch/index.php?8585 for a bugreport to GNU Autoconf Archive.

Is paveljanik@e7f114c worth cherrypicking so we have auto-detected values saved in the Travis logs/configure log?

Otherwise we can't do more here. Thank you all. Closing.

JFYI: ax_pthreads.m4 is getting fixed upstream:

https://savannah.gnu.org/patch/?8585