정적 라이브러리와 공유 라이브러리의 차이점

정적 라이브러리와 공유 라이브러리의 차이점

정적 라이브러리와 공유 라이브러리의 차이점은 무엇입니까?

Eclipse를 사용하고 있는데 정적 라이브러리 및 공유 라이브러리 등 여러 프로젝트 유형이 있습니다.어느 쪽이 다른 쪽보다 유리합니까?

공유 라이브러리는 .so 파일(또는 Windows .dll 파일 또는 OS X .dylib 파일)입니다.라이브러리와 관련된 모든 코드는 이 파일에 있으며 런타임에 이를 사용하는 프로그램에 의해 참조됩니다.공유 라이브러리를 사용하는 프로그램은 공유 라이브러리에서 사용하는 코드만 참조합니다.

스태틱 라이브러리는 .a(또는 Windows .lib) 파일입니다.라이브러리와 관련된 모든 코드는 이 파일에 있으며 컴파일 시 프로그램에 직접 링크됩니다.정적 라이브러리를 사용하는 프로그램은 정적 라이브러리에서 사용하는 코드의 복사본을 가져와 프로그램의 일부로 만듭니다.[Windows에는 .dll 파일을 참조하기 위해 사용되는 .lib 파일도 있지만 처음과 동일하게 작동합니다.]

각 방법에는 장점과 단점이 있습니다.

• 공유 라이브러리는 라이브러리를 사용하는 각 프로그램에서 중복되는 코드의 양을 줄여 바이너리를 작게 유지합니다.또한 공유 객체를 기능적으로는 동일하지만 이를 사용하는 프로그램을 다시 컴파일할 필요 없이 성능상의 이점을 추가할 수도 있습니다.그러나 공유 라이브러리는 기능 실행에 약간의 추가 비용과 함께 라이브러리 내의 모든 심볼을 사용하는 것에 연결해야 하므로 런타임 로딩 비용이 발생합니다.또한 공유 라이브러리는 런타임에 애플리케이션에 로드할 수 있습니다.이것은 바이너리 플러그인 시스템을 구현하기 위한 일반적인 메커니즘입니다.

• 정적 라이브러리는 바이너리의 전체 크기를 증가시키지만 사용 중인 라이브러리의 복사본을 가지고 다닐 필요는 없습니다.코드는 컴파일 시 연결되므로 추가 런타임 로드 비용이 발생하지 않습니다.그 암호는 그냥 거기에 있다.

개인적으로는 공유 라이브러리를 선호하지만 C++ 표준 라이브러리의 특정 버전이나 Boost C++ 라이브러리의 특정 버전 등 바이너리가 충족하기 어려운 외부 종속성을 많이 갖지 않도록 해야 할 때는 정적 라이브러리를 사용하십시오.

정적 도서관은 서점과 같고 공유 도서관은...도서관전자의 경우, 자신의 서적/기능의 카피를 집에 가지고 갈 수 있습니다.후자의 경우, 당신과 다른 모든 사람이 같은 서적/기능을 사용하기 위해 도서관에 갑니다.따라서 (공유) 라이브러리를 사용하고자 하는 모든 사용자는 도서/기능을 "구입"해야 하기 때문에 라이브러리의 위치를 알아야 합니다.정적 라이브러리에서는 책/기능을 소유할 수 있으며, 집/프로그램에 보관하고 있으면 언제 어디서 구했는지는 상관없습니다.

심플화:

• 정적 링크: 대용량 실행 파일 1개
• 동적 링크: 작은 실행 파일과 하나 이상의 라이브러리 파일(Windows, Linux, MacOS의 .dylib)

정적 라이브러리의 경우 링커에 의해 라이브러리에서 코드가 추출되어 응용 프로그램을 컴파일/빌드하는 시점에서 최종 실행 파일을 빌드하는 데 사용됩니다.실행 시 최종 실행 파일은 라이브러리에 종속되지 않습니다.

공유 라이브러리의 경우, 컴파일러/링커는 애플리케이션이 빌드될 때 링크된 이름이 라이브러리에 존재하는지 확인하지만, 해당 코드는 애플리케이션으로 이동하지 않습니다.실행 시 공유 라이브러리를 사용할 수 있어야 합니다.

C 프로그래밍 언어 자체에는 정적 라이브러리 또는 공유 라이브러리의 개념이 없습니다.이것은 완전한 구현 기능입니다.

개인적으로 정적 라이브러리를 사용하면 소프트웨어 배포가 간단해지기 때문에 저는 정적 라이브러리를 사용하는 것이 훨씬 선호합니다.그러나 이것은 과거에 많은 피를 흘린 것에 대한 의견이다.

공유 라이브러리의 가장 큰 장점은 라이브러리를 사용하는 프로세스의 수에 관계없이 메모리에 로드된 코드의 복사본이 1개뿐이라는 것입니다.정적 라이브러리의 경우 각 프로세스가 자체 코드 복사본을 가져옵니다.이로 인해, 메모리 용량이 큰폭으로 삭감될 가능성이 있습니다.

OTOH의 장점은 모든 것이 애플리케이션에 번들된다는 것입니다.따라서 클라이언트가 시스템에서 올바른 라이브러리(및 버전)를 사용할 수 있는지 걱정할 필요가 없습니다.

정적 라이브러리는 응용 프로그램의 일부로 컴파일되지만 공유 라이브러리는 그렇지 않습니다.공유 라이브러리에 의존하는 애플리케이션을 배포할 때는 MS Windows의 dll과 같은 라이브러리를 설치해야 합니다.

정적 라이브러리의 장점은 응용 프로그램을 실행하는 사용자에게 필요한 종속성이 없다는 것입니다. 예를 들어 DLL을 업그레이드할 필요가 없습니다.단점은 필요한 모든 라이브러리와 함께 출하되기 때문에 응용 프로그램의 크기가 더 크다는 것입니다.

공유 라이브러리는 소규모 애플리케이션으로 이어질 뿐만 아니라 사용자에게 애플리케이션의 일부인 라이브러리에 의존하지 않고 아마도 더 나은 버전의 라이브러리를 사용할 수 있는 기능을 제공합니다.

+---------------+---------------------------+------------------------------+
| properties    | Static library            | Shared library               |
+===============+===========================+==============================+
| Linking time  | It happens as the         | Shared libraries             |
|               | last step of the          | are added during             |
|               | compilation process.      | linking process              |
|               | After the program         | when executable              |
|               | is placed                 | file and libraries           |
|               | in the memory             | are added to the memory.     |
+---------------+---------------------------+------------------------------+
| Means         | Performed by linkers      | Performed by operating System|
+---------------+---------------------------+------------------------------+
| Size          | Static libraries are      | Dynamic libraries are        |
|               | much bigger in size,      | much smaller, because        |
|               | because external          | there is only one copy       |
|               | programs are built        | of dynamic library           |
|               | in the executable file.   | that is kept in memory.      |
+---------------+---------------------------+------------------------------+
| External file | Executable file will      | In shared libraries,         |
| changes       | have to be recompiled     | no need to recompile         |
|               | if any changes were       | the executable.              |
|               | applied to external files.|                              |
+---------------+---------------------------+------------------------------+
| Time          | Takes longer to execute   | It is faster                 |
|               | because loading into the  | because shared               |
|               | memory happens every time | library code is              |
|               | while executing.          | already in the memory.       |
+---------------+---------------------------+------------------------------+
| Compatibility | Never has a compatibility | Programs are dependent       |
|               | issue,since all code is   | on having a compatible       |
|               | in one executable module. | library.Dependent program    |
|               |                           | will not work if library     |
|               |                           | gets removed from the system |
+---------------+---------------------------+------------------------------+

다른 모든 답변과 더불어 아직 언급되지 않은 한 가지는 디커플링입니다.

제가 취급하고 있는 실제 생산 코드에 대해 말씀드리겠습니다.

300개 이상의 프로젝트(visual studio 포함)로 구성된 매우 큰 소프트웨어는 대부분 static lib로 구축되며 마지막으로 모든 것이 하나의 거대한 실행 파일로 링크됩니다.결국 다음과 같은 문제가 발생합니다.

·링크 시간이 매우 길다.예를 들어 컴파일 시간이 10초 정도인 경우 링크 시간이 15분 이상 걸릴 수 있습니다.코드를 인스톨 할 필요가 있는 메모리 체크 툴 등, 큰 실행 파일을 가지고 있는 툴도 있습니다.당신은 바보로 여겨졌던 한계에 다다를지도 모른다.

보다 문제가 되는 것은 소프트웨어의 디커플링입니다.이 실제 예에서는 모든 프로젝트의 헤더 파일을 다른 프로젝트와 복구하는 것이 가능했습니다.그 결과, 한 개발자가 의존 관계를 추가하는 것은 매우 쉬웠습니다.끝에 있는 링크는 심볼을 모두 찾을 수 있기 때문에 헤더를 포함하기만 하면 됩니다.그것은 결국 끔찍한 사이클 의존과 완전한 난장판으로 끝나게 된다.

공유 라이브러리의 경우 개발자가 종속 라이브러리를 추가하기 위해 프로젝트 빌드 시스템을 편집해야 하기 때문에 약간의 추가 작업이 필요합니다.공유 라이브러리 코드가 더 깨끗한 코드 API를 제공하는 경향이 있다는 것을 알게 되었습니다.

-------------------------------------------------------------------------
|  +-  |    Shared(dynamic)       |   Static Library (Linkages)         |
-------------------------------------------------------------------------
|Pros: | less memory use          |   an executable, using own libraries|
|      |                          |     ,coming with the program,       |
|      |                          |   doesn't need to worry about its   |
|      |                          |   compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of       |   bigger memory uses                |
|      | libraries may be altered |                                     |
|      | subject to OS  and its   |                                     |
|      | version, which may affect|                                     |
|      | the compilebility and    |                                     |
|      | runnability of the code  |                                     |
-------------------------------------------------------------------------

언급URL : https://stackoverflow.com/questions/2649334/difference-between-static-and-shared-libraries