Risoluzione delle dipendenze circolari collegando due volte la stessa libreria?

Question

Abbiamo una base di codice suddivisa in librerie statiche. Sfortunatamente, le librerie hanno dipendenze circolari; ad esempio, libfoo.a dipende da libbar.a e viceversa.

So che il modo "corretto" per gestire questa situazione è quello di utilizzare --start-group e --end-group opzioni del linker, in questo modo:

g++ -o myApp -Wl,--start-group -lfoo -lbar -Wl,--end-group 

Ma nelle nostre Makefiles esistenti, il problema è in genere gestito in questo modo:

g++ -o myApp -lfoo -lbar -lfoo 

(Immaginate questo esteso a ~ 20 biblioteche con complesse interdipendenze.)

vado attraverso ou r Makefile che cambiano la seconda forma alla prima, ma ora i miei colleghi mi chiedono perché ... E a parte "perché è più pulito" e un vago senso che l'altra forma sia rischiosa, non ho una buona risposta.

Quindi, è possibile collegare la stessa libreria più volte sempre creare un problema? Ad esempio, il collegamento potrebbe fallire con simboli definiti in modo multiplo se lo stesso .o viene inserito due volte? O c'è qualche rischio di finire con due copie dello stesso oggetto statico, creando bug sottili?

Fondamentalmente, desidero sapere se esiste la possibilità di errori di collegamento o di runtime per collegare più volte la stessa libreria; e se è così, come attivarli. Grazie.

Answer 1

Tutto quello che posso offrire è una mancanza di controesempio. Non ho mai visto la prima forma prima (anche se è chiaramente migliore) e ho sempre visto questo risolto con la seconda forma, e di conseguenza non ho osservato problemi.

Anche così suggerirei di passare al primo modulo perché mostra chiaramente la relazione tra le librerie piuttosto che affidarsi al linker che si comporta in un modo particolare.

Detto questo, vorrei suggerire almeno considerando se esiste la possibilità di refactoring del codice per estrarre i pezzi comuni in librerie aggiuntive.

Answer 2

Dato che si tratta di un'applicazione legacy, scommetto che la struttura delle librerie è ereditata da un accordo che probabilmente non ha più importanza, come ad esempio essere utilizzato per costruire un altro prodotto che non si fa più.

Anche se rimangono ancora motivi strutturali per la struttura della libreria ereditata, quasi certamente, sarebbe ancora accettabile creare un'altra libreria dall'accordo legacy. Basta mettere tutti i moduli delle 20 librerie in una nuova libreria, liballofthem.a. Quindi ogni singola applicazione è semplicemente g++ -o myApp -lallofthem ...