Compilar C/C++ linkando estáticamente librerías

dagavi

Hola wenas, estoy intentando compilar un código linkando estáticamente las librerías de las que hace uso.

Concretamente mi código hace uso de pcap, iw, trace i pthread. Todas ellas tienen los archivos .so y un .a, de la trace además hay un .la

Algunas de las librerías en /usr/lib

Al compilar de forma normal (haciendo uso de las librerías dinámicas) el ejecutable se linka correctamente, pero al añadir el parámetro -static el linkado falla diciendo "Undefined reference to" y las difernetes llamadas que hago a los códigos de las librerías.

El makefile tiene estas líneas:

CC=g++
CXXFLAGS=-DDEBUG -Iinclude -ansi -O2 -DNDEBUG -Wall -Wextra -Werror -Wno-uninitialized -Wno-sign-compare -Wno-unused-parameter -Wno-unused-result
LDFLAGS=-lpcap -liw -lpthread -ltrace

Si en LDFLAGS añado "-static" es cuando no linka (también lo he añadido a CXXFLAGS sin éxito). Para probar también he intentado realizar una compilación "manual" con el comando:

g++ -o main -DDEBUG -Iinclude -static -pthread -ltrace -ltrace -lpcap *.cpp

Con los mismos

resultados

¿Que hago mal? La pthread lo arreglo cambiando el -lpthread por un simple "-pthread", pero, obviamente, esto no arregla el resto de dependencias.

Saludos!

LOc0

NO te puedo dar la solución pero yo compilaría un hello.c estáticamente contra todas las librerías a ver si el problema es entre ellas. Luego iría haciendo combinaciones de linkados quitando una a ver cuál es la que peta. Revisa tb los directorios de INCLUDE de las librerías y el orden de llamada. (Si una librería llama a una función de otra, la librería llamante va antes que la llamada y lo mismo para el fichero con el código del programa que llama. Siempre el llamador antes del llamado).

¡ÁNIMO!

1 respuesta
dagavi

Edit: #2 Pos el programa que pongo aquí de ejemplo compila correctamente poniendo los *.c/cpp antes del -static -lpthread, voy a realizar pruebas con mi makefile :O

Edit2: Aunque ya lo dejo para mañana, que con más código no me es tan simple xD


#2 Lo primero lo he intentado haciendo:

Código picado directamente aquí, no me hago responsable de que no compile xD

Y compilándolo con:

gcc -o prog -static -lpthread prog.c

(usando -lpthread y no solo -pthread que parece que hace otras cosas)

Obteniendo el mismo resultado :(

Ahora mismo pruebo a ver de nuevo este mini progama que he puesto aquí pero poniendo el "prog.c" como tercer parámetro, a ver si cambia algo...

Por otro lado diría que he probado a cambiar todos los órdenes de librerías, pero lo volveré a probar a ver si consigo que funcione -.-

Saludos y gracias :D

LOc0

Hola. Acabo de probar a compilar ese código con:

gcc dagavi.c -static -lpthread -o dagavi

y se lo traga perfectamente dándome un ejecutable de unos 700KB

He probado tb con

gcc dagavi.c -lpthread -o juas

y se lo traga tb dándome un ejecutable de unos 7 KB

Salu2 ;)

Edit: ya he leído tu edit ;) Prueba porque si no es del orden es de la ruta del INCLUDE de las librerías.

dagavi

Me volví a poner a intentar compilar, pero sin el makefile que usa reglas implícitas y le cambia el orden.

La siguiente línea compila correctamente un código con enlazado dinámico:

g++ -o main *.cpp -DDEBUG -Iinclude -ltrace -lpcap -liw -lpthread

Al poner el -static tengo también que añadir -lzlib ya que hay otra que hace uso de ella, se añade:

g++ -o main *.cpp -DDEBUG -Iinclude -static -ltrace -lpcap -liw -lpthread -lzlib

Pero peta de esta forma:

/usr/lib/libpcap.a(nametoaddr.o): In function `pcap_nametoaddrinfo':
(.text+0x4a9): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/usr/lib/libtrace.a(format_rt.o): In function `rt_start_input':
(.text+0xb3d): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/usr/lib/libpcap.a(nametoaddr.o): In function `pcap_nametonetaddr':
(.text+0x40d): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/usr/lib/libpcap.a(nametoaddr.o): In function `pcap_nametoproto':
(.text+0x22d): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/usr/lib/libpcap.a(nametoaddr.o): In function `pcap_nametoport':
(.text+0x276): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

collect2: ld returned 1 exit status

El mensaje deja claro que ocurre. Sin embargo buscando en Google no doy con algo que me diga "se puede solventar de esta forma" o "eso significa que no podrás compilarlo estático" (vamos, o la solución o algo que me indique que eso no se puede arreglar).

¿Alguien sabe si eso se puede saltar? SI a mi me da igual que llame a la glibc dinámicamente, yo quiero que las otras estén estáticas xD

LOc0

Oye por curiosidad, ¿lo solucionaste? ¿Esos warnings no te dejan compilar?

Salu2 ;)

1 respuesta
dagavi

Aun no, lo he dejado por ahora aparcado el tema de los warnings de la glibc. Si bien de vez en cuando he ido buscando info sin éxito.

Esta semana lo miraré más a fondo (que será cuando realmente tendré que compilar), pero creo que no tendrá solución :( Tal vez si recompilara las librerías de las que hago uso si podría funcionar (hago uso de las obtenidas por apt-get install lib...-dev), pero teniendo en cuenta que las librerías de las que hago uso en distros como Ubuntu se puede conseguir con un simple apt-get install no creo que acabe siendo mucho problema.

Los warnings esos no dejan compilar al pedir un -static, pero no salen si no se le solicita esto.

Actualización: #6 pues al final sigo como estaba: algunos paquetes no les da la gana compilarse como static. Dejé ese tema ya que gracias a las dependencias de los paquetes DEB o RPM actualmente esto se puede solventar bastante bien (si bien corres el riesgo de que desaparezcan de los repos, cambien de versión y deje de funcionar o cosas por el estilo).

Usuarios habituales

  • dagavi
  • LOc0