autoconf检测pthread函数的实际位置

我正在寻找一种方法来检测pthread函数真正存在的位置(libc、libpthread或两者兼有)。我的动机是GNU libc似乎正在将pthread函数从libpthread移动到libc。我需要截取这些函数,并确定在配置时截取哪个库。使受支持平台复杂化的是Linux glibc、Solaris、FreeBSD、macOS和Linux musl,重点是Linux glibc。

我认为AC\u CHECK\u LIB和AC\u SEARCH\u LIB并不合适,它们只会尝试编译一个包含函数并与库链接的小存根。由于libc在默认情况下是链接的,所以这不起作用。

到目前为止,我已经想出了这样的办法

  safe_CFLAGS=$CFLAGS
  CFLAGS="$CFLAGS -nodefaultlibs -lc"
  AC_MSG_CHECKING([if pthread_cond_destroy is in libc])
  AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[
      #include <pthread.h>
      (void)pthread_cond_destroy(0);
  ]])], [
  PTHREAD_IN_LIBC=1
  AC_MSG_RESULT([yes])
  ], [
  AC_MSG_RESULT([no])
  ])
  CFLAGS=$safe_CFLAGS

这对于检测函数是否在libc中似乎很有用(也许AC\u SEARCH\u LIBS可以更容易地做到这一点)。

但是为了检查libpthread,我得到

configure:16532: clang -o conftest  -nodefaultlibs -lpthread  
conftest.c  >&5 ld: error: undefined symbol: atexit
>>> referenced by crt1.c:63 (/usr/src/lib/csu/amd64/crt1.c:63)

(加上类似错误 _init_tls 和 exit )

计划B使用 nm 但这似乎 真正地 脆性-libs可能被剥离,我必须处理每个不同的路径/库名称。

更新:

我取得了一些进展。

ac_pthread_create_in_libc=yes
ac_pthread_cond_destroy_in_libc=yes
ac_sem_open_in_libc=yes

AC_SEARCH_LIBS([pthread_create], , , [ac_pthread_create_in_libc=no],)
AC_SEARCH_LIBS([pthread_cond_destroy], , , [ac_pthread_cond_destroy_in_libc=no],)
AC_SEARCH_LIBS([sem_open], , , [ac_sem_open_in_libc=no],)

ac_thread_fns_only_in_libc=no

if test x$ac_pthread_create_in_libc = xyes \
        -a x$ac_pthread_cond_destroy_in_libc = xyes \
        -a x$ac_sem_open_in_libc = xyes ; then
  ac_thread_fns_only_in_libc=yes
fi

ac_thread_fns_only_in_libpthread=no

if test x$ac_thread_fns_only_in_libc = xno ; then

  ac_pthread_create_in_libpthread=no
  ac_pthread_cond_destroy_in_libpthread=no
  ac_sem_open_in_libpthread=no
  
  if test x$ac_pthread_create_in_libc = xno ; then
    unset ac_cv_search_pthread_create
    safe_LIBS=$LIBS
    AC_SEARCH_LIBS([pthread_create], [pthread], [ac_pthread_create_in_libpthread=yes], ,)
    LIBS=$safe_LIBS
  fi

  if test x$ac_pthread_cond_destroy_in_libc = xno ; then
    unset ac_cv_search_pthread_cond_destroy
    AC_SEARCH_LIBS([pthread_cond_destroy], [pthread], [ac_pthread_cond_destroy_in_libc=yes], ,)
    LIBS=$safe_LIBS
  fi
    
  if test x$ac_sem_open_in_libc= xyes ; then
    unset ac_cv_search_sem_open
    AC_SEARCH_LIBS([sem_open], [pthread], [ac_sem_open_in_libc=yes], ,)
    LIBS=$safe_LIBS
  fi
  
  if test x$ac_pthread_create_in_libpthread = xyes \
          -a x$ac_pthread_cond_destroy_in_libpthread = xyes \
          -a x$ac_sem_open_in_libpthread = xyes ; then
    ac_thread_fns_only_in_libpthread=yes
  fi
fi

ac_thread_fns_in_libc_and_libpthread=no
if test x$ac_thread_fns_only_in_libc = xno -a \
        x$ac_thread_fns_only_in_libpthread = xno ; then
  ac_thread_fns_in_libc_and_libpthread=yes
fi

AC_MSG_NOTICE([libc $ac_thread_fns_only_in_libc pthread $ac_thread_fns_only_in_libpthread both $ac_thread_fns_in_libc_and_libpthread])

这似乎奏效了。生产准备就绪后,我会回答的。