2010-03-29 5 views
5

다음 두 가지 방법 (gcc 또는 gcc 일 수 있음)에서 gcc/g ++에 라이브러리 (공유 및 정적 모두)를 지정하는 데 상당한 차이가 있는지 궁금 할 것입니다.gcc/g ++에 라이브러리를 지정하는 다른 방법

CC -o output_executable /path/to/my/libstatic.a /path/to/my/libshared.so source1.cpp source2.cpp ... sourceN.cpp 

CC -o output_executable -L/path/to/my/libs -lstatic -lshared source1.cpp source2.cpp ... sourceN.cpp 
뭔가

난 단지 직접 완전 지정된 라이브러리의 이름을 전달하는 정적 또는 동적 버전을 선택에 더 큰 제어 할 것 인 큰 차이를 볼 수 있지만, 나는 의심있다 그 밖의 일은 execu가 어떻게 수행되는지에 부작용을 줄 수 있습니다. 테이블이 작성되었거나 런타임에 작동합니다. 맞습니까?

안드레아.

+0

결과 파일을 비교해 보았습니까? – Ernelli

+0

아닙니다. 이 – abigagli

답변

5

좋아, 나 자신이 어떤 실험을 근거로 응답하고 GCC 문서의 깊은 독서 할 수 GCC 문서에서

: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

는 [...] 링커는 스캔하여 아카이브 파일을 처리 지금까지는 참조되었지만 정의되지 않은 기호를 정의하는 구성원에 대해이를 통해. 그러나 발견 된 파일이 일반 오브젝트 파일 인 경우, 이는 일반적인 방식으로 링크됩니다. -l 옵션을 사용하고 파일 이름을 지정 사이의 유일한 차이는 -l이 실제로 직접 지정하는 제 3 옵션에 대해 관련 의혹에도 답변을 여러 디렉토리

lib' and .A와 라이브러리를 둘러싸고 '와 검색이다 gcc 명령 줄의 오브젝트 파일 (즉,이 경우 오브젝트 파일의 모든 코드는 아카이브를 사용하는 동안 최종 실행 파일의 일부가되며 실제로 필요한 오브젝트 파일 만 가져옵니다).

+0

에 대한 "공식적인"정보가 .so에 대한 전체 경로를 사용할 때 - 다른 환경에서 런타임 중에 어떤 일이 발생 하는지를보고 싶지만 다음 시험이 될 수 있습니까? .so가 어떻게 룩업되고 있습니까? 라이브러리로 전체 문자열을 검색하는 것 같습니다. 따라서 대상 환경의 원래 정확한 위치에 존재하지 않는다면 찾을 수 없습니다 ..이를 극복하는 방법은 무엇입니까? –

+1

일반적으로 .so가 "soname"(즉, 메이저 버전 번호가 추가 된 라이브러리 이름)을 가진 경우 "soname"이 실행 파일의 종속물로 등록됩니다. 그런 다음 실행 파일을 시작할 때 런타임 링커 (일반적으로 /lib/ld-linux.so.X on linux)는 다양한 위치 (플랫폼, LD_LIBRARY_PATH 환경 변수 및 잠재적으로 빌드 중에 사용 된 rpath 인수)에 따라 soname (보통 파일 시스템에는 실제 이름에 대한 심볼릭 링크). http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html – abigagli

+0

감사합니다. 몇 시간 전에 나 자신과 rpath 자신을 발견 :) –

관련 문제