내가 기호 from_a를 내보내는 ELF 공유 라이브러리 liba.so을 가지고 있다고 생각해 보자. from_a의 구현은 공유 라이브러리 libb.so에서 내 보낸 된 기호 from_b의 용어로 정의하고, liba.so는 libb.so의 DT_NEEDED 엔트리를 가지고있다.ELF 링커가 간접적 인 종속성을 찾기 위해 어떤 보증을 제공합니까?
지금은 기호 from_a를 사용 program을 보유하고 있습니다. 내가 program를 연결할 때, 나는 함께 링커가 liba.so를 찾기위한 검색 경로가있는 경우, 필요 어떤 링크 시간, 링크 라인에 -la을 포함한다. libb.so의 기호에 대한 직접적인 종속성은 program입니다.
첫 번째 질문 : 그것은 보장 내가 program에 대한 링크 라인에 liba.so의 (이 경우 libb.so에서) 간접 종속성을 나열 할 필요가 없습니다 (시스템을 사용하는 모든 비 깨진 ELF에 이식의 의미에서)? 나는 이것이 사실이라고 믿지만 나는 확인하고 싶다. 링커의 이러한 동작은 사양에 따라 위임됩니까? 는 1 개 (ELF 사양?) 그렇다면
가 두 번째 질문 : liba.so와 libb.so 비표준 위치에 설치하는 경우 (를/usr/lib 디렉토리를 반대로 말하자면 $ HOME/lib 디렉토리가) 검색 기본되지 않도록 program를 링크 할 때, 다음, 적어도 내 현재의 시스템과 내가 테스트 한 몇 사람에 BFD 링커는 -L로 지정 라이브러리 디렉토리를 설치하는 것이 사실에도 불구하고, libb.so을 찾을 수 없다는 불평하고, 사용 제안합니다 -rpath 또는 -rpath-link. 그러나 설치 위치를 식별하는 RPATH 또는 RUNPATH가 liba.so에 설정된 경우 BFD 링커는 placated됩니다. program에 직접적인 종속성이없는 경우 BFD 링커가 링크 시간에 libb.so을 찾을 수 있는지 여부를 신경 쓰는 이유는 무엇입니까? liba.so에 RPATH를 설정하여 얻은 동작이 보장됩니까? 그것은 링커를 placate 위해이 의존하는 것이 좋을 것입니다. 나는 또한 황금 링커가 이 아니고이 아님을 발견했다. 여기서 의도 한 행동은 무엇입니까? 위에서 언급 한 테스트를 기반으로
역사적인 이유로,이 동작에 대한 테스트를 작성했음을 유의할 것입니다. Lucid, Precise 및 Raring에서 작동하는 것으로 보입니다. https://github.com/acmorrow/solib-rpath-test에서 테스트 사본을 얻을 수 있습니다. 나는 그것이 미래에 누군가를 돕기를 바랍니다. – acm