Когда я компилирую 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
неg++
Ответы:
Вы должны упомянуть библиотеку в командной строке после компиляции объектных файлов:
Пояснение: связывание зависит от порядка модулей. Символы сначала запрашиваются, а затем связываются из библиотеки, в которой они есть. Таким образом, вы должны указать модули, которые сначала используют библиотеки, а библиотеки после них. Как это:
Более того, в случае циклической зависимости вы должны указывать одну и ту же библиотеку в командной строке несколько раз. Таким образом, в случае, если
libb
требуется символ fromlibc
иlibc
нужен символ fromlibb
, командная строка должна быть:источник
-Wl,--start-group -la -lb- -lc -Wl,--end-group
для круговых зависимостей.Сообщение об ошибке зависит от версии дистрибутива / компилятора:
Ubuntu Saucy:
Ubuntu Raring: (более информативно)
Решение. Возможно, вам не хватает библиотеки на этапах компиляции на этапе компоновки. В моем случае я добавил '-lz' в флаги makefile / GCC.
Справочная информация: DSO - это динамический общий объект или общая библиотека.
источник
glewInit
, вам нужно-lGLEW
Задний план
DSO missing from command line
Сообщение будет отображаться , когда линкер не находит нужный символ с его обычным поиском , но символ доступен в одном из зависимостей непосредственно указанной динамической библиотеки.В прошлом компоновщик считал символы в зависимостях указанных языков доступными. Но это изменилось в более поздней версии, и теперь компоновщик обеспечивает более строгое представление о том, что доступно. Таким образом, сообщение предназначено, чтобы помочь с этим переходом.
Что делать?
Если вы являетесь сопровождающим программного обеспечения
Вы должны решить эту проблему, убедившись, что все библиотеки, необходимые для удовлетворения необходимых символов, непосредственно указаны в командной строке компоновщика. Также имейте в виду, что порядок часто имеет значение.
Если вы просто пытаетесь скомпилировать программное обеспечение
В качестве обходного пути можно переключиться обратно на более разрешающее представление доступных символов, используя опцию
-Wl,--copy-dt-needed-entries
.Распространенные способы внедрить это в сборку - экспортировать LDFLAGS перед запуском
configure
или подобным образом:Иногда передача
LDFLAGS="-Wl,--copy-dt-needed-entries"
непосредственноmake
может также работать.источник
-Wl,
бит, либо у вас есть компоновщик, который не поддерживает эти опции. Какой линкер вы используете? Этот ответ предполагает классический линкер binutils (ld.bfd). Золотой компоновщик binutils (ld.gold) помечается--copy-dt-needed-entries
как «Не поддерживается». Поэтому, если у вас есть это (или любой другой компоновщик, который не поддерживает эту опцию) по умолчанию, вам может потребоваться следовать разделу для сопровождающих или перейти на классический ld для компоновки. Я думаю, что вы можете использовать-fuse-ld=ld.bfd
для этого.Я нашел другой случай, и поэтому я думаю, что вы все не правы.
Вот что у меня было:
Проблема в том, что командная строка НЕ содержит
-lX11
- хотя libX11.so должен быть добавлен как зависимость, потому что в аргументах были также библиотеки GTK и GNOME.Итак, единственное объяснение для меня - это то, что это сообщение могло помочь вам , но оно не сделало это должным образом. Вероятно, это было просто: библиотека, предоставляющая символ, не была добавлена в командную строку.
Обратите внимание на три важных правила, касающихся связи в POSIX:
-l<name>
, вы никогда не знаете, будет ли онаlib<name>.so
илиlib<name>.a
. Динамическая библиотека предпочтительнее, если она найдена, и статические библиотеки могут быть применены только с помощью параметра компилятора - и все. И если у вас есть какие-либо проблемы, как указано выше, это зависит от того, были ли у вас статические или динамические библиотекиисточник
Я обнаружил, что у меня была такая же ошибка. Я компилировал код с использованием lapack и blas. Когда я сменил порядок именования двух библиотек, ошибка исчезла.
«LAPACK_LIB = -llapack -lblas» работал там, где «LAPACK_LIB = -lblas -llapack» выдал ошибку, описанную выше.
источник
find_package(Threads)
иtarget_link_libraries( ... ${CMAKE_THREAD_LIBS_INIT})
Я также столкнулся с той же проблемой. Я не знаю почему, я просто добавляю
-lpthread
опцию в компилятор и все в порядке.Старый:
получил следующую ошибку. Если я добавлю
-lpthread
опцию к вышеуказанной команде, тогда ОК.источник
Я обнаружил, что иногда библиотека, на которую жалуется компоновщик, не та, которая вызывает проблему. Возможно, есть умный способ решить, где проблема, но это то, что я делаю:
@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, попробуйте добавить следующие строки
источник
То же самое произошло со мной, когда я устанавливал тест HPCC (включая HPL и несколько других тестов). Я добавил
-lm
флаги компилятора в свой скрипт сборки, а затем он успешно скомпилирован.источник
При использовании
g++
убедитесь, что вы не работаетеgcc
вместоисточник
Попробуйте добавить
-pthread
в конец списка библиотек в Makefile .Это сработало для меня.
источник
Если вы используете CMake, есть несколько способов решить эту проблему:
Решение 1: самый элегантный
Решение 2: использование CMake
find_package
Решение 3: Изменить флаги CMake
источник