Как проверить удобство использования библиотеки C++ в configure.in?

Может быть более чистый способ добиться этого, но я думаю, что ваша проблема заключается в том, что методы С++ «искажаются», чтобы можно было закодировать дополнительную информацию о методе (типы аргументов и возвращаемых значений и т. д.). Например; метод int A::foo(void) превратится во что-то вроде __ZN1A3fooEv.

Итак, вам нужно найти искаженное имя метода в библиотеке. Это можно сделать с помощью nmкоманды в Unix-подобных ОС:

$ nm libifc++.so | grep ITString

Стоит отметить, что точный формат искажения зависит от разных компиляторов; и поэтому, встраивая определенный искаженный символ компилятора в ваш configure.in, он может не работать на других платформах - YMMV.

Примечание: вы можете использовать c++filt утилита для преобразования имени в удобочитаемую форму; поэтому для примера, который я привел ранее:

$ c++filt __ZN1A3fooEv
A::foo()

Дополнительную информацию см. в разделе Изменение имен в C++ в Википедии.

Вы обнаружили недостаток автоинструментов, но с этим ничего не поделаешь. Autotools проверяет имена символов в двоичном файле библиотеки, и в отличие от C, где имена символов функций идентичны именам функций, C++ «искажает» имена символов функций для выполнения таких задач, как перегрузка функций. Что еще хуже, так это то, что C++ на самом деле даже не имеет «стандартного» соглашения об изменении, поэтому разные компиляторы C++ могут создавать разные имена символов для одной и той же функции. Таким образом, автоинструменты не могут надежно проверять имена символов C++.

Есть ли в библиотеке, которую вы пытаетесь использовать, какие-либо функции, объявленные с помощью extern "C"? Это заставляет компилятор C++ генерировать стандартизированные имена символов в стиле C, и автоинструменты смогут их найти.

Я столкнулся с этой проблемой, пытаясь обнаружить gtest и gmock (фреймворки Google для модульного тестирования и имитации объектов) с Autotools, и вот что у меня получилось:

# gtest has a main function in the gtest_main library with C linkage, we can test for that.
AC_CHECK_LIB([gtest_main], [main], [HAVE_GTEST=1] [TEST_LIBS="$TEST_LIBS -lgtest_main"], 
      AC_MSG_WARN([libgtest (Google C++ Unit Testing Framework) is not installed. Will not be able to make check.])) 

# gmock has no functions with C linkage, so this is a roundabout way of testing for it. We create a small test
# program that tries to instantiate one of gmock's objects, and try to link it with -lgmock and see if it works.
if test "$HAVE_GTEST"                                                                 
then                                                                                  
  saved_ldflags="${LDFLAGS}"                                                          
  LDFLAGS="${LDFLAGS} -lgtest -lgmock"                                                
  AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <gmock/gmock.h>], [testing::Cardinality dummy])],
    [TEST_LIBS="$TEST_LIBS -lgmock"] [HAVE_GMOCK=1],                                           
    [AC_MSG_WARN([libgmock (Google C++ Object Mocking Framework) is not installed. Will not be able to make check.])])
  LDFLAGS="${saved_ldflags}"                                                                                          
fi          

Если библиотека, которую вы проверяете, поддерживает pkg-config, сделать это очень просто. Вот все, что я добавил в свой configure.in, чтобы проверить и включить gtest и gmock:

dnl ************************************
dnl Check for googletest and googlemock
dnl ************************************

PKG_CHECK_MODULES(gtestmock, libgtest >= 0.4.0, libgmock >= 0.4.0)
AC_SUBST(gtestmock_LIBS)
AC_SUBST(gtestmock_CFLAGS)

А потом где-то в моем Makefile.am:

sometarget_CXXFLAGS = $(gtestmock_CFLAGS) $(AM_CXXFLAGS)
sometarget_LDADD    = $(gtestmock_LIBS)

Довольно банально, а?

AC_LANG_CPLUSPLUS
AC_CHECK_LIB(Sockets, main)

Предостережение: http://lists.gnu.org/archive/html/autoconf/2006-09/msg00019.html