“Symbole caché `atexit " est référencé par l'ASM” lors de l'utilisation de libtool avec gcov

J'ai un projet C++ qui utilise la GNU Autotools pour ses scripts de construction et de libtool pour la liaison. Récemment, j'ai ajouté de la couverture de code avec l'instrumentation gcov, en veillant à ce que

GCOV_CFLAGS="-fprofile-arcs -ftest-coverage"
GCOV_LDFLAGS="-fprofile-arcs -ftest-coverage"

..inclus dans mon CFLAGS et LDFLAGS respectivement. Sur OS X 10.7.4 à l'aide de g++-4.2 (installé par homebrew), tout fonctionne bien.

Sur Ubuntu 12.04 à l'aide de g++ 4.6.3, libtool ne parvient pas à lier une de mes tests:

/bin/bash ./libtool --tag=CXX   --mode=link g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -L/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib   -o myproj/inttests/locale_test myproj/inttests/locale_test.o myproj/app/libapp.la -lboost_thread-mt -lboost_system-mt -pthread -llog4cplus  
libtool: link: g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -Wl,-rpath -Wl,/usr/local/lib -o myproj/inttests/.libs/locale_test myproj/inttests/locale_test.o -pthread  -L/usr/local/lib myproj/app/.libs/libapp.so -lboost_thread-mt -lboost_system-mt /usr/lib/liblog4cplus.so -pthread
/usr/bin/ld: myproj/inttests/.libs/locale_test: hidden symbol `atexit' in /usr/lib/x86_64-linux-gnu/libc_nonshared.a(atexit.oS) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [myproj/inttests/locale_test] Error 1

Comment puis-je réparer mon build sur ubuntu/g++ 4.6?

InformationsquelleAutor phs | 2012-07-28
  1. 5

    Après googler autour de moi, je vois ce fil, ce qui suggère l'ajout de --coverage à CXXFLAGS lors de l'exécution de ./configure. En effet, même si cela n'a pas fonctionné pour cette affiche, ça fonctionne pour moi:

    ./configure CXXFLAGS="--coverage"

    Cependant, cette variable est réservé à l'installateur de paquets, pas le responsable (moi.) La question se réduit à "Comment puis-je intégrer dans la construire correctement?"

    Voici ce qui est pas assez:

    GCOV_CFLAGS="-fprofile-arcs -ftest-coverage --coverage"
GCOV_LDFLAGS="-fprofile-arcs -ftest-coverage"

    Sur l'hypothèse que GCOV_CFLAGS qui est inclus dans l'effectif CXXFLAGS (pas indiqué, mais il n'), il semble que ce correctif doit travailler. Il n'a pas.

    Creuser en outre, il semble qu'on devrait au moins avoir une certaine influence si nous laissons tomber CXXFLAGS="--coverage" à partir de la ligne de commande et au lieu de le placer dans configure.ac quelque part. Ceci, en fait, n'a pas de travail sauf la ligne est placée au-dessus de la AC_PROG_CXX appel qui sélectionne le compilateur.

    Alors maintenant, nous gagnons un peu de perspicacité. AC_PROG_CXX est en train de modifier quelque chose quand il voit --coverage, ce qui est très probablement pourquoi le placement dans GCOV_CFLAGS ne fonctionne pas: il était trop tard.

    Regardant attentivement dans les journaux, il semble que le secret de la sauce est l'inclusion automatique de -lgcov dans l'échec d'une étape de liaison. Je ne suis pas sûr que cette bibliothèque devait être un secret, mais si je change mes variables de la manière suivante:

    GCOV_CFLAGS="-fprofile-arcs -ftest-coverage --coverage"
GCOV_LDFLAGS="-fprofile-arcs -ftest-coverage"
GCOV_LIBS="-lgcov"

    ..et assurer GCOV_LIBS est inclus dans LIBS, puis tout ça fonctionne, sur tous mes plates-formes.

    MODIFIER: Voir aussi ce fil.

    • Avez-vous manuellement travail de ces GCOV* vars dans d'autres variables ou sont-ils inclus automatiquement? Si vous avez manuellement les placer dans d'autres, vous les placez dans?
    • En fait, il semble que la version actuelle de mes scripts de faire encore une troisième chose. Jetez un coup d'oeil à github.com/phs/sauce/blob/master/Makefile.am (voir la configure.ac pour GCOV_ENABLED)
    • Ce commentaire apporté à vous par le Ministère de la Redondance du Département. --coverage est l'équivalent de -fprofile-arcs -ftest-coverage lors de la compilation et -lgcov, tout en les reliant.
    InformationsquelleAutor phs
  2. 0

    En plus de façon générique, cette erreur peut être résolu en faisant en sorte que vos bibliothèques sont classées correctement sur votre ligne de commande de liaison.

    InformationsquelleAutor MonoThreaded