Ensure HAVE_PTHREAD_INIT is set similarly with Autoconf and CMake on MacOSX
Ensure HAVE_PTHREAD_INIT is set similarly with Autoconf and CMake on MacOSX

This is done by setting HAVE_PTHREAD_INIT with the value
of CMAKE_USE_PTHREADS_INIT. Being itself set by FindThreads module which
checks for the presence of the "pthread_create" symbol.

Before this commit, the macro "check_symbol_exists" was used to check for
the "availability" of the "pthread_init" symbol. The macro was returning
false on both system as expected. Indeed, both system follows the UNIX
specification standard, the "pthread_init" function isn't part of
the documented API. See [1] and [2]

[1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread.h.htmlhttps://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.html
[2] https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/pthread.3.html

While the CMake macro was working as expected, the autoconf one is not as
robust and is returning true on MacOSX while false is expected.

Let's try to understand why by looking at the program generated by
both system:

* CMake

 The following code:

   check_symbol_exists(pthread_init "${CFG_HEADERS}" HAVE_PTHREAD_INIT)

 expands to:

   [...]
   #include <pthread.h>
   [...]

   int main(int argc, char* argv[])
   {
   return ((int*)(&pthread_init))[argc];
   }



* Autoconf:


  The following code:

    AC_CHECK_FUNC(pthread_init)

  expands to:

    /* confdefs.h */
    // [...]
    #define HAVE_PTHREAD_H
    // [...]
    /* end confdefs.h.  */

    // [...] Some HP-UX11i related stuff

    /* Override any GCC internal prototype to avoid an error.
       Use char because int might match the return type of a GCC
       builtin and then its argument prototype would still apply.  */
    #ifdef __cplusplus
    extern "C"
    #endif
    char pthread_init ();

    // [...] The GNU C library alias function test.

    int
    main (int argc, char * argv[])
    {
     return pthread_init ();
      ;
      return 0;
    }



In case of the CMake, the test checks that the function is publicly available
and linkable whereas the Autoconf one only verify that it is possible to
resolve the corresponding symbol.


Manually introspecting the system library, I found that

  (1) on MacOSX the libSystemB.dylib has a symbol named "_pthread_init"

  (2) on Linux, the libc exposes has the symbol "__libc_pthread_init".

This can be verified easily using nm.

  nm /usr/lib/libSystemB.dylib | grep pthread_init

                   U __pthread_init


  nm /usr/lib/libpthread.a | grep pthread_init

                   U __libc_pthread_init
                   U __pthread_init_static_tls
  0000000000000000 T __pthread_initialize_minimal
  0000000000000000 T __pthread_initialize_minimal_internal
  00000000000009f0 T __pthread_init_static_tls


Checking the associated source code [3][4] also confirm this.

[3] http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthreadP.h;h=d08b219b5db12f2b51a8579fe7112e1dd18149e9;hb=HEAD#l370
[4] http://www.opensource.apple.com/source/Libc/Libc-825.25/pthreads/pthread.c


This explains why the Autconf test was passing whereas the CMake test was
failing as expected.


As a side note, to be able to obtain the generate code for the autoconf
system, I added the following three line to the "ac_fn_c_check_func"
function in the "configure" script itself.

  echo "=================== " >> check_func.log
  echo "conftest.$ac_ext is " >> check_func.log
  cat conftest.$ac_ext >> check_func.log
  echo "=================== " >> check_func.log


Source: http://stackoverflow.com/questions/7207525/autotools-temporary-files


While investigating the issue, I also found an interesting reading about
symbol interposition:

See  http://stackoverflow.com/questions/11161462/why-glibc-and-pthread-library-both-defined-same-apis

thewtex/python-cmake-buildsystem,adrianbroher/python-cmake-buildsystem,chuckatkins/python-cmake-buildsystem,msmolens/python-cmake-buildsystem,thewtex/python-cmake-buildsystem,davidsansome/python-cmake-buildsystem,python-cmake-buildsystem/python-cmake-buildsystem,jcfr/python-cmake-buildsystem