2009-04-07 20 views
9

Un tercero me proporcionó una lib estática (.a) para enlazar con la estación de Solaris. Intenté compilar con sunpro y fallé en el paso de enlace.¿Hay alguna manera de saber qué compilador generó una biblioteca estática?

Supongo que el problema proviene del compilador que uso (¿gcc?) O simplemente su versión (ya que la biblioteca estándar proporcionada por el compilador podría cambiar de la versión esperada por la biblioteca AFAIK podría provocar errores en el enlace paso).

¿Cómo podría saber qué compilador se utilizó para generar esta lib? ¿Hay algunas herramientas haciendo eso? Alguna opción en sunpro/gcc o lo que sea?

A modo de sugerencia: He leído hace algún tiempo que los compiladores utilizan diferentes convenciones mangling al generar archivos de objetos (verdad?). Aún así, "nm --demangle" línea de comandos me imprime todos los nombres de funciones de los símbolos de depuración en esta lib estática. Como funciona ? Si mi suposición es correcta, nm tiene una manera de resolver qué convención está en uso en una biblioteca estática, ¿no? ¿O simplemente significa que lib fue generado por GNU gcc, ya que nm es parte de los binutils de GNU?

No estoy cerca de mi estación de trabajo así que no puedo copiar & pasta de salida de error del enlazador (no por el momento, pero podría copiarlos en una edición más)

+1

¿Por qué no le preguntas al "tercero" que suministró la biblioteca las instrucciones sobre cómo usarla? –

+0

les pregunté. Pero ninguna respuesta de su equipo de soporte, que es reacio a preguntarle al equipo de desarrollo, parece ...:/ –

Respuesta

2

tiendo a utilizar el programa strings (con la opción '-a', o mi propia variante en la que el '-a' comportamiento es estándar) y buscar las señales indicadoras. Por ejemplo, en una de mis propias bibliotecas, encuentro:

/work1/gcc/v4.2.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.3/include 
/work1/gcc/v4.3.0/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.0/include 
/work1/gcc/v4.3.1/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.1/include 
/work1/gcc/v4.3.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.3/include 

Eso sugiere que el código de la biblioteca se ha elaborado con una variedad de versiones de GCC durante un período de años (en realidad, estoy bastante sorprendido de encontrar tantas versiones en una sola biblioteca).

Otra biblioteca contiene:

cg: Sun Compiler Common 11 Patch 120760-06 2006/05/26 
acomp: Sun C 5.8 Patch 121015-02 2006/03/29 
iropt: Sun Compiler Common 11 Patch 120760-06 2006/05/26 
/compilers/v11/SUNWspro/prod/bin/cc -O -v -Xa -xarch=v9 ... 

lo tanto, no son por lo general las huellas dactilares en los archivos de objetos que indican qué compilador se utilizó. Pero debes saber cómo buscarlos.

-1

Usted puede probar la utilidad de UNIX archivo:

file foo.a 
+0

Lo intenté pero recuerdo que solo me dice que este archivo usa el formato ELF para la plataforma SPARC. ¿Sunpro genera formato ELF, como lo hace GCC? –

+0

¡La herramienta 'file' difícilmente devolverá información acerca del compilador utilizado! – Enzo

2

¿se supone que la biblioteca para ser una biblioteca de C o C++?

Si se trata de una biblioteca en C, el problema no puede ser el mangle, ya que no existe ninguno en C. Sin embargo, podría estar en un formato incorrecto. Los equipos solían tener bibliotecas en el formato a.out pero casi todas las versiones más nuevas cambiaban a formatos más potentes como ELF.

Si se trata de una biblioteca en C++, el cambio de nombre puede ser un problema. La mayoría de los compiladores incorporan algunos símbolos que son específicos del compilador en el código, por lo que si tiene una herramienta como nm para listar los símbolos, puede deducir de qué compilador proviene.

Por ejemplo g ++ crea un símbolo

__gxx_personality_v0

en Es bibliotecas

4

extraer los archivos objeto desde el archivo a continuación, ejecute el comando strings en algunos de ellos (por primera vez en el los más pequeños ya que habría menos ruido para tamizar). Muchos compiladores insertan firmas ASCII en los archivos de objeto.

Por ejemplo, el siguiente archivo de origen sin sentido, foo.c:

extern void blah(); 

cuando se compila en mi Fedora 10 en la máquina a través de foo.o gcc -c -o foo.o foo.c resultados en un archivo objeto foo.o 647 bytes.Correr strings en foo.o resultados en

GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) 
.symtab 
.strtab 
.shstrtab 
.text 
.data 
.bss 
.comment 
.note.GNU-stack 
foo.c

del que se desprende el compilador GCC era. Incluso si lo hubiera compilado con -fno-ident, la sección .FNU-stack note ELF todavía habría estado presente.

Puede extraer los archivos de objetos mediante la utilidad ar, o el uso de Midnight Commander (que integra ar), o simplemente puede ejecutar strings en el archivo (que podría darle más ruido y ser menos relevante, pero a pesar de ello ayudar .)

+0

O simplemente ejecute 'cadenas' directamente en la biblioteca; no es necesario extraer los archivos del objeto primero. –

+0

Como mencioné, hay mucho más salida, * especialmente * en el caso de los archivos de objeto C++, y es mucho más fácil pasar por alto las firmas del compilador. Además, no hay ningún requisito de que todos los objetos en un archivo sean del mismo compilador ... –

Cuestiones relacionadas