[clang64] [SoX] undefined pthread symbols referenced by FLAC

[L4cache]

Mingw64 environment don't have this problem.
If I add -lpthread to flac.pc Libs.private then the problem is seemingly solved.

  CCLD     sox.exe
ld.lld: error: undefined symbol: pthread_mutex_lock
>>> referenced by libFLAC.a(stream_encoder.c.o):(FLAC__stream_encoder_finish)
>>> referenced by libFLAC.a(stream_encoder.c.o):(FLAC__stream_encoder_finish)
>>> referenced by libFLAC.a(stream_encoder.c.o):(FLAC__stream_encoder_finish)
>>> referenced 14 more times

ld.lld: error: undefined symbol: pthread_cond_broadcast
>>> referenced by libFLAC.a(stream_encoder.c.o):(FLAC__stream_encoder_finish)
>>> referenced by libFLAC.a(stream_encoder.c.o):(FLAC__stream_encoder_finish)

logs.zip.txt
(I don't know why github won't let me upload zip files...)

[L4cache]

This is probably "introduced" by the migration from autotools to cmake.
But other things that link against FLAC don't seem to have this problem, such as opusenc.

[1480c1]

51a5995

[1480c1]

Possibly the other projects have something else that links pthread for flac, that's my current guess

[L4cache]

Possibly the other projects have something else that links pthread for flac, that's my current guess

That can explain why other tools built successfully in this case, but can't explain the bigger mistery:
Autotools-built flac don't have -lpthread in flac.pc too and in the same environment I tested and same SoX code would successfully built.
And the difference (successful or not) between mingw64 and clang64 is also... mind-blowing?

[1480c1]

mingw-w64 gcc implicitly always links pthreads due to needing pthread for some base libraries or something like that

[L4cache]

Wow thanks, that's one more mystery solved.
(shame for my lack of knowledge)