libpthread.so.0: Fehler beim Hinzufügen von Symbolen: DSO fehlt in der Befehlszeile

Beim Kompilieren von openvswitch-1.5.0 ist der folgende Kompilierungsfehler aufgetreten:

 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

Wenn ich versuche, die Symbole von zu sehen libpthread, sieht es gut aus.

$ 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

Könnten Sie irgendwelche Hinweise oder Hinweise geben?

Sie sollten die Bibliothek in der Befehlszeile nach dem Kompilieren der Objektdateien erwähnen :

 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 

Erläuterung: Die Verknüpfung hängt von der Reihenfolge der Module ab. Symbole werden zuerst angefordert und dann aus einer Bibliothek mit ihnen verknüpft. Sie müssen also Module angeben, die zuerst Bibliotheken und danach Bibliotheken verwenden. So was:

gcc x.o y.o z.o -la -lb -lc

Darüber hinaus sollten Sie bei einer zirkulären Abhängigkeit dieselbe Bibliothek mehrmals in der Befehlszeile angeben. Für den Fall, dass ein libbSymbol von libcund ein libcSymbol von benötigt wird libb, sollte die Befehlszeile wie folgt lauten:

gcc x.o y.o z.o -la -lb -lc -lb

Die Fehlermeldung hängt von der Distribution / Compiler-Version ab:

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: (informativer)

/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

Lösung: Während der Verknüpfungsphase fehlt möglicherweise eine Bibliothek in Ihren Kompilierungsschritten. In meinem Fall habe ich '-lz' zu Makefile / GCC-Flags hinzugefügt.

Hintergrund: DSO ist ein dynamisches freigegebenes Objekt oder eine gemeinsam genutzte Bibliothek.

Hintergrund

Die DSO missing from command lineMeldung wird angezeigt, wenn der Linker das erforderliche Symbol bei seiner normalen Suche nicht findet, das Symbol jedoch in einer der Abhängigkeiten einer direkt angegebenen dynamischen Bibliothek verfügbar ist.

In der Vergangenheit betrachtete der Linker Symbole in Abhängigkeiten bestimmter Sprachen als verfügbar. Dies hat sich jedoch in einer späteren Version geändert, und jetzt erzwingt der Linker eine strengere Sicht auf das, was verfügbar ist. Die Nachricht soll somit bei diesem Übergang helfen.

Was ist zu tun?

Wenn Sie der Betreuer der Software sind

Sie sollten dieses Problem lösen, indem Sie sicherstellen, dass alle Bibliotheken, die zur Erfüllung der erforderlichen Symbole benötigt werden, direkt in der Linker-Befehlszeile angegeben sind. Denken Sie auch daran, dass die Reihenfolge oft wichtig ist.

Wenn Sie nur versuchen, die Software zu kompilieren

Um dieses Problem zu umgehen, können Sie mithilfe der Option wieder in die freizügigere Ansicht der verfügbaren Symbole wechseln -Wl,--copy-dt-needed-entries.

Übliche Methoden, um dies in einen Build einzufügen, sind das Exportieren von LDFLAGS vor dem Ausführen configureoder ähnliches:

export LDFLAGS="-Wl,--copy-dt-needed-entries"

Manchmal funktioniert es auch, LDFLAGS="-Wl,--copy-dt-needed-entries"direkt an zu gehen make.

Ich habe einen anderen Fall gefunden und deshalb bin ich der Meinung, dass Sie alle falsch liegen.

Das hatte ich:

/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

Das Problem ist, dass die Befehlszeile NICHT enthielt -lX11- obwohl libX11.so als Abhängigkeit hinzugefügt werden sollte, da die Argumente auch GTK- und GNOME-Bibliotheken enthielten .

Die einzige Erklärung für mich ist, dass diese Nachricht möglicherweise dazu gedacht war, Ihnen zu helfen , aber sie hat es nicht richtig gemacht. Dies war wahrscheinlich einfach: Die Bibliothek, die das Symbol bereitstellt, wurde nicht zur Befehlszeile hinzugefügt.

Bitte beachten Sie drei wichtige Regeln bezüglich der Verknüpfung in POSIX:

• Dynamische Bibliotheken haben Abhängigkeiten definiert, daher sollten nur Bibliotheken aus der obersten Abhängigkeit in beliebiger Reihenfolge bereitgestellt werden (obwohl nach den statischen Bibliotheken).
• Statische Bibliotheken haben nur undefinierte Symbole - es liegt an Ihnen, ihre Abhängigkeiten zu kennen und alle in der Befehlszeile anzugeben
• Die Reihenfolge in statischen Bibliotheken lautet immer: Anforderer zuerst , Anbieter folgt . Andernfalls erhalten Sie eine undefinierte Symbolmeldung, genau wie wenn Sie vergessen haben, die Bibliothek zur Befehlszeile hinzuzufügen
• Wenn Sie die Bibliothek mit angeben -l<name>, wissen Sie nie, ob lib<name>.sooder lib<name>.a. Die dynamische Bibliothek wird bevorzugt, wenn sie gefunden wird, und statische Bibliotheken können nur durch die Compileroption erzwungen werden - das ist alles. Und ob Sie wie oben beschrieben Probleme haben, hängt davon ab, ob Sie statische oder dynamische Bibliotheken hatten
• Nun, manchmal fehlen die Abhängigkeiten in dynamischen Bibliotheken: D.

Ich stellte fest, dass ich den gleichen Fehler hatte. Ich habe einen Code mit Lapack und Blas kompiliert. Als ich die Reihenfolge wechselte, in der die beiden Bibliotheken aufgerufen wurden, verschwand der Fehler.

"LAPACK_LIB = -llapack -lblas" funktionierte, wobei "LAPACK_LIB = -lblas -llapack" den oben beschriebenen Fehler ergab.

Ich bin auch auf das gleiche Problem gestoßen. Ich weiß nicht warum, ich füge nur eine -lpthreadOption zum Compiler hinzu und alles in Ordnung.

Alt:

$ g++ -rdynamic -m64 -fPIE -pie  -o /tmp/node/out/Release/mksnapshot ...*.o *.a -ldl -lrt

habe folgenden Fehler bekommen. Wenn ich die -lpthreadOption an den obigen Befehl anhänge , dann 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

Was ich gefunden habe ist, dass manchmal die Bibliothek, über die sich der Linker beschwert, nicht diejenige ist, die das Problem verursacht. Möglicherweise gibt es eine clevere Möglichkeit, herauszufinden, wo das Problem liegt, aber das mache ich:

• Kommentieren Sie alle verknüpften Bibliotheken im Befehl link aus.
• Bereinigen Sie alle .o's, .so's usw. (Normalerweise reicht es aus, sauber zu machen, aber Sie möchten möglicherweise einen rekursiven Find + rm oder ähnliches ausführen).
• Kommentieren Sie die Bibliotheken im Link-Befehl einzeln aus und ordnen Sie die Reihenfolge nach Bedarf neu.

@ Peter Karasev: Ich bin auf dasselbe Problem mit einem gcc 4.8.2 cmake-Projekt unter CentOS7 gestoßen. Die Reihenfolge der Bibliotheken im Abschnitt "target_link_libraries" ist wichtig. Ich denke, cmake gibt die Liste einfach so wie sie ist an den Linker weiter, dh es wird nicht versucht, die richtige Reihenfolge zu ermitteln. Dies ist vernünftig - wenn Sie darüber nachdenken, kann cmake nicht wissen, wie die richtige Reihenfolge ist, bis die Verknüpfung erfolgreich abgeschlossen wurde.

Bitte hinzufügen: CFLAGS="-lrt"undLDFLAGS="-lrt"

Das gleiche Problem ist mir passiert, als ich distccmein C ++ - Projekt erstellt habe. Endlich habe ich es mit gelöst export CXX="distcc g++".

Wenn Sie cmake und pthreads verwenden, fügen Sie die folgenden Zeilen hinzu

find_package(Threads)
target_link_libraries(${CMAKE_THREAD_LIBS_INIT})

Das gleiche passierte mir bei der Installation des HPCC-Benchmarks (einschließlich HPL und einiger anderer Benchmarks). Ich -lmhabe die Compiler-Flags in meinem Build-Skript hinzugefügt und dann erfolgreich kompiliert.

Stellen Sie bei Verwendung g++sicher, dass Sie nicht gccstattdessen ausgeführt werden

Versuchen Sie, -pthreadam Ende der Bibliotheksliste im Makefile hinzuzufügen .

Es hat bei mir funktioniert.

Wenn Sie CMake verwenden, gibt es einige Möglichkeiten, wie Sie es lösen können:

Lösung 1: Die eleganteste

add_executable(...)
target_include_directories(...)
target_link_libraries(target_name pthread)

Lösung 2: Verwenden von CMakefind_package

find_package(Threads REQUIRED) # this will generate the flag for CMAKE_THREAD_LIBS_INIT

add_executable(...)
target_include_directories(...)
target_link_libraries(target_name ${CMAKE_THREAD_LIBS_INIT})

Lösung 3: Ändern Sie die CMake-Flags

# e.g. with C++ 17, change to other version if you need
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -pthread")