Collegamento statico di libstdc ++: qualche trucco?

Ho bisogno di distribuire un'applicazione C ++ costruita su Ubuntu 12.10 con libstdc ++ di GCC 4.7 su sistemi che eseguono Ubuntu 10.04, che viene fornito con una versione notevolmente precedente di libstdc ++.

Attualmente sto compilando -static-libstdc++ -static-libgcc, come suggerito da questo post del blog: Collegamento statico di libstdc ++ . L'autore mette in guardia dall'usare qualsiasi codice C ++ caricato dinamicamente durante la compilazione statica di libstdc ++, cosa che non ho ancora verificato. Tuttavia, finora sembra tutto filare liscio: posso utilizzare le funzionalità C ++ 11 su Ubuntu 10.04, che è quello che stavo cercando.

Noto che questo articolo è del 2005 e forse molto è cambiato da allora. I suoi consigli sono ancora attuali? Ci sono problemi in agguato di cui dovrei essere a conoscenza?

Quel post sul blog è piuttosto impreciso.

Per quanto ne so, le modifiche C ++ ABI sono state introdotte con tutte le principali versioni di GCC (cioè quelle con diversi componenti del numero di prima o seconda versione).

Non vero. Le uniche modifiche ABI C ++ introdotte da GCC 3.4 sono state retrocompatibili, il che significa che l'ABI C ++ è rimasta stabile per quasi nove anni.

A peggiorare le cose, la maggior parte delle principali distribuzioni Linux utilizza snapshot di GCC e / o patcha le loro versioni di GCC, rendendo praticamente impossibile sapere esattamente con quali versioni di GCC potresti avere a che fare quando distribuisci i binari.

Le differenze tra le versioni patchate delle distribuzioni di GCC sono minori e non cambiano ABI, ad esempio Fedora 4.6.3 20120306 (Red Hat 4.6.3-2) è ABI compatibile con le versioni upstream di FSF 4.6.x e quasi certamente con qualsiasi 4.6. x da qualsiasi altra distribuzione.

Su GNU / Linux le librerie di runtime di GCC usano il controllo delle versioni dei simboli ELF quindi è facile controllare le versioni dei simboli necessarie per oggetti e librerie, e se hai un libstdc++.soche fornisce quei simboli funzionerà, non importa se è una versione con patch leggermente diversa da un'altra versione della tua distribuzione.

ma nessun codice C ++ (o qualsiasi codice che utilizza il supporto di runtime C ++) può essere collegato dinamicamente se questo deve funzionare.

Anche questo non è vero.

Detto questo, il collegamento statico a libstdc++.aè un'opzione per te.

Il motivo per cui potrebbe non funzionare se carichi dinamicamente una libreria (usando dlopen) è che i simboli libstdc ++ da cui dipende potrebbero non essere stati necessari all'applicazione quando l'hai (staticamente) collegata, quindi quei simboli non saranno presenti nel tuo eseguibile. Ciò può essere risolto collegando dinamicamente la libreria condivisa a libstdc++.so(che è la cosa giusta da fare comunque se dipende da essa.) L'interposizione di simboli ELF significa che i simboli presenti nel tuo eseguibile verranno utilizzati dalla libreria condivisa, ma altri no presente nel tuo eseguibile si troverà in quello a cui libstdc++.sosi collega. Se la tua applicazione non usa, dlopennon devi preoccupartene.

Un'altra opzione (e quella che preferisco) è quella di distribuire il più recente libstdc++.soinsieme alla tua applicazione e assicurarti che venga trovato prima del sistema predefinito libstdc++.so, cosa che può essere eseguita forzando il linker dinamico a guardare nel posto giusto, utilizzando $LD_LIBRARY_PATHla variabile di ambiente in run- time, o impostando un RPATHnell'eseguibile al momento del collegamento. Preferisco usare RPATHin quanto non si basa sull'ambiente impostato correttamente affinché l'applicazione funzioni. Se colleghi la tua applicazione con '-Wl,-rpath,$ORIGIN'(nota le virgolette singole per evitare che la shell tenti di espandersi $ORIGIN), l'eseguibile avrà una RPATHdelle $ORIGINquali dice al linker dinamico di cercare le librerie condivise nella stessa directory dell'eseguibile stesso. Se metti il ​​file più recentelibstdc++.sonella stessa directory dell'eseguibile verrà trovato in fase di esecuzione, problema risolto. (Un'altra opzione è inserire l'eseguibile /some/path/bin/e la più recente libstdc ++. Così dentro /some/path/lib/e collegarsi con '-Wl,-rpath,$ORIGIN/../lib'o qualsiasi altra posizione fissa relativa all'eseguibile e impostare l'RPATH relativo a $ORIGIN)

Un'aggiunta all'eccellente risposta di Jonathan Wakely, perché dlopen () è problematico:

A causa del nuovo pool di gestione delle eccezioni in GCC 5 (vedere PR 64535 e PR 65434 ), se si dlopen e dlclose una libreria che è staticamente collegata a libstdc ++, si verificherà ogni volta una perdita di memoria (dell'oggetto pool). Quindi, se c'è qualche possibilità che tu possa mai usare dlopen, sembra davvero una cattiva idea collegare staticamente libstdc ++. Si noti che questa è una perdita reale rispetto a quella benigna menzionata nel PR 65434 .

Add-on alla risposta di Jonathan Wakely riguardo all'RPATH:

RPATH funzionerà solo se l'RPATH in questione è l'RPATH dell'applicazione in esecuzione . Se si dispone di una libreria che si collega dinamicamente a qualsiasi libreria tramite il proprio RPATH, l'RPATH della libreria verrà sovrascritto dall'RPATH dell'applicazione che lo carica. Questo è un problema quando non puoi garantire che l'RPATH dell'applicazione sia lo stesso di quello della tua libreria, ad esempio se ti aspetti che le tue dipendenze siano in una particolare directory, ma quella directory non fa parte dell'RPATH dell'applicazione.

Ad esempio, supponiamo di avere un'applicazione App.exe che ha una dipendenza collegata dinamicamente da libstdc ++. So.x per GCC 4.9. L'App.exe ha questa dipendenza risolta tramite RPATH, cioè

App.exe (RPATH=.:./gcc4_9/libstdc++.so.x)

Supponiamo ora che esista un'altra libreria Dependency.so, che ha una dipendenza collegata dinamicamente da libstdc ++. So.y per GCC 5.5. La dipendenza qui viene risolta tramite l'RPATH della libreria, ad es

Dependency.so (RPATH=.:./gcc5_5/libstdc++.so.y)

Quando App.exe carica Dependency.so, non aggiunge né antepone l'RPATH della libreria . Non lo consulta affatto. L'unico RPATH considerato sarà quello dell'applicazione in esecuzione, o App.exe in questo esempio. Ciò significa che se la libreria si basa su simboli che si trovano in gcc5_5 / libstdc ++. So.y ma non in gcc4_9 / libstdc ++. So.x, la libreria non verrà caricata.

Questo è solo un avvertimento, poiché in passato mi sono imbattuto in questi problemi. RPATH è uno strumento molto utile ma la sua implementazione ha ancora alcuni trucchi.

Potrebbe anche essere necessario assicurarsi di non dipendere dalla glibc dinamica. Esegui lddsul tuo eseguibile risultante e nota eventuali dipendenze dinamiche (libc / libm / libpthread sono sospetti usuali).

Un esercizio aggiuntivo consisterebbe nella creazione di un gruppo di esempi C ++ 11 coinvolti utilizzando questa metodologia e provando effettivamente i binari risultanti su un vero sistema 10.04. Nella maggior parte dei casi, a meno che tu non faccia qualcosa di strano con il caricamento dinamico, saprai subito se il programma funziona o si blocca.

Vorrei aggiungere alla risposta di Jonathan Wakely quanto segue.

Giocando -static-libstdc++su Linux, ho affrontato il problema con dlclose(). Supponiamo di avere un'applicazione "A" collegata staticamente libstdc++e che venga caricata dinamicamente collegata al libstdc++plug-in "P" in fase di esecuzione. Va bene. Ma quando "A" scarica "P", si verifica un errore di segmentazione. La mia ipotesi è che dopo lo scaricamento libstdc++.so, "A" non possa più utilizzare i simboli relativi a libstdc++. Si noti che se sia "A" che "P" sono collegati staticamente a libstdc++, o se "A" è collegato dinamicamente e "P" staticamente, il problema non si verifica.

Riepilogo: se la tua applicazione carica / scarica plug-in che possono collegarsi dinamicamente libstdc++, l'app deve anche essere collegata dinamicamente ad essa. Questa è solo una mia osservazione e mi piacerebbe ricevere i tuoi commenti.