2014-09-22 11 views
0

에 따라 나는 libgcc_s.so.1 2 버전 2 개 폴더를 만들어 그리고 LDD에 따라 라이브러리 선택을 찾았 :

> file {A,B}/libgcc_s.so.1 
A/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped 
B/libgcc_s.so.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped 

> LD_LIBRARY_PATH=A:B ldd MyProgram | grep libgcc_s.so.1 
libgcc_s.so.1 => B/libgcc_s.so.1 

MyProgram 사용하지 않는 이유 A/libgcc_s.so.1? 그것이 아키텍처의 문제이지만 A/libgcc_s.so.1이 어떻게 무효로 간주되는지 그리고 수동으로 어떻게 테스트 할 수 있습니까?

답변

0

ELF header's 제 3 필드는 amd64 (x86_64)에 62, i386 (80386)에 3을 갖는 "machine"입니다. 물론 로더는이 필드를 검사하여 주어진 라이브러리를 사용할 수 있는지 여부를 결정하고 그렇지 않은 경우 검색 목록의 다음 경로로 계속 진행합니다.

+0

그래도 라이브러리가 현재 아키텍처를 준수하는지 어떻게 확인할 수 있습니까? ELF의 18-19 바이트를 얻을 수는 있지만,이 코드가 실제 아키텍처와 호환되는지를 어떻게 판단 할 지 모르겠습니다. [[$ (readelf -h | grep $ (Machine :)) == \ * (uname -i) \ *]]하는 것이 안전합니까? – Alcolo47

+0

상위 레벨에서 달성하려는 실제 목표는 무엇입니까? –

+0

다른 아키텍처에 대해 서로 다른 라이브러리가 포함 된 다른 플랫폼간에 폴더를 공유했습니다. 내 실제 LD_LIBRARY_PATH에 모두 포함됩니다. 명명 규칙을 사용하지 않고 아키텍처에 따라 유용한 폴더만으로 축소하려고합니다. – Alcolo47