2009-04-07 18 views
9

Una terza parte mi ha fornito un lib statico (.a) per collegarsi alla stazione solaris. Ho provato a compilare con sunpro e non sono riuscito al passaggio del collegamento.C'è un modo per sapere quale compilatore ha generato una libreria statica?

Suppongo che il problema provenga dal compilatore che uso (gcc invece? passo).

Come posso sapere quale compilatore è stato utilizzato per generare questa libreria? C'è qualche strumento per farlo? Qualche opzione su sunpro/gcc o altro?

Come suggerimento: Ho letto qualche tempo fa che i compilatori utilizzano diverse convenzioni di manomissione durante la generazione di file oggetto (vero?). Ancora, "nm --demangle" La riga di comando mi stampa bene tutti i nomi di funzioni dai simboli di debug in questa libreria statica. Come funziona ? Se la mia ipotesi è ok, nm ha un modo per risolvere quale convenzione è in uso in una libreria statica, non è vero? O è semplicemente il significato che lib è stato generato da GNU gcc, dato che nm è una parte dei binutils di GNU?

Non sto vicino alla mia postazione di lavoro, quindi non posso copiare & pasta di output di errore dal linker (non per il momento, ma li ho potuto copiare in una ulteriore modifica)

+1

Perché non chiedi alla "terza parte" che ha fornito la libreria per istruzioni su come usarla? –

+0

Ho chiesto loro. Ma nessuna risposta dal loro team di supporto, che è riluttante a chiedere al team di sviluppo, sembra ...:/ –

risposta

2

tendo a usare il programma strings (con l'opzione '-a', o il mio variante dove il '-a' comportamento è standard) e cercare i segni rivelatori. Per esempio, in una delle mie librerie, trovo:

/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 

Ciò suggerisce che il codice nella libreria è stato compilato con una varietà di versioni di GCC per un periodo di anni (in realtà, sono abbastanza sorpreso di trovare così tante versioni in una singola libreria).

Un'altra 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 ... 

così, ci sono di solito impronte digitali nei file oggetto che indicano quale compilatore è stato utilizzato. Ma devi sapere come cercarli.

-1

Si può provare l'utility UNIX file di:

file foo.a 
+0

Ho provato ma mi ricordo che mi dice solo che questo file utilizza il formato ELF per la piattaforma SPARC. Sunpro genera il formato ELF, come fa GCC? –

+0

Lo strumento 'file' difficilmente restituirà informazioni sul compilatore utilizzato! – Enzo

2

è la biblioteca dovrebbe essere una libreria C++ o C?

Se è una libreria C, il nome mangling non può essere il problema, poiché non ce n'è uno in C. Potrebbe tuttavia essere in un formato errato. Unices utilizzava librerie nel formato a.out ma quasi tutte le versioni più recenti passavano a formati più potenti come ELF.

Se si tratta di una libreria C++, il nome del mangling può essere un problema. La maggior parte dei compilatori incorpora alcuni simboli che sono specifici del compilatore nel codice, quindi se hai uno strumento come nm per elencare i simboli puoi dedurre da quale compilatore è arrivato.

Per esempio g ++ crea un simbolo

__gxx_personality_v0

nella sua librerie

4

estrarre i file oggetto dall'archivio quindi eseguire il comando strings su alcuni di essi (prima sul quelli più piccoli poiché ci sarebbe meno rumore da setacciare). Molti compilatori inseriscono firme ASCII nei file oggetto.

Ad esempio, il seguente file di origine senza senso, foo.c:

extern void blah(); 

quando compilato sulla mia macchina Fedora 10 in foo.o via gcc -c -o foo.o foo.c risultati in un file foo.o oggetto 647 byte.Esecuzione strings su foo.o risultati in

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

che rende chiaro il compilatore GCC è stato. Anche se l'avessi compilato con -fno-ident, la sezione ELF della nota .GNU-stack sarebbe stata ancora presente.

È possibile estrarre i file oggetto utilizzando l'utilità ar, o utilizzando Midnight Commander (che integra ar), oppure si può semplicemente eseguire strings sull'archivio (che potrebbe darvi più rumore ed essere meno rilevante, ma sarebbe comunque aiutare .)

+0

Oppure esegui semplicemente "stringhe" direttamente nella libreria: non è necessario prima estrarre i file oggetto. –

+0

Come ho già detto, c'è molto più output, * specialmente * nel caso di file oggetto C++, ed è molto più facile perdere le firme del compilatore. Inoltre, non è necessario che tutti gli oggetti in un archivio provengano dallo stesso compilatore ... –

Problemi correlati