libpthread.so.0: ошибка при добавлении символов: DSO отсутствует в командной строке

Когда я компилирую openvswitch-1.5.0, я столкнулся со следующей ошибкой компиляции:

 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

Если я попытаюсь увидеть символы libpthread, это выглядит хорошо.

$ 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

Не могли бы вы дать какие-либо подсказки или указатели?

Вы должны упомянуть библиотеку в командной строке после компиляции объектных файлов:

 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 

Пояснение: связывание зависит от порядка модулей. Символы сначала запрашиваются, а затем связываются из библиотеки, в которой они есть. Таким образом, вы должны указать модули, которые сначала используют библиотеки, а библиотеки после них. Как это:

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

Более того, в случае циклической зависимости вы должны указывать одну и ту же библиотеку в командной строке несколько раз. Таким образом, в случае, если libbтребуется символ from libcи libcнужен символ from libb, командная строка должна быть:

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

Сообщение об ошибке зависит от версии дистрибутива / компилятора:

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: (более информативно)

/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

Решение. Возможно, вам не хватает библиотеки на этапах компиляции на этапе компоновки. В моем случае я добавил '-lz' в флаги makefile / GCC.

Справочная информация: DSO - это динамический общий объект или общая библиотека.

Задний план

DSO missing from command lineСообщение будет отображаться , когда линкер не находит нужный символ с его обычным поиском , но символ доступен в одном из зависимостей непосредственно указанной динамической библиотеки.

В прошлом компоновщик считал символы в зависимостях указанных языков доступными. Но это изменилось в более поздней версии, и теперь компоновщик обеспечивает более строгое представление о том, что доступно. Таким образом, сообщение предназначено, чтобы помочь с этим переходом.

Что делать?

Если вы являетесь сопровождающим программного обеспечения

Вы должны решить эту проблему, убедившись, что все библиотеки, необходимые для удовлетворения необходимых символов, непосредственно указаны в командной строке компоновщика. Также имейте в виду, что порядок часто имеет значение.

Если вы просто пытаетесь скомпилировать программное обеспечение

В качестве обходного пути можно переключиться обратно на более разрешающее представление доступных символов, используя опцию -Wl,--copy-dt-needed-entries .

Распространенные способы внедрить это в сборку - экспортировать LDFLAGS перед запуском configureили подобным образом:

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

Иногда передача LDFLAGS="-Wl,--copy-dt-needed-entries"непосредственно makeможет также работать.

Я нашел другой случай, и поэтому я думаю, что вы все не правы.

Вот что у меня было:

/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

Проблема в том, что командная строка НЕ ​​содержит -lX11 - хотя libX11.so должен быть добавлен как зависимость, потому что в аргументах были также библиотеки GTK и GNOME.

Итак, единственное объяснение для меня - это то, что это сообщение могло помочь вам , но оно не сделало это должным образом. Вероятно, это было просто: библиотека, предоставляющая символ, не была добавлена ​​в командную строку.

Обратите внимание на три важных правила, касающихся связи в POSIX:

• Динамические библиотеки имеют определенные зависимости, поэтому только библиотеки из top-зависимости должны предоставляться в любом порядке (хотя после статических библиотек)
• Статические библиотеки имеют только неопределенные символы - вы должны знать их зависимости и предоставлять их все в командной строке
• Порядок в статических библиотеках всегда: запрашивающий первый , поставщик следует . В противном случае вы получите неопределенное символьное сообщение, как если бы вы забыли добавить библиотеку в командную строку
• Когда вы указываете библиотеку с -l<name>, вы никогда не знаете, будет ли она lib<name>.soили lib<name>.a. Динамическая библиотека предпочтительнее, если она найдена, и статические библиотеки могут быть применены только с помощью параметра компилятора - и все. И если у вас есть какие-либо проблемы, как указано выше, это зависит от того, были ли у вас статические или динамические библиотеки
• Ну, иногда в динамических библиотеках могут отсутствовать зависимости: D

Я обнаружил, что у меня была такая же ошибка. Я компилировал код с использованием lapack и blas. Когда я сменил порядок именования двух библиотек, ошибка исчезла.

«LAPACK_LIB = -llapack -lblas» работал там, где «LAPACK_LIB = -lblas -llapack» выдал ошибку, описанную выше.

Я также столкнулся с той же проблемой. Я не знаю почему, я просто добавляю -lpthreadопцию в компилятор и все в порядке.

Старый:

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

получил следующую ошибку. Если я добавлю -lpthreadопцию к вышеуказанной команде, тогда ОК.

/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

Я обнаружил, что иногда библиотека, на которую жалуется компоновщик, не та, которая вызывает проблему. Возможно, есть умный способ решить, где проблема, но это то, что я делаю:

• Закомментируйте все связанные библиотеки в команде link.
• Очистите все .o, .so и т. Д. (Обычно достаточно сделать clean, но вы можете запустить рекурсивный поиск + rm или что-то подобное).
• Раскомментируйте библиотеки в команде link по одной и измените порядок при необходимости.

@peter karasev: я столкнулся с той же проблемой в проекте cmake gcc 4.8.2 на CentOS7. Порядок библиотек в разделе "target_link_libraries" важен. Я предполагаю, что cmake просто передает список компоновщику как есть, то есть он не пытается определить правильный порядок. Это разумно - когда вы думаете об этом, cmake не может знать, каков правильный порядок, пока соединение не будет успешно завершено.

Пожалуйста, добавьте: CFLAGS="-lrt"иLDFLAGS="-lrt"

Та же проблема случилась со мной, когда я использовал distccсвой проект на c ++; Наконец я решил это с export CXX="distcc g++".

если вы используете cmake и pthreads, попробуйте добавить следующие строки

find_package(Threads)
target_link_libraries(${CMAKE_THREAD_LIBS_INIT})

То же самое произошло со мной, когда я устанавливал тест HPCC (включая HPL и несколько других тестов). Я добавил -lmфлаги компилятора в свой скрипт сборки, а затем он успешно скомпилирован.

При использовании g++убедитесь, что вы не работаете gccвместо

Попробуйте добавить -pthreadв конец списка библиотек в Makefile .

Это сработало для меня.

Если вы используете CMake, есть несколько способов решить эту проблему:

Решение 1: самый элегантный

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

Решение 2: использование 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})

Решение 3: Изменить флаги CMake

# 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")