Cuando estoy compilando openvswitch-1.5.0, he encontrado el siguiente error de compilación:
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 trato de ver los símbolos de libpthread
, se ve 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
¿Podría dar alguna pista o sugerencia?
gcc
nog++
Respuestas:
Debe mencionar la biblioteca en la línea de comando después de que se compilen los archivos de objetos:
Explicación: la vinculación depende del orden de los módulos. Los símbolos se solicitan primero y luego se vinculan desde una biblioteca que los tiene. Por lo tanto, debe especificar los módulos que usan las bibliotecas primero y las bibliotecas después de ellos. Me gusta esto:
Además, en caso de que haya una dependencia circular, debe especificar la misma biblioteca en la línea de comando varias veces. Entonces, en caso de que
libb
necesite un símbololibc
y unlibc
símbolo delibb
, la línea de comando debería ser:fuente
-Wl,--start-group -la -lb- -lc -Wl,--end-group
para dependencias circulares.El mensaje de error depende de la versión de distribución / compilador:
Ubuntu Saucy:
Ubuntu Raring: (más informativo)
Solución: es posible que le falte una biblioteca en sus pasos de compilación, durante la etapa de vinculación. En mi caso, agregué '-lz' a las marcas de makefile / GCC.
Antecedentes: DSO es un objeto dinámico compartido o una biblioteca compartida.
fuente
glewInit
, usted necesita-lGLEW
Antecedentes
los
DSO missing from command line
mensaje se mostrará cuando el vinculador no encuentre el símbolo requerido con su búsqueda normal, pero el símbolo está disponible en una de las dependencias de una biblioteca dinámica directamente especificada.En el pasado, el vinculador consideraba que los símbolos en dependencias de idiomas específicos estaban disponibles. Pero eso cambió en alguna versión posterior y ahora el vinculador impone una visión más estricta de lo que está disponible. Por lo tanto, el mensaje está destinado a ayudar con esa transición.
¿Qué hacer?
Si eres el mantenedor del software
Debe resolver este problema asegurándose de que todas las bibliotecas necesarias para satisfacer los símbolos necesarios se especifiquen directamente en la línea de comando del vinculador. También tenga en cuenta que el orden a menudo es importante.
Si solo está intentando compilar el software
Como solución alternativa, es posible volver a la vista más permisiva de los símbolos disponibles mediante el uso de la opción
-Wl,--copy-dt-needed-entries
.Las formas comunes de inyectar esto en una compilación son exportar LDFLAGS antes de ejecutarlo
configure
o similar de esta manera:A veces, pasar
LDFLAGS="-Wl,--copy-dt-needed-entries"
directamente amake
podría funcionar también.fuente
-Wl,
bit o tienes un vinculador que no admite estas opciones. ¿Qué enlazador estás usando? Esta respuesta asume el clásico enlazador binutils (ld.bfd). El binutils gold linker (ld.gold) documenta--copy-dt-needed-entries
como "No compatible". Entonces, si tiene ese (o cualquier otro vinculador que no sea compatible con esta opción) como predeterminado, es posible que deba seguir la sección para mantenedores o cambiar al clásico ld para vincular. Creo que puedes usar-fuse-ld=ld.bfd
para eso.Encontré otro caso y, por lo tanto, creo que todos ustedes están equivocados.
Esto es lo que tenía:
El problema es que la línea de comando NO contenía
-lX11
, aunque libX11.so debería agregarse como una dependencia porque también había bibliotecas GTK y GNOME en los argumentos.Entonces, la única explicación para mí es que este mensaje podría haber sido para ayudarlo , pero no lo hizo correctamente. Esto probablemente fue simple: la biblioteca que proporciona el símbolo no se agregó a la línea de comando.
Tenga en cuenta tres reglas importantes sobre la vinculación en POSIX:
-l<name>
, nunca sabes si tomarálib<name>.so
o nolib<name>.a
. Se prefiere la biblioteca dinámica, si se encuentra, y las bibliotecas estáticas solo se pueden aplicar mediante la opción del compilador, eso es todo. Y si tiene algún problema como el anterior, depende de si tenía bibliotecas estáticas o dinámicas.fuente
Descubrí que tenía el mismo error. Estaba compilando un código tanto con lapack como con blas. Cuando cambié el orden en que se llamaban las dos bibliotecas, el error desapareció.
"LAPACK_LIB = -llapack -lblas" funcionó donde "LAPACK_LIB = -lblas -llapack" dio el error descrito anteriormente.
fuente
find_package(Threads)
ytarget_link_libraries( ... ${CMAKE_THREAD_LIBS_INIT})
También encontré el mismo problema. No sé por qué, solo agrego la
-lpthread
opción al compilador y todo está bien.Antiguo:
Tengo el siguiente error. Si agrego la
-lpthread
opción al comando anterior, entonces OK.fuente
Lo que he encontrado es que a veces la biblioteca de la que se queja el vinculador no es la que causa el problema. Posiblemente hay una manera inteligente de averiguar dónde está el problema, pero esto es lo que hago:
@peter karasev: me he encontrado con el mismo problema con un proyecto gcc 4.8.2 cmake en CentOS7. El orden de las bibliotecas en la sección "target_link_libraries" es importante. Supongo que cmake simplemente pasa la lista al enlazador tal como está, es decir, no intenta resolver el orden correcto. Esto es razonable: cuando lo piensa, cmake no puede saber cuál es el orden correcto hasta que la vinculación se complete con éxito.
fuente
Por favor agregue:
CFLAGS="-lrt"
yLDFLAGS="-lrt"
fuente
El mismo problema me sucedió cuando uso
distcc
para hacer mi proyecto de c ++; Finalmente lo resolví conexport CXX="distcc g++"
.fuente
si está usando cmake y pthreads, intente agregar las siguientes líneas
fuente
Me sucedió lo mismo cuando estaba instalando el benchmark HPCC (incluye HPL y algunos otros benchmarks). Agregué
-lm
a los indicadores del compilador en mi script de compilación y luego se compiló con éxito.fuente
Si lo usa
g++
, asegúrese de no estar ejecutando en sugcc
lugarfuente
Intente agregar
-pthread
al final de la lista de bibliotecas en el Makefile .Funcionó para mi.
fuente
Si está utilizando CMake, hay algunas formas en que podría resolverlo:
Solución 1: la más elegante
Solución 2: usando CMake
find_package
Solución 3: cambiar las banderas CMake
fuente