GCC also needs find_package(Threads)

[roastduck]

The current CMakeLists.txt only call find_package(Threads) for clang, but I found gcc also needs it, tested in Ubuntu 15.10, with gcc version 5.2.1. I found this PR claims MSVC needs it but it was deleted later. And this PR claims WIN32 needs it but has not been merged. However, They also claim gcc do not need this call. So when should we use find_package(Threads) after all?

[roastduck]

Why can't we call find_package(Threads) for all platform?

[jasonyu1996]

I had exactly the same problem encountered, and have solved it with the PR given applied. Tested with gcc 5.3.0 on 4.4.5-1 Arch.

[kinnefix]

A temporary solution I found : the cmake command "find_package(Threads)" should be called no matter clang is detected.
What I did is that I simpy added command "find_package(Threads)" right after it finishes checking for clang. To conclude, my portion of CMakeLists.txt looks as below

Detect clang

if(CMAKE_CXX_COMPILER MATCHES ".*clang")
set(CMAKE_COMPILER_IS_CLANGXX 1)

call find_package for Threads. Without this, you will get this error:

set_target_properties Can not find target to add properties to: Threads::Threads

find_package(Threads)
endif()
find_package(Threads)
add_definitions( -DLIQUIDFUN_EXTERNAL_LANGUAGE_API=1 )

Hope this helps.
By the way, this is the first time I comment on github... and I don't even speak English. But I really wanted to participate in improving projects on github. :)

[roastduck]

That's what I meant and it works on my platform. But the pull requests mentioned above claimed that gcc doesn't need it, why?

PS: When posting on github, you should add indents on the code part so that markdown can display it as code.