[CMake] Problems resolving PTHREAD_* symbols.

[Robert Maynard]

To get information on why a try_compile is failing you can use the
--debug-trycompile option which will stop CMake from deleting the
try_compile build tree code. Now this flag is only useful on a single
try_compile at a time.

On Tue, Sep 23, 2014 at 10:50 AM, Rick McGuire <object.rexx at gmail.com> wrote:
> This is still driving us crazy.  Digging a little deeper into this, the
> symbols we need are defined as enums on Linux, which explains why
> check_symbol_exists() does not work there.  The OSX pthread.h header uses
> defines, but for some reason, the check_c_source_compiles method is still
> failing.  We've updated our script to use
>
> check_c_source_compiles("#include <pthread.h>
>                          int main(int arg, char **argv) {
>                          int tryme;
>                          tryme = PTHREAD_MUTEX_ERRORCHECK;
>                          return 0;}"
>                         HAVE_PTHREAD_MUTEX_ERRORCHECK)
> if (NOT DEFINED HAVE_PTHREAD_MUTEX_ERRORCHECK)
>    check_symbol_exists(PTHREAD_MUTEX_ERRORCHECK "pthread.h"
> HAVE_PTHREAD_MUTEX_ERRORCHECK)
> endif ()
>
>
> to try both methods, but this is still failing on the Mac and a couple of
> the Linux versions we build for.
>
>
> This is driving us nuts, since we don't understand why the
> check_c_source_compiler check is not working.  Is there some way we can get
> debug information about why the compile fails?  That might give us some
> clues.
>
>
> Rick
>
>
> On Mon, Sep 22, 2014 at 12:06 PM, Rick McGuire <object.rexx at gmail.com>
> wrote:
>>
>> We have some semaphore code that has conditional compilation based on
>> #defines in config.h.  We're having problems with resolving the various
>> PTHREAD_* symbols to get the correct values in config.h.  Our first attempt
>> at this (done on Linux) used
>>
>> check_symbol_exists(PTHREAD_MUTEX_RECURSIVE "pthread.h"
>> HAVE_PTHREAD_MUTEX_RECURSIVE)
>>
>>
>> This did not pick the symbol up correctly.  Eventually, we got things to
>> work by using
>>
>>
>> check_c_source_compiles("#include <pthread.h>
>>                          int main(int arg, char **argv) {
>>                          int tryme;
>>                          tryme = PTHREAD_MUTEX_RECURSIVE;
>>                          return 0;}"
>>                         HAVE_PTHREAD_MUTEX_RECURSIVE)
>>
>> and got everything to build cleanly.  Over the weekend, we tried building
>> on OSX for the first time, and once again, we were not resolving that these
>> symbols existed.  What are we missing here?  Is there some technique we
>> should be using that will work across the various platforms?
>>
>>
>> Rick
>>
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake