System Software and Program Execution(2)

Library

 

- Standard library header files

• <...>          /usr/include
• <sys/...>   /usr/include/sys

- 헤더 파일에는 라이브러리 함수의 선언만 있고, 실제 함수의 정의는 라이브러리 파일에 있는 것이 일반적

---

Compile & Linking

프로그램에 존재하는 모든 변수 및 함수의 정의가

1. 직접 작성한 소스 파일에 존재하거나(.o)
2. 직접 작성하지 않았지만 include 시킨 라이브러리 파일에 존재한다면(.a)

실행 파일을 생성할 수 있다.

---

Static Linking vs. Dynamic Linking

 

Static Linking

- 라이브러리가 프로그램의 실행 파일 코드에 포함(static library)
- 실행 파일의 크기가 커짐

- 동일한 라이브러리를 여러 프로그램이 각각 사용할 때, 각각의 프로세스가 해당 라이브러리를 메모리에 올리므로 메모리 낭비(ex: printf 함수의 라이브러리 코드)

 

Dynamic Linking

- 라이브러리가 실행 시 link됨(shared library)
- 실행 파일에는 라이브러리의 위치를 찾기 위한 간단한 코드만 표시됨(라이브러리 코드 자체가 포함되는 것 X) → 프로그램 실행 중 해당 함수가 호출된다면 그때 link가 이루어짐(=라이브러리 파일의 위치를 찾아 메모리에 올림)

- 라이브러리가 이미 메모리에 올라와 있으면(=다른 프로세스에 의해 사용된 적이 있으면) 해당 루틴의 주소로(→share), 없으면 디스크에서 읽어 옴

Static Library

- 함수들이 link time 중에 .out 파일으로 복사

- binding: compile time

 

Shared Library

- 함수들이 link time 중에 복사되지 않는다(just mapped-위치 정보만 실행 파일 내에 적어 놓음)

- 실행 도중에 함수가 호출된다면 해당 함수가 포함된 라이브러리에서 읽어 옴→필요에 따라 그때그때 load

- binding: loading or run time

binding: 라이브러리가 그 프로그램에 "달라붙는" 것
static library의 경우 link time(compile time)에, shared library는 run time(프로그램 실행 중)에 binding 발생

- static library는 실행 파일이 만들어질 때 각각의 파일마다 그 라이브러리의 코드가 들어가 있음→실행시키면 메모리에 올라가서 실행

- 동일한 라이브러리 함수일지라도 프로세스마다 각각 존재

 

- shared library는 라이브러리 함수가 실행 파일 내에 포함되지 않고 별도의 파일 형태로 존재

- 프로그램을 실행시키면 라이브러리 함수를 "사용하는 순간에" 해당 함수를 load하여 사용

- 동일한 라이브러리 함수가 하나만 존재하고 프로세스들이 이를 공유

---

Advantages & Disadvantages of Shared Library

 

Advantage

- 여러 프로세스들이 하나의 라이브러리 함수를 공유하여 메모리 공간 낭비가 적다.

(↔ static library는 동일한 함수 코드를 프로세스마다 포함시켜야 하므로 공간이 낭비됨)

 

Disadvantage

- 사용된 함수의 라이브러리를 가지고 있지 않은 상대에게 .out 파일을 줄 수 없다(라이브러리가 있는지, 있다면 동일한 버전인지 등 모두 고려해야 함).

- 느린 속도(run-time에 bind & load가 일어나므로)

- heavy overhead in initial bookkeeping during gcc(추가적인 라이브러리 정보를 기록해 둬야(버전, 위치, etc. 함수를 찾으러 갈 수 있음)