문제

G ++ 버전 4.2.3을 사용하여 동일한 GNU/Linux 서버에서 2 개의 다른 바이너리를 컴파일했습니다.

첫 번째는 다음을 사용합니다.

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

두 번째는 다음을 사용합니다.

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

두 번째 바이너리가 glibcxx_3.4.9를 사용하는 이유는 libstdc ++에서만 사용할 수 있습니다. So.6.0.9 및 ~ 아니다 libstdc ++에서. So.6.0.8

G ++에서 생성 된 새로운 기능은 무엇입니까?

glibcxx_3.4.9가 필요하지 않도록이 새로운 기능을 비활성화하는 방법이 있습니까?

도움이 되었습니까?

해결책

나열된 glibcxx_3.4.9 기호 중 어느 것이 실제로 이진에 의존하는지 알아 보려면 다음을 수행하십시오.

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

어떤 기호를 찾아야하는지 알면 필요한 객체로 다시 추적 할 수 있습니다.

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

마지막으로, 이것을 소스에 묶으려면 다음을 수행 할 수 있습니다.

objdump -dS foo.o

3.4.9 기호를 참조하는 코드를 확인하십시오.

다른 팁

당신이 그것을 요청했기 때문에, 다음은 적어도 ABI 버전 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;

파일을 실행하십시오 libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt C ++ Filt를 통해 Glibcxx_3.4.9에 대한 그레핑을 통해 그 이름을 이해합니다 (와일드 카드처럼 보입니다). 그 이름이 꽤 길고 중첩되어 있기 때문에 나는 그것을하지 않았다. 나중에 버전에는 주로 C ++ 1X 물건이 포함됩니다. 파일을 참조하십시오 libstdc++-v3/config/abi/pre/gnu.ver 위의 경우. 읽다 여기 버전 링커 스크립트 명령에 대해

첫 번째 질문은 위의 목록을 어떻게 생성했는지입니다.
컴파일러가 결정적이라고 가정하므로 바이너리를 같은 방식으로 연결한다고 가정합니다.

나는 질문에 직접 대답하지 않은 것에 대해 표시를했다고 생각하지만 의견은 좋을 것입니다. 그러나 나는 여전히 당신이 올바른 정보를 제공하지 않았다고 생각하며 문제를 보여주는 명령의 출력을 보는 것이 좋을 것입니다.

LDD를 사용했다고 가정합니다.
당신은 다음과 같은 것처럼 보이는 출력을 얻을 것입니다.

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

그러나 이것은 이야기의 끝이 아닙니다.
파일에서 ls를 시도하는 것은 상징적 링크 일 수 있습니다.

> ls /usr/lilb/lib<X>.so.<verM>
lrwxrwxrwx 1 root root    <Date>  /usr/lib/lib<X>.so.<verM>  -> lib<X>.so.<verM>.<verm>.<verp>
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top