[Static and Shared Library] - Static / Shared Library 비교

[Static Library의 장점]

 

• 정적 라이브러리는 사용하기 쉽다.
• 실행 파일은 관련 외부 구성 요소(공유 라이브러리)에 의존하지 않는다. 실행 파일에는 필요한 모든 것이 포함되어 있다.
• 정적 라이브러리에는 환경적 또는 관리적 문제가 없다.
• 정적 라이브러리 코드는 위치 독립적인 코드일 필요가 없다.

[Static Linking의 용이성]

• Static Library로 테스트 하다가 Shared Library로 변경할 수 있다.

 

[Static Linking의 독립성]

• executable file에 필요한 것이 모두 포함되어 있다.

 

[간편한 설치]

• LD_LIBRARY_PATH에 경로를 지정을 할 필요가 없다.
• 공유 라이브러리를 제공하지 않는 플랫폼에서 Static Linking이 중요하다.

 

========================================================================================

 

[Shared Library 장점]

• 코드 공유는 시스템 리소스를 절약한다.
• 공통 공유 라이브러리에 의존하는 여러 프로그램은 공통 공유 라이브러리를 교체하여 한 번에 수정할 수 있다.
• 대체 공유 라이브러리를 사용하도록 환경을 수정할 수 있다.
• 링크 타임에 사전 정렬 없이 동적 라이브러리를 로드하도록 프로그램을 작성할 수 있다. 
• 대규모 라이브러리에서 메모리 절약 효과가 크다.

 

[중앙 집중식 코드 선호]

• 여러 실행 파일에서 프로덕션 수준 코드를 실행 중이고 이들이 사용하는 공통 공유 라이브러리에서 버그를 발견한 경우 해당 라이브러리를 수정하면 해당 라이브러리를 사용하는 모든 프로그램이 즉시 수정된다. 
• 해당 공통 공유 라이브러리를 사용하는 실행 파일은 다시 컴파일하거나 다시 연결할 필요가 없다.

 

[중앙 집중식 코드를 권장하지 않음]

• 동시에 프로덕션 수준 실행 프로그램의 작업 집합은 공통 공유 라이브러리의 단일 변경으로 중단될 수 있다. 
• 구조, 클래스 정의 및 매크로를 변경하는 파일을 포함하는 변경 사항에 특히 주의해야한다.
• 공유 라이브러리를 호출하는 기존 프로그램은 구조 및 클래스 내에서 올바른 멤버 오프셋을 참조하기 위해 다시 컴파일해야 할 수 있다.

 

[공유 라이브러리 리디렉션]

• 공유 라이브러리를 사용하면 LD_LIBRARY_PATH 변수를 변경하여 프로그램에서 사용하는 라이브러리를 제어할 수 있다. 
• 이를 통해 실행 파일을 다시 컴파일하고 연결하지 않고도 라이브러리를 대체할 수 있다. 
• 예를 들어, 품질 보증 테스트를 위해 다른 버전의 공유 라이브러리를 시도할 수 있다. 이러한 유형의 대체는 정적 라이브러리를 사용하는 경우 실행 파일을 다시 연결해야 한다.

 

 

[런타임에 동적으로 연결]

• 이것은 단순히 정적 라이브러리로 할 수 없다. 
• 프로그램은 공유 라이브러리 파일 이름과 함수 진입점 이름을 나타낼 수 있으며 동적 로더는 공유 라이브러리 모듈을 로드하고 제어를 전달한다. 이렇게 하면 프로그램이 사전 조정 없이 라이브러리 모듈을 호출할 수 있다.