Co dělat g ++ patří GLIBCXX_3.4.9?

hlasů
4

Zpracovala jsem 2 různé binární soubory na stejném serveru GNU / Linux pomocí g ++ verze 4.2.3.

První z nich používá:

GLIBC_2.0
GLIBC_2.2
GLIBC_2.1
GLIBCXX_3.4
GLIBC_2.1.3

Druhá používá:

GLIBC_2.0
GLIBC_2.2
GLIBC_2.1
GLIBCXX_3.4.9
GLIBCXX_3.4
GLIBC_2.1.3

Proto druhý binární používá GLIBCXX_3.4.9, která je k dispozici pouze v libstdc ++. So.6.0.9 a nikoli v libstdc ++. So.6.0.8

Jaká je nová funkce generované g ++, která vyžaduje, aby přestávku ABI a přinutit systém mít GLIBCXX_3.4.9?

Existuje způsob, jak zakázat tuto novou funkci nevyžadují GLIBCXX_3.4.9?

Položena 07/01/2009 v 18:51
zdroj uživatelem
V jiných jazycích...                            


3 odpovědí

hlasů
8

Chcete-li zjistit, který ze symbolu uvedena GLIBCXX_3.4.9 (y) Váš binární skutečně závisí na, postupujte takto:

readelf -s ./a.out | grep 'GLIBCXX_3\.4\.9' | c++filt

Jakmile budete vědět, jaké symboly hledat, můžete vystopovat k objektu, který je potřebuje:

nm -A *.o | grep _ZN<whatever>

A konečně, aby tie to zpět ke zdroji, můžete tak učinit:

objdump -dS foo.o

a zjistit, které kód je odkazem na symbol (y) 3.4.9.

Odpovězeno 08/01/2009 v 05:58
zdroj uživatelem

hlasů
3

Vzhledem k tomu, budete požádáni o to, zde jsou symboly, které mají alespoň ABI verzi 3.4.9:

GLIBCXX_3.4.9 {

    _ZNSt6__norm15_List_node_base4hook*;
    _ZNSt6__norm15_List_node_base4swap*;
    _ZNSt6__norm15_List_node_base6unhookEv;
    _ZNSt6__norm15_List_node_base7reverseEv;
    _ZNSt6__norm15_List_node_base8transfer*;

    _ZNSo9_M_insertI[^g]*;
    _ZNSt13basic_ostreamIwSt11char_traitsIwEE9_M_insertI[^g]*;
    _ZNSi10_M_extractI[^g]*;
    _ZNSt13basic_istreamIwSt11char_traitsIwEE10_M_extractI[^g]*;

    _ZSt21__copy_streambufs_eofI[cw]St11char_traitsI[cw]EE[il]PSt15basic_streambuf*;

    _ZSt16__ostream_insert*;

    _ZN11__gnu_debug19_Safe_sequence_base12_M_get_mutexEv;
    _ZN11__gnu_debug19_Safe_iterator_base16_M_attach_singleEPNS_19_Safe_sequence_baseEb;
    _ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv;
    _ZN11__gnu_debug19_Safe_iterator_base12_M_get_mutexEv;

    _ZNKSt9bad_alloc4whatEv;
    _ZNKSt8bad_cast4whatEv;
    _ZNKSt10bad_typeid4whatEv;
    _ZNKSt13bad_exception4whatEv;

} GLIBCXX_3.4.8;

Spusťte soubor libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txtpomocí C ++ filt, grep pro GLIBCXX_3.4.9 smysl těchto jmen (vypadají jako zástupné znaky pouze). Neudělal jsem to proto, že tyto názvy se docela dlouho a vnořené. Pozdější verze většinou patří C ++ 1x věci. Viz soubor libstdc++-v3/config/abi/pre/gnu.verpro výše uvedené. Přečtěte si zde o příkazu VERZE linker skriptu.

Odpovězeno 07/01/2009 v 20:15
zdroj uživatelem

hlasů
0

No první otázka je, jak jste generovat výše uvedený seznam.
Dalo by se předpokládat, že kompilátor je deterministické a tím odkazů binární soubory stejným způsobem.

Předpokládám, že jsem byl označen po dobu ne přímo odpovědět na otázku, ale komentář by bylo hezké. Ale stále si myslím, jste zadali správné informace, a že by bylo hezké vidět výstup příkazu, který ukazuje váš problém.

Za předpokladu, že jste použili ldd:
Ty by si výstup, který vypadal takto:

lib<X>.so.<ver>  =>  /usr/lib/lib<X>.so.<verM>  (<Addr>)

Ale to není konec příběhu.
Snaží dělá ls k souboru může být symbolický link

> ls /usr/lilb/lib<X>.so.<verM>
lrwxrwxrwx 1 root root    <Date>  /usr/lib/lib<X>.so.<verM>  -> lib<X>.so.<verM>.<verm>.<verp>
Odpovězeno 07/01/2009 v 19:24
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more