Comment tester l'utilisabilité d'une bibliothèque C ++ dans configure.in?

Question

Je travaille sur un projet C ++ sous GNU / Linux et je cherche un moyen de tester l'existence et la convivialité de la bibliothèque d'IBM Informix avec les outils automatiques, à savoir la modification d'un configure.in . Comme je n'ai pas d'expérience avec Autotools, je tire donc essentiellement parti des scripts configure.in et autres du projet, ainsi que de la copie et de la modification de l'emplacement souhaité. modifié. IOW, je me suis adapté du texte existant dans configure.in .

Jusqu'à présent, j'utilise avec succès AC_CHECK_LIB dans configure.in pour vérifier si une bibliothèque donnée existe et est utilisable. Mais cela ne semble fonctionner qu'avec des bibliothèques avec des fonctions , pas par exemple. Des classes. Cela échoue notamment lors du test de la bibliothèque libifc ++. So d'Informix:

AC_CHECK_LIB(ifc++, ITString, 
        INFORMIX_LIB="-L$INFORMIX_LIB_LOCATION/c++ -lifc++ -L$INFORMIX_LIB_LOCATION -L$INFORMIX_LIB_LOCATION/dmi -L$INFORMIX_LIB_LOCATION/esql -lifdmi -lifsql -lifasf -lifgen -lifos -lifgls -lifglx $INFORMIX_LIB_LOCATION/esql/checkapi.o -lm -ldl -lcrypt -lnsl",
        echo "* WARNING: libifc++.so not found!"
        INFORMIX_INC=""
        INFORMIX_LIB=""
)

J'ai également essayé d'utiliser d'autres combinaisons, telles que ITString :: ITString , etc.

Je n'ai pas trouvé de "pur". fonction dans l’API d’Informix (c’est-à-dire qui n’est pas mis en contexte dans une classe C ++). J'espère donc qu'il est possible d'utiliser AC_CHECK_LIB dans ce contexte ou qu'il existe un autre autoconf / configure.in " commande " pour cette utilisation spécifique.

Merci d'avance pour vos commentaires.

Answer 1

Il existe peut-être une méthode plus simple pour y parvenir, mais je pense que votre problème est que les méthodes C ++ sont "mutilées". pour permettre à des informations supplémentaires sur la méthode (argument & types de retour, etc.) d'être codées. Par exemple; la méthode int A :: foo (void) sera modifiée en quelque chose comme __ ZN1A3fooEv .

Vous devez donc trouver le nom mutilé d’une méthode dans la bibliothèque. Vous pouvez le faire en utilisant la commande nm sur Systèmes d'exploitation de type Unix:

$ nm libifc++.so | grep ITString

Il convient de mentionner que le format de modification exact varie selon les compilateurs. et ainsi, en incorporant le symbole mutilé d’un certain compilateur dans votre configure.in , il se peut que cela ne fonctionne pas sur d’autres plateformes - YMMV.

Remarque: vous pouvez utiliser c ++ filt pour démêler un nom en son format lisible par l’homme; donc pour l'exemple que j'ai donné précédemment:

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

Voir Nom Mangling en C ++ sur Wikipedia pour plus d'informations.

Answer 2

Vous avez découvert une lacune dans les autotools, mais on ne peut vraiment pas y remédier. Autotools recherche les noms de symbole dans le fichier binaire de la bibliothèque et, contrairement à C où les noms de symbole des fonctions sont identiques aux noms de fonction, C ++ "mangles". les noms de symboles de fonctions pour accomplir des tâches telles que la surcharge de fonctions. Ce qui est pire, c'est que C ++ n'a même pas vraiment de "standard". convention de modification, si différents compilateurs C ++ peuvent produire différents noms de symbole pour la même fonction Ainsi, les outils automatiques ne peuvent pas vérifier les noms de symbole C ++ de manière fiable.

La bibliothèque que vous essayez d'utiliser possède-t-elle des fonctions déclarées avec extern " C "? Ainsi, le compilateur C ++ génère des noms de symbole normalisés de style C et les outils automatiques pourront les trouver.

J'ai rencontré ce problème en essayant de détecter gtest et gmock (les frameworks de test unitaire et de moquage d'objets de Google) avec Autotools, et voici ce que j'ai proposé:

# 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          

Answer 3

Si la bibliothèque que vous recherchez supporte le pkg-config , cela devient très facile. . Voici tout ce que j'ai ajouté à mon configure.in pour vérifier et activer gtest et 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)

Et puis dans mon Makefile.am quelque part:

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

Assez trivial, hein?

Answer 4

AC_LANG_CPLUSPLUS
AC_CHECK_LIB(Sockets, main)

Avertissement: http://lists.gnu.org /archive/html/autoconf/2006-09/msg00019.html