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.r...@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.r...@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 -- 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