Il meccanismo che tendono ad utilizzare una combinazione di readelf -V
per scaricare le informazioni .gnu.version
da libstdC++ e quindi una tabella di ricerca che corrisponde al valore GLIBCXX_
più grande estratto.
readelf -sV /usr/lib/libstdc++.so.6 | sed -n 's/.*@@GLIBCXX_//p' | sort -u -V | tail -1
se la versione di sort
è troppo vecchio per avere la possibilità -V
(che ordina in base al numero di versione) quindi è possibile utilizzare:
tr '.' ' ' | sort -nu -t ' ' -k 1 -k 2 -k 3 -k 4 | tr ' ' '.'
al posto del sort -u -V
, per ordinare per fino a 4 cifre della versione.
In generale, la corrispondenza della versione ABI dovrebbe essere sufficiente.
Se si sta cercando di rintracciare il libstdc++.so.<VERSION>
, però, si può usare un po 'come bash:
file=/usr/lib/libstdc++.so.6
while [ -h $file ]; do file=$(ls -l $file | sed -n 's/.*-> //p'); done
echo ${file#*.so.}
così per il mio sistema di questo prodotto 6.0.10
.
Se, tuttavia, si sta tentando di ottenere un file binario compilato su systemX per funzionare su systemY, allora questo tipo di cose ti porterà solo lontano. In questi casi, portando con sé una copia del libstdC++ in modo che è stato utilizzato per l'applicazione, e poi avere uno script percorso che fa un:.
export LD_LIBRARY_PATH=<directory of stashed libstdc++.so>
exec application.bin "[email protected]"
lavora generalmente intorno alla questione del .so che si trova sul casella incompatibile con la versione dell'applicazione. Per le differenze più estreme in ambiente, tendo ad aggiungere tutte le librerie dipendenti finché l'applicazione non funziona correttamente. Questo è l'equivalente di Linux di aggirare ciò che, per Windows, sarebbe considerato dll hell.
I datestamps sono quasi del tutto inutile, non so il motivo per cui loro o documentazione preoccuparci di mantenere loro. Ad esempio, la data per GCC 4.6.3 è successiva alla 4.7.0, ma 4.7.0 ha più funzionalità, quindi quale uso è conoscere la data di rilascio? –