libpthread.so.0: erreur lors de l'ajout de symboles: DSO manquant à partir de la ligne de commande
Lorsque je compile openvswitch-1.5.0, j'ai rencontré l'erreur de compilation suivante:
gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith
-Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init -g -O2 -export-dynamic ***-lpthread*** -o utilities/ovs-dpctl utilities/ovs-dpctl.o lib/libopenvswitch.a
/home/jyyoo/src/dpdk/build/lib/librte_eal.a
/home/jyyoo/src/dpdk/build/lib/libethdev.a
/home/jyyoo/src/dpdk/build/lib/librte_cmdline.a
/home/jyyoo/src/dpdk/build/lib/librte_hash.a
/home/jyyoo/src/dpdk/build/lib/librte_lpm.a
/home/jyyoo/src/dpdk/build/lib/librte_mbuf.a
/home/jyyoo/src/dpdk/build/lib/librte_ring.a
/home/jyyoo/src/dpdk/build/lib/librte_mempool.a
/home/jyyoo/src/dpdk/build/lib/librte_malloc.a -lrt -lm
/usr/bin/ld: /home/jyyoo/src/dpdk/build/lib/librte_eal.a(eal.o): undefined reference
to symbol 'pthread_create@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from
command line
Si j'essaie de voir les symboles de libpthread, tout va bien.
$ readelf -s /lib/x86_64-linux-gnu/libpthread.so.0 | grep pthread_create
199: 0000000000008220 2814 FUNC GLOBAL DEFAULT 13 pthread_create@@GLIBC_2.2.5
173: 0000000000008220 2814 FUNC LOCAL DEFAULT 13 __pthread_create_2_1
462: 0000000000008220 2814 FUNC GLOBAL DEFAULT 13 pthread_create@@GLIBC_2.2
Pourriez-vous donner des conseils ou des pointeurs?
Vous devriez mentionner la bibliothèque sur la ligne de commande after les fichiers objet compilés:
gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init \
-g -O2 -export-dynamic -o utilities/ovs-dpctl utilities/ovs-dpctl.o \
lib/libopenvswitch.a \
/home/jyyoo/src/dpdk/build/lib/librte_eal.a /home/jyyoo/src/dpdk/build/lib/libethdev.a /home/jyyoo/src/dpdk/build/lib/librte_cmdline.a /home/jyyoo/src/dpdk/build/lib/librte_hash.a /home/jyyoo/src/dpdk/build/lib/librte_lpm.a /home/jyyoo/src/dpdk/build/lib/librte_mbuf.a /home/jyyoo/src/dpdk/build/lib/librte_ring.a /home/jyyoo/src/dpdk/build/lib/librte_mempool.a /home/jyyoo/src/dpdk/build/lib/librte_malloc.a \
-lrt -lm -lpthread
Explication: la liaison dépend de l'ordre des modules. Les symboles sont d'abord demandés, puis liés à partir d'une bibliothèque les contenant. Vous devez donc spécifier les modules qui utilisent d’abord les bibliothèques, et ensuite les bibliothèques. Comme ça:
gcc x.o y.o z.o -la -lb -lc
De plus, en cas de dépendance circulaire, vous devez spécifier plusieurs fois la même bibliothèque sur la ligne de commande. Ainsi, dans le cas où libb a besoin du symbole de libc et libc d'un symbole de libb, la ligne de commande doit être:
gcc x.o y.o z.o -la -lb -lc -lb
Le message d'erreur dépend de la version de la distribution/du compilateur:
Ubuntu Saucy:
/usr/bin/ld: /mnt/root/ffmpeg-2.1.1//libavformat/libavformat.a(http.o): undefined reference to symbol 'inflateInit2_'
/lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing from command line
Ubuntu Raring: (plus informatif)
/usr/bin/ld: note: 'uncompress' is defined in DSO /lib/x86_64-linux-gnu/libz.so.1 so try adding it to the linker command line
Solution: Il vous manque peut-être une bibliothèque dans vos étapes de compilation, au cours de la phase de liaison. Dans mon cas, j'ai ajouté '-lz' aux drapeaux makefile/GCC.
Background: DSO est un objet partagé dynamique ou une bibliothèque partagée.
J'ai trouvé un autre cas et donc je pense que vous avez tous tort.
Voici ce que j'ai eu:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: eggtrayicon.o: undefined reference to symbol 'XFlush'
/usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
Le problème est que la ligne de commande DID NE contient PAS -lX11 - bien que libX11.so doive être ajouté en tant que dépendance car il y avait également des bibliothèques GTK et GNOME dans les arguments.
Donc, la seule explication pour moi est que ce message a peut-être été conçu pour vous aider, mais il ne l’a pas fait correctement. C'était probablement simple: la bibliothèque qui fournit le symbole n'a pas été ajoutée à la ligne de commande.
Veuillez noter trois règles importantes concernant les liaisons dans POSIX:
- Les bibliothèques dynamiques ont des dépendances définies. Par conséquent, seules les bibliothèques de la dépendance du haut doivent être fournies dans l'ordre de votre choix (bien qu'après les bibliothèques statiques).
- Les bibliothèques statiques ont juste des symboles indéfinis - c'est à vous de connaître leurs dépendances et de les fournir toutes en ligne de commande
- L'ordre dans les bibliothèques statiques est toujours: le demandeur en premier, le fournisseur suit. Sinon, vous obtiendrez un message de symbole non défini, comme lorsque vous avez oublié d'ajouter la bibliothèque à la ligne de commande.
- Lorsque vous spécifiez la bibliothèque avec
-l<name>, vous ne savez jamais si cela prendralib<name>.sooulib<name>.a. La bibliothèque dynamique est préférable, si elle est trouvée, et seules les bibliothèques statiques peuvent être appliquées par l'option du compilateur - c'est tout. Et si vous avez des problèmes comme ci-dessus, cela dépend si vous avez des bibliothèques statiques ou dynamiques - Eh bien, il arrive que les dépendances fassent défaut dans les bibliothèques dynamiques: D
J'ai trouvé que j'avais la même erreur. Je compilais un code avec lapack et blas. Lorsque j'ai changé l'ordre dans lequel les deux bibliothèques ont été appelées, l'erreur est partie.
"LAPACK_LIB = -llapack -lblas" a fonctionné là où "LAPACK_LIB = -lblas -llapack" a généré l'erreur décrite ci-dessus.
J'ai aussi rencontré le même problème. Je ne sais pas pourquoi, je viens d’ajouter l’option -lpthread au compilateur et tout va bien.
Vieux:
$ g++ -rdynamic -m64 -fPIE -pie -o /tmp/node/out/Release/mksnapshot ...*.o *.a -ldl -lrt
a obtenu l'erreur suivante. Si j’ajoute l’option -lpthread à la commande ci-dessus, alors OK.
/usr/bin/ld: /tmp/node/out/Release/obj.Host/v8_libbase/deps/v8/src/base/platform/condition-variable.o: undefined reference to symbol 'pthread_condattr_setclock@@GLIBC_2.3.3'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Contexte
Le message DSO missing from command line sera affiché lorsque l'éditeur de liens ne trouvera pas le symbole requis avec sa recherche normale mais que le symbole est disponible dans l'une des dépendances d'une bibliothèque dynamique spécifiée directement.
Dans le passé, l'éditeur de liens considérait que les symboles dépendant de langues spécifiées étaient disponibles. Mais cela a changé dans une version ultérieure et l'éditeur de liens impose désormais une vue plus stricte de ce qui est disponible. Le message est donc destiné à aider à cette transition.
Que faire?
Si vous êtes le responsable du logiciel
Vous devez résoudre ce problème en vous assurant que toutes les bibliothèques nécessaires pour satisfaire les symboles requis sont directement spécifiées sur la ligne de commande de l'éditeur de liens. Gardez également à l'esprit que l'ordre est souvent important.
Si vous essayez juste de compiler le logiciel
En guise de solution de contournement, il est possible de revenir à la vue plus permissive des symboles disponibles en utilisant l'option -Wl,--copy-dt-needed-entries.
Les manières courantes d'injecter cela dans une construction sont d'exporter LDFLAGS avant d'exécuter configure ou similaire, comme ceci:
export LDFLAGS="-Wl,--copy-dt-needed-entries"
Parfois, passer LDFLAGS="-Wl,--copy-dt-needed-entries" directement à make peut également fonctionner.
Veuillez ajouter: CFLAGS="-lrt" et LDFLAGS="-lrt"
Ce que j’ai trouvé, c’est que parfois la bibliothèque contre laquelle l’éditeur de liens se plaint n’est pas celle qui cause le problème. Peut-être y a-t-il une façon intelligente de déterminer le problème, mais voici ce que je fais:
- Mettez en commentaire toutes les bibliothèques liées dans la commande link.
- Nettoyez tous les fichiers .o, .so, etc. (Généralement, le nettoyage est suffisant, mais vous pouvez exécuter une recherche récursive + rm ou quelque chose de similaire).
- Décommentez les bibliothèques dans la commande link une à la fois et modifiez l'ordre si nécessaire.
@ Peter Karasev: J'ai rencontré le même problème avec un projet gcc 4.8.2 cmake sur CentOS7. L'ordre des bibliothèques dans la section "target_link_libraries" est important. J'imagine que cmake ne fait que transmettre la liste à l'éditeur de liens tel quel, c'est-à-dire qu'il n'essaie pas de déterminer le bon ordre. C'est raisonnable - quand vous y réfléchissez, cmake ne peut pas savoir quel est le bon ordre tant que la liaison n'est pas terminée.
Le même problème m’est arrivé lorsque j’utilise distcc pour créer mon projet c ++; Finalement, je l'ai résolu avec export CXX="distcc g++".
Si vous utilisez g++, assurez-vous que vous n’exécutez pas gcc à la place.
La même chose m’est arrivée lors de l’installation du benchmark HPCC (inclut HPL et quelques autres benchmarks). J'ai ajouté -lm aux drapeaux du compilateur dans mon script de construction, puis il a été compilé avec succès.