Modifiche introdotte in gcc 4.5 rispetto al collegamento?

Question

Ho un progetto che produce una libreria condivisa che è collegata a un'altra libreria, anch'essa condivisa.

Quando compilo e collegarlo con gcc 4.4, tutto funziona:

1. non in fase di compilazione di avvertimento o di errore,
2. tempo linking avvertimento o di errore e
3. ldd libmyproject.so segnala correttamente la dipendenza con l'altra libreria condivisa.

Quando compilo e collegarlo con gcc 4.5, d'altra parte (con le stesse bandiere), ho i seguenti sintomi:

1. alcun avviso di compilazione o di un errore,
2. nessun collegamento avvertimento tempo o errore ma
3. la libreria non è correttamente legato contro l'altro lib comune: questo si manifesta quando ho eseguito ldd e non vedo la connessione, e anche quando cerco di usarlo: mentre funziona con gcc 4.4, si blocca es a run-time con gcc 4.5 con un errore "symbol not found" (ovviamente dall'altra lib).

ho guardato il release notes e la mia intuizione è che ha qualcosa a che fare con la nuova ottimizzazione link-tempo, ma non riuscivo a capire in dettagli sufficienti.

Qualcuno ha riscontrato una situazione simile e/o ha qualche consiglio da offrire?

(notare che i risultati con 4.6 sono identici a 4.5).

Answer 1

Per riassumere la risposta di Mat dal GCC 4.5 vs 4.4 linking with dependencies e la discussione in commenti, è necessario il collegamento con:

--copy-dt-needed-entries and --no-as-needed 

Answer 2

È possibile eseguire il debug dell'applicazione dinamica collegata con la variabile di ambiente LD_DEBUG. Questa è un'opzione di ld-linux.so.2; ldd è uno script per impostare anche questa opzione. Tutte le opzioni sono descritte alla pagina man http://linux.die.net/man/8/ld-linux.

Come usare LD_DEBUG (in bash, il modo più semplice):

$ LD_DEBUG=all ./your_program 

Ciò attivare il debug di LD-linux.so.2 - il linker dinamico in fase di esecuzione. Si stamperà un sacco di debug per stdout o stderr e si sarà in grado di

• 1) confrontare l'uscita di "LD_DEBUG=all ./your_program_4.4" e "LD_DEBUG=all ./your_program_4.5"
• 2) vedere l'ultima simboli cercando di risolvere e di individuare simbolo buggy.

Inoltre, ci si dovrebbe dare maggiori informazioni:

• 0) Qual è il sistema operativo e il tipo di CPU? (ci mostra l'output di uname -a) Qual è la versione di libc? (eseguito in bash for a in /lib*/libc.so.*;do echo $a; $a; done)
• 1) Cosa sono le bandiere di compilazione della libreria stessa?
• 2) Qual è l'errore esatto quando si tenta di eseguire l'applicazione?
• 3) Ultimi versi di uscita del LD_DEBUG possono contenere informazioni preziose

UPDATE: Il bene e precisa risposta è qui: GCC 4.5 vs 4.4 linking with dependencies (da Mat)

Answer 3

Assicurarsi di specificare le librerie condivise dopo i file oggetto (o origine) sulla riga di comando del linker.

Questo è il modo in cui dovevi farlo con le librerie statiche ai vecchi tempi. Sembra essere di nuovo utile con le versioni recenti di GCC. Per quanto ne so, se analizza una libreria condivisa che non fornisce simboli utili, ignora l'intera libreria, che ottimizza il numero di librerie condivise caricate in fase di esecuzione, ma richiede che le opzioni -libname vengano visualizzate dopo la file oggetto.