🐢 chap3. 목적 파일

⭐ 3.1 ABI

✅ ABI와 API란?

ABI : 응용프로그램 이진 인터페이스

API : 응용프로그램 인터페이스

API : 두 소프트웨어 컴포넌트가 서로를 사용하거나 서로 기능을 제공할 때 수용하는 규칙이나 표준

    ( 운영체제와 응용프로그램 사이의 통신에 사용되는 언어나 메시지 형식)

라이브러리를 사용하기 위기위해서는 API를 사용해야 한다!

라이브러리 API 수정 시 코드 역시 새 API에 맞추어야 한다!

✅ ABI와 API의 차이점

ABI와 API는 수준(level)이 다르다.

• API : 두 소프트웨어의 컴포넌트 간 호환성을 보장하여 기능적으로 계속 협력할 수 있도록 한다.
• ABI : 두 프로그램이 기계 수준의 명령어 수준에서 호환 가능하도록 두 프로그램 목적 파일을 함께 사용할 수 있게 한다.

→ 프로그램은 서로 다른 ABI를 갖는 동적/정적 라이브러리를 사용할 수 없다!

✅ ABI가 포함하는 내용

• 대상 아키텍처의 명령어 집합 :프로세서 명령어, 메모리 레이아웃, 엔디언 endianness, 레지스터 등
• 기존의 자료형과 크기 및 정렬 규칙 alignment policy-
• 함수 호출 규칙 convention : 함수가 호출되는 방식. 예를 들어 스택 프레임의 구조나, 인자의 순서를 푸시 push하는 문제가 함수 호출 방식과 관련이 있습니다.

● 유닉스 계열 시스템에서 시스템 호출 방식 정의

● 사용된 목적 파일 형식: 재배치 가능한 실행 가능한, 공유 목적 파일에 관한 내용(다음 절에서 설명 합니다)

• C++ 컴파일러로 생성한 목적 파일의 네임 맹글링, 가상 테이블 virtual table 레이아웃

System V ABI는 리눅스나 BSD 시스템과 같은 유닉스 계열 시스템에서 가장 널리 사용되는 ABI 표준

실행 가능한 링크 파일 형식 executable and linking format (ELF)은 System V ABI에서 사용되는 표준 목적 파일 형식

⭐ 3.2 목적 파일 형식

✅ 목적파일

플랫폼에서 목적 파일에는 기계 수준의 명령어를 저장하는 목적 파일만의 특정 파일 형식이 존재

다양한 운영체제에서 사용되는 널리 알려진 목적 파일 형식 예시

• 리눅스와 다른 유닉스 계열 운영체제에서 사용되는 ELF
• OS X(macOS 및 iOS)에서 사용되는 Mach-0
• 마이크로소프트 윈도우에서 사용되는 PE

✅ a.out 목적파일

• 현존하는 모든 목적 파일 형식은 예전의 a.out 목적 파일 형식을 계승한다.
• 이 파일 형식은 유닉스의 초기 버전을 위해 설계되었다.
• a.out은 어셈블러 출력 결과 assembler output을 나타낸다.
• 오늘날에는 이 파일 형식은 구식이지만, 이 이름은 대부분의 링커가 생성하는 실행 파일의 기본 이름으로 여전히 사용된다.

✅ COFF 목적파일

• a.out 형식은 곧 COFF Common Object File Format (공용 목적 파일 형식)로 대체되었다.
• COFF는 ELF의 토대가 되었다(ELF는 대부분의 유닉스 계열 시스템에서 사용하는 목적 파일 형식)
• 애플은 a.out을 OS/X에서 Mach-O로 바꾸었다.
• 윈도우는 목적파일의 형식으로 이식 가능한 실행 파일(PE)을 사용하며 COFF를 기반으로 한다.
• 오늘날의 모든 주요 목적 파일 형식은 역사적인 목적 파일 형식인 a.out과 COFF를 기반으로하며 여러 면에서 같은 조상을 공유한다.

✅ ELF 목적파일

• ELF는 리눅스와 대부분의 유닉스 계열 운영체제에서 사용되는 목적 파일 형식.
• ELF는 System V ABI에서 사용되는 목적 파일 형식
• 오늘날에는 운영체제가 사용하는 목적 파일 형식으로 널리 받아들여지고 있다.

ELF는 운영체제에 포함되는 표준 이진 파일 형식이다. 하지만 아래 4개에 국한되지는 않는다.

• 리눅스
• FreeBSD
• NetBSD
• Solaris

ELF의 기반 아키텍처가 같다면, 이러한 한 운영체제에서 생성된 ELF 목적 파일은 다른 운영체제에서도 실행하거나 사용할 수 있다. ELF는 다른 모든 파일 형식과 마찬가지로 어떤 구조를 갖는데, 다음 절에서 간단히 살펴봅니다.

⭐ 3.3 재배치 가능한 목적 파일

✅ 재배치 가능한 목적파일이란?

재배치 가능한(relocatable) 의 의미는?

• 링커가 작업을 수행하는 과정에서 비롯된 의미

링커는 재배치 가능한 목적 파일 여러 개를 한데 모아서 더 큰 목적 파일을 형성하는데,

이 파일은 실행 가능한 목적 파일 혹은 공유 목적 파일이라고 합니다.

실행 가능한 목적 파일에서 찾아볼 수 있는 항목은 이 파일을 구성하는 모든 재배치 가능한 목적 파일에서 찾아볼 수 있는 항목의 총합이라는 점입니다. 먼저 기계 수준의 명령어를 알아봅시다.

• 하나의 재배치 가능한 목적 파일에서 나타나는 기계 수준의 명령어는 다른 재배지 가능한 목적파일에서 나온 기계 수준의 명령어 다음에 위치해야 합니다.
• 이는 즉 명령어가 이동할 수 있거나 재배치 가능 relocatable 하다는 점을 의미합니다.
• 따라서 재배치 가능한 목적 파일에서 명령어는 주소를 갖지 않고 링크 단계를 거치고 나서야 명령어는 주소를 가집니다.

[예제 3-1]은 두 개의 소스 파일에 관한 것으로, 한 소스 파일은 max와 max_3이라는 함수 2개의 정의를 포함합니다. 다른 소스 파일은 선언된 함수 max와 max_3를 사용하는 main 함수를포함합니다. 다음은 첫 번째 소스 파일의 내용입니다.

코드 박스 3-1 [예제 3-1]의 두 함수의 정의를 포함하는 파일(ExtremeC_examples_chapter3_1.funcs.c)

int max(int a, int b) {
	return a > b ? a : b;
}
int max_3(int a,int b, int c){
	int temp = max(a, b);
	return c > temp ? c : temp;
}

그리고 두 번째 소스 파일은 다음 [코드 박스 3-2]와 같습니다.

코드 박스 3-2 [예제 3-1]의 이미 선언된 함수를 사용하는 main 함수: 정의는 별도의 소스 파일에 있음 (ExtremeC_examples_chapter3_1.c)

int max(int, int);
int max_3(int, int, int);

int a = 5;
int b = 10;

int main(int argc, char** argv) {
	int m1 = max(a, b);
	int m2 =  max_3(5, 8, -1);
	return 0;
}

앞의 소스 파일로 재배치 가능한 목적 파일을 만들어봅시다. 이렇게 해서 코드의 내용 및 앞서 설명한 내용을 살펴볼 수 있습니다. 리눅스 머신에서 소스를 컴파일하므로, 컴파일 결과로는 ELF 목적 파일이 나오게 된다.

셀 박스 3-1 소스 파일에 해당하는 재배치 가능한 목적 파일로 컴파일하기

$ gcc -c ExtremeC_examples_chapter3_1_funcs.c -o funcs.o
$ gcc -c ExtremeC_examples_chapter3_1.c -o main.o
$

funcs.o와 main.o는 둘 다 재배치 가능한 ELF 목적 파일입니다. ELF 목적 파일에서는 재배치 가능한 목적 파일에서 서술된 항목이 ELF 목적 파일의 여러 섹션에 배치됩니다. 이러한 재배치 가능한 목적 파일에 현재 존재하는 섹션을 확인하려면 readelf 유틸리티를 다음과 같이 사용할 수 있습니다.

셸 박스 3-2 funcs.o 목적 파일의 ELF 내용

**$ readelf -hsl funcs.o**
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Data:  2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL
Machine: Advanved Micro Devices X86-64

...

Number of section headers: 12
Section header string table index: 11

⭐ 3.4 실행 가능한 목적 파일

✅ 실행 가능한 목적 파일

실행 가능한 목적 파일이 C 언어의 프로젝트의 최종 결과물 중 하나일까?

• 실행 가능한 목적 파일도 재배치 가능한 목적 파일처럼 기계 수준의 명령어, 초기화된 전역 변숫값, 심벌 테이블과 같은 항목을 가집니다.
• 하지만 정렬arrangement 은 다를 수 있습니다.

ELF 실행 가능한 목적 파일은 생성하기도 내부 구조를 이해하기도 쉬운 만큼, 이 파일과 관련한 차이점을 설명할 수 있습니다.

실행 가능한 ELF 목적 파일을 만들고자 [예제 3-1]로 넘어가 보겠습니다. 앞 절에서 예제에 있는 소스 2개로부터 재배치 가능한 목적 파일을 만들었습니다. 이번에는 그 파일을 링크해 하나의 실행 파일을 만들겠습니다.

앞 장에서 설명한 대로 다음 명령어를 사용합니다.

gcc funcs.o main.o -o ex3_1.out

앞 절에서 ELF 목적 파일에 존재하는 섹션을 설명했습니다.

• ELF 실행 가능한 목적 파일에는 더 많은 섹션이 있는데, 이들은 몇몇 세그먼트와 함께 있습니다.
• 모든 ELF 실행 가능한 목적 파일과, 이장의 후반부에서 보게 될 ELF 공유 목적 파일은 섹션뿐만 아니라 여러 세그먼트를 갖습니다.
• 각 세그먼트는 많은 섹션 (0개 혹은 그 이상)으로 구성되며, 섹션은 내용에 따라 세그먼트에 놓입니다.
  • 예를 들면 기계 수준의 명령어를 포함하는 모든 섹션은 같은 세그먼트에 들어갑니다.

이제 실행 파일의 내용을 살펴보고 세그먼트도 만나봅시다. 재배치 가능한 목적 파일과 마찬가지로, 실행 가능한 ELF 목적 파일에 있는 섹션과 세그먼트를 보려면 같은 명령어를 사용할 수 있습니다.

셸 박스 3-6 ex3_1.out 실행 목적 파일의 ELF 내용

readelf -hSl ex3_1.out

⭐ 3.5 정적 라이브러리

이전에 설명한 대로 정적 라이브러리는 C 프로젝트에서 얻을 수 있는 결과물 중 하나입니다.

이 절에서는 정적 라이브러리를 다루며 어떻게 생성되고 사용되는지를 살펴보겠습니다. 그다 음 절에서는 동적 라이브러리를 소개하며 설명을 계속하겠습니다. 정적 라이브러리는 쉽게 말해 재배치 가능한 목적 파일에서 만들어지는 유닉스 아카이브입니다.

정적 라이브러리는 다른 목적 파일과 함께 링크되어 실행 가능한 목적 파일을 형성합니다. 정적 라이브러리 그 자체는 목적 파일로 볼 수 없으며, 오히려 목적 파일을 위한 컨테이너입니 다. 즉 리눅스 시스템에서 정적 라이브러리는 ELF 파일이 아닙니다. 또한 macOS 시스템에서 Mach-O 파일인 것도 아닙니다.

정적 라이브러리는 유닉스의 ar 유틸리티로 파일을 아카이브할 뿐입니다. 링커가 링크 단계에서 정적 라이브러리를 사용하려고 할 때, 우선 재배치 가능한 목적 파일에서 정적 라이브러리를 추출하려고 시도합니다. 그다음에는 거기서 정의되지 않은 심벌을 찾아 서 해결하기 시작합니다.

이번에는 여러 개의 소스 파일을 가진 프로젝트에서 정적 라이브러리를 만들어볼 차례입니다. 첫 번째 단계는 재배치 가능한 목적 파일을 만드는 일입니다. C/C++ 프로젝트의 모든 소스 파 일을 컴파일하고 나면 정적 라이브러리의 아카이브 파일을 만들고자 유닉스의 아카이브 도구 인 ar을 사용할 수 있습니다.

유닉스 시스템에서 정적 라이브러리는 널리 사용되고 수용되는 규칙에 따라 이름이 붙습니다. 이름은 Lib로 시작하고. 확장자로 끝납니다. 다른 운영체제에서는 다를 수 있습니다. 예를들어 윈도우에서는 정적 라이브러리에.lib확장자가 붙습니다.

가상의 C 프로젝트에서 aa.c, bb.c부터 zz.c까지 여러 소스 파일을 가졌다고 가정해봅시다. 재배치 가능한 목적 파일을 만들려면 다음 명령어를 사용한 것과 비슷한 방식으로 소스 파일을 컴파일해야 합니다. 컴파일 과정은 이전 장에서 자세히 살펴봤으니 참고하세요.

여러 소스 파일을 그에 해당하는 재배치 가능한 목적 파일로 컴파일하기

gcc -c aa.c -o aa.o
gcc -c bb.c -o bb.o
gcc -c ZZ.C -O zz.0

⭐ 3.6 동적 라이브러리

동적 라이브러리 혹은 공유 라이브러리는 재사용을 위한 라이브러리를 만드는 또 다른 방식입니다. 이름대로, 정적 라이브러리와는 달리 동적 라이브러리는 그 자체가 실행 파일에 해당하지는 않습니다. 대신 동적 라이브러리는 실행을 위한 프로세스가 로딩될 때 가져와서 로드되어야 합니다.

정적 라이브러리가 실행 파일의 일부이므로, 링커는 주어진 재배치 가능한 파일의 모든 것을최종 실행 파일에 넣습니다. 즉, 링커는 정의되지 않은 심벌을 감지하고, 정의가 필요하며, 이를 주어진 재배치 가능한 목적 파일에서 찾고자 하고, 그렇게 출력되는 최종 파일에 모든 것을 집어넣습니다.

모든 정의되지 않은 심벌을 찾고 나서야 최종 결과물이 만들어집니다. 고유한 관점에서 링크 단계에서 모든 심벌의 의존 관계를 찾아서 해결합니다. 동적 라이브러리의 경우 정의되지 않은 심벌을 가질 수도 있습니다. 이러한 정의되지 않은 심벌은 링크 단계에서 해결되지 않습니다. 실행 파일이 로드되고 실행을 시작할 때 이 심벌을 검색합니다.

즉, 정의되지 않은 동적 심벌을 찾고자 할 때는 다른 종류의 링크 단계가 필요합니다. 실행 파일을 로드하고 프로세스로 실행될 준비를 할 때, 동적 링커 dynamic linker 혹은 간단히는 로더loader가 주로 이 링크를 수행합니다.

정의되지 않은 동적 심벌을 실행 파일에서 찾을 수 없으므로 어딘가 다른 곳에서 찾아야 합니다. 이 심벌은 공유 목적 파일에서 로드해야 합니다. 공유 목적 파일은 정적 라이브러리 파일의 자매 격인 파일입니다. 대부분의 유닉스 계열 시스템에서 정적 라이브러리는 . 확장자를 갖지만, 정적 목적 파일은 .SO 확장자를 갖습니다. macOS에서는 dylib 확장자를 가집니다. 프로세스를 로드하고 실행할 때, 공유 목적 파일이 로드되며 프로세스가 접근할 수 있는 메모리 지역에 이 파일이 연결됩니다. 이 절차는 동적 링커 (혹은 로더)에 의해 수행되며, 동적 링커는 실행 파일을 로드하고 실행합니다.

실행 가능한 목적 파일에 대한 절에서 설명한 대로, ELF 실행 파일 및 공유 목적 파일은 각자의 ELF 구조 내에 세그먼트가 있습니다. 각 세그먼트 안에는 0개 혹은 그 이상의 섹션이 있습니다. ELF 실행 가능한 목적 파일과 ELF 공유 목적 파일 간에는 주요 차이점이 두 가지 있습니다. 첫 번째, 심벌이 상대적인 절대 주소를 가지며 이 주소를 통해 심벌이 여러 프로세스에 동시에 로드되도록 합니다.

이는 각 명령어의 주소가 프로세스에서 다른 한편, 두 명령어 사이의 거리는 고정되어 있음을 의미합니다. 다시 말하면 주소는 오프셋 offset에 상대적으로 고정됩니다.

이는 재배치 가능한 목적 파일이 위치 독립적 position independent이기 때문입니다. 이번 장의 마지막 부분에서 더 설명하겠습니다.

예를 들어, 한 프로세스에서 두 명령어가 100과 200이라는 주소에 위치하고, 다른 프로세스에서는 명령어가 140과 240, 또 다른 프로세스에서는 323과 423에 있다고 해봅시다.

서로 연관 된 주소는 절대적이지만, 실제 주소는 변할 수 있습니다. 이 두 명령어는 언제나 주소가 서로 100만큼 떨어져 있을 것입니다. 두 번째 차이점은 ELF 실행 가능한 목적 파일에 관련된 세그먼트가 공유 목적 파일에는 존재 하지 않는다는 것입니다. 이는 결국 공유 목적 파일이 실행될 수 없음을 의미합니다.

공유 목적 파일이 다른 프로세스에서 어떻게 접근하는지 세부적으로 설명하기 전에, 공유 목적 파일이 어떻게 생성되고 사용되는지에 관한 예제를 살펴봐야 합니다. 따라서 앞 절에서 작업한 [예제 3-2]와 동일한 기하학 라이브러리를 위한 동적 라이브러리를 생성하겠습니다.

앞서 기하학 라이브러리를 위한 정적 라이브러리를 생성했습니다. 이번에는 공유 목적 파일을만들고자 소스를 다시 컴파일하려 합니다. 다음 명령어는 3개의 소스 파일을 재배치 가능한 목적 파일로 컴파일하는 방법을 나타냅니다. [예제 3-2]에 비하면 단 하나의 차이만 있습니다.

다음 명령어에서 -fPIC 옵션이 gcc로 전달된다는 점에 주의하세요.

gcc -c Extremec_examples_chapter3_2_2d.c -fPIC -o 2d.o
gcc -c ExtremeC_examples_chapter3_2_3d.c -fPIC -o 3d.o
gcc -c ExtremeC_examples_chapter3_2_trigon.c -fPIC -o trigon.o

명령어를 보면 소스를 컴파일하는 동안 gcc에 추가 옵션인 FPIC를 전달했다는 것을 알 수 있습니다. 만약 재배치 가능한 목적 파일에서 공유 목적 파일을 만들려고 한다면 이 옵션은 반드시 사용해야 합니다.

PIC는 위치 독립적인 코드 position independent code를 나타냅니다. 앞서 설명한대로 만약 재배치 가능한 목적 파일이 위치 독립적이라면, 이는 곧 파일 안의 명령어 instruction가고정 주소를 갖지 않는다는 의미입니다. 그 대신 상대 주소를 가집니다. 따라서 재배치 가능한 목적 파일은 다른 프로세스에서 다른 주소를 가질 수 있습니다. 공유 목적 파일을 사용하는 방식 때문에 이는 필수 조건입니다.

프로세스가 다른 경우 로더 프로그램이 같은 주소에서 공유 목적 파일을 로드하리라는 보장은 없습니다. 사실 로더는 공유 목적 파일에 메모리 매핑을 생성하고, 그러한 매핑을 위한 주소의 범위는 다를 수 있습니다. 만약 명령어의 주소가 절대적이라면, 다양한 프로세스나 다양한 메모리 지역에서 같은 공유 목적 파일을 동시에 로드할 수 없습니다.

공유 목적 파일을 만들려면 컴파일러가 필요하며, 여기서는 다시 gcc를 사용합니다. 정적 라이브러리 파일과는 달리 공유 목적 파일은 단순한 아카이브이며, 공유 목적 파일은 그 자체로 목적 파일입니다. 따라서 재배치 가능한 목적 파일을 만들려면 사용한 것과 동일한 링커 프로그램으로 생성해야 합니다.

알다시피 대부분의 유닉스 계열 시스템에서 ld가 컴파일을 수행합니다. 하지만 앞서 설명한 이유 때문에 ld를 직접 사용해서 목적 파일을 링크하지 않기를 강력히 권고합니다. 다음 명령어는 -fPIC 옵션을 사용해 컴파일한 여러 재배치 가능한 목적 파일로부터 공유 목적 파일을 만드는 법을 나타냅니다.

gcc -shared 2d.o 3d.o trigon.o -o libgeometry.so
mkdir -p /opt/geometry
mv libgeometry.so /opt/geometry
sudo mv libgeometry.so ../../../../opt/geometry/

첫 번째 명령어에서 볼 수 있듯 -shared 옵션을 gcc에 전달해 재배치 가능한 목적 파일에서 공유 목적 파일을 생성하도록 지시했습니다. 이 결과로 공유 목적 파일은 libgeometry.so 라는 이름이 붙습니다. 여기서는 공유 목적 파일을 opt/geometry로 이동해 다른 프로그램이 사용하기 쉽게 두었습니다. 다음은 [예제 3-3]을 다시 컴파일하고 링크하는 단계입니다.

앞에서는 [예제 3-3] 컴파일해 정적 라이브러리 파일인 libgeometry.a와 링크했습니다. 여기에서도 같은 과정을 수행하지만, 링크는 libgeometry.so, 즉 동적 라이브러리와 링크하겠습니다.

모든 것은 같아 보입니다. 특히 명령어도 똑같아 보이지만, 사실은 다릅니다. 이번에는 libgeometry.a 대신 libgeometry.so [예제 3-3]을 링크합니다. 게다가 동적 라이브러리는 최종 실행 파일에 임베드되지 않습니다. 대신 실행할 때 라이브러리가 로드됩니다.

연습을 위해 [예제 3-3]을 다시 링크하기 전 opt/geometry에서 정적 라이브러리 파일 libgeometry.a를 제거합시다.

rm -fv /opt/geometry/libgeometry.a
gcc -c ExtremeC_examples_chapter3_3.c -o main.o
gcc main.o -L/opt/geometry -lgeometry -lm -o ex3_3.out

앞서 설명한 대로-lgeometry 옵션은 컴파일러가 정적 혹은 동적 라이브러리를 찾아서 사용하도록 하고, 그 파일을 나머지 목적 파일과 링크하도록 합니다.

정적 라이브러리 파일을 제거했으므로 공유 목적 파일이 선택됩니다. 만약 지정 경로에 정적 라이브러리와 공유 목적 파일이 둘 다 존재한다면, gcc는 공유 목적 파일을 선택해 프로그램과 링크합니다.실행 파일인 ex3_3.out을 실행하면 대부분 다음과 같은 오류가 나타납니다.

./ex3_3.out

지금까지는 정적 링크와 정적 라이브러리를 사용했으므로 이런 오류를 볼 수 없었습니다. 하지만 이번에는 동적 라이브러리를 가져왔으므로, 만약 동적 의존성 dynamic dependency을 갖는 프로그램을 실행한다면 실행에 필요한 동적 라이브러리를 제공해야 합니다. 하지만 무슨 일이 발생했으며 왜 이런 오류 메시지를 받게 될까요?

실행 파일 ex3_3.out은 필요한 정의의 일부를 공유 목적 파일에서만 찾으므로 libgeometry.so에 의존합니다. 정적 라이브러리인 libgeometry.a에서는 그렇지 않다는 점을 알아두세요.

정적 라이브러리와 링크된 실행 파일은 독립 실행 파일 standalone executable에서 실행할 수 있습니다. 이는 정적 라이브러리 파일로부터 모든 것을 복제하기 때문이며 따라서 정적 라이브러리 파일의 존재에 더는 의존하지 않습니다.

공유 목적 파일에서는 그렇지 않습니다. 프로그램 로더가 기본 탐색 경로에서 libgeometry.so를 찾을 수 없으므로 오류가 발생했습니다. 그러므로 탐색 경로에 /opt/geometry를 추가해서 거기에서 libgeometry.so를 찾을 수 있도록 해야 합니다. 경로를 추가하기 위해 환경변수인 LD_LIBRARY_PATH가 현재 경로를 가리키도록 업데이트합니다.

로더는 환경 변수를 검사할 것이고, 필요한 공유 라이브러리를 지정 경로에서 검색할 것입니다. 환경 변수에는 하나 이상의 경로를 지정할 수 있다는 점을 알아두세요

export LD_LIBRARY_PATH=/opt/geometry
./ex3_3.out

이번에는 프로그램이 성공적으로 실행됩니다. 프로그램 로더가 공유 목적 파일을 찾았고 동적 링커가 그 파일로부터 필요한 심벌을 성공적으로 로드했다는 의미입니다.

앞의 셸 박스에서 LD_LIBRARY_PATH를 변경하려고 export 명령어를 사용했으니 유의하세요. 하지만 일반적으로는 환경 변수를 실행 명령어와 함께 설정합니다. 다음 셸 박스에서 이를 확인할 수 있습니다. 사용 결과는 둘 다 같습니다.

같은 명령어로 LD_LIBRARY_PATH의 경로를 지정해 [예제 3-3]을 실행하기

LD_LIBRARY_PATH=/opt/geometry ./ex3_3.out

앞에서 한 대로 몇 개의 공유 목적 파일과 실행 파일 하나를 링크함으로써, 이 실행 파일이 실행 시 at runtime 많은 공유 라이브러리를 찾아서 로드해야 한다고 시스템에 명령합니다.

따라서 실행 파일을 실행하기 전에, 로더는 자동으로 이러한 공유 목적 파일을 찾고, 필요한 심벌이 프로세스가 접근할 수 있는 알맞은 주소에 연결됩니다. 그래야만 프로세서가 실행을 시작할 수 있습니다.

✅ 공유 라이브러리의 수동 로딩

또한 공유 목적 파일은 다른 방식으로 로드되고 사용될 수 있습니다. 로더 프로그램(동적 링커)이 자동으로 로드하지 않는 방식입니다.

공유 라이브러리 내부에서 찾을 수 있는 심벌 (함수)을 이용하기전, 공유목적 파일을 수동으로 로드하는 함수를 개발자가 사용할 수 있습니다.

수동 로딩 메커니즘을 위한 응용프로그램이 존재하며, 이번 절에서 알아볼 것이라고 언급한 적이 있는 예제를 통해 설명하겠습니다.

[예제 3-4]는 링크 단계에서 공유 목적 파일을 느리게 또는 수동으로, 혹은 공유 목적 파일 없이 로드하는 법을 제시합니다. 이번 예제는

[예제 3-3]과 같은 로직을 빌려 오지만, 그 대신 프로그램 내에서 공유 목적 파일인 libgeometry.so를 수동으로 로드합니다. [예제 3-4]를 보기 전에 [예제 3-4]가 작동할 수 있도록 libgeometry.so를 약간 다르게 생성해야 합니다. 그러려면 리눅스에서 다음 명령어를 사용해야 합니다.

gcc -shared 2d.o 3d.o trigon.o -lm -o libgeometry.so

앞의 명령어에서는 새로운 옵션인 -m을 볼 수 있습니다. 이것은 링커가 표준 수학 라이브러리인 libm.so와 관련된 공유 목적 파일을 링크하도록 합니다.

libgeometry.so를 수동으로 로드할 때, 이 파일의 의존성이 어느 정도는 자동으로 로드되어야 하기 때문입니다.

만약 그렇지 않다면 cos 또는 sqrt 같이 libgeometry.so가 필요로 하는 심벌에 관한 오류가 발생합니다. 최종 실행 파일과 수학 표준 라이브러리를 링크하지는 않을 것이며, libgeometry.so 를 로드할 때 로더가 이를 자동으로 해결할 것이라는 점을 참고하세요.

공유 목적 파일을 링크했으니 이제 [예제 3-4]를 진행할 수 있습니다.

// File name: ExtremeC_examples_chapter3_4.c
// Description: Load the shared object file using dlopen

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

#include "ExtremeC_examples_chapter3_2_geometry.h"

polar_pos_2d_t (*func_ptr)(cartesian_pos_2d_t*);

int main(int argc, char** argv)
{

  void* handle = dlopen ("/opt/geometry/libgeometry.so", RTLD_LAZY);
  if (!handle) {
    fprintf(stderr, "%s\n", dlerror());
    exit(1);
  }

  func_ptr = dlsym(handle, "convert_to_2d_polar_pos");
  if (!func_ptr)
	{
    fprintf(stderr, "%s\n", dlerror());
    exit(1);
  }

  cartesian_pos_2d_t cartesian_pos;
  cartesian_pos.x = 100;
  cartesian_pos.y = 200;
  polar_pos_2d_t polar_pos = func_ptr(&cartesian_pos);
  printf("Polar Position: Length: %f, Theta: %f (deg)\n",
    polar_pos.length, polar_pos.theta);
  return 0;
}

이 코드에서 dlopen과 dlsym이라는 함수로 공유 목적 파일을 로드하는 방법을 확인할 수 있습니다. 또한 convert_to_2d_polar_pos가 공유 목적 파일 안에 있다는 것도 볼 수 있습니다.

dlsym 함수는 함수 포인터를 반환하며, 이 포인터는 대상 함수를 불러오는 invoke데에 쓰입니다.

이 코드는 /opt/geometry에서 공유 목적 파일을 찾으며, 이 디렉터리에 해당 파일이 없다면 오류 메시지가 나타나니 주의해야 합니다. 참고로 macOS에서 공유 목적 파일의 확장자는 dylib입니다. 따라서 올바른 확장자로 파일을 로드하려면 이 코드를 수정해야 합니다.

다음 명령어는 앞의 코드를 컴파일하고 실행 파일을 실행합니다.

gcc ExtremeC_examples_chapter3_4.c -ldl -o ex3_4.out

프로그램을 libgeometry.so 파일과 링크하지 않았습니다. 필요할 때 이 파일을 수동으로 로드하려고 했기 때문입니다. 이방법은 공유 목적 파일의 지연된 로딩 lazy loading이라고 합니다.

이름은 이렇지만, 경우에 따라 공유 목적 파일을 지연해 로드하는 방식은 정말 유용합니다. 같은 라이브러리의 별도 실행 혹은 별도 버전을 위한 공유 목적 파일을 별개로 만들려고 할 때 가 지연된 로딩에 해당하는 경우입니다.

지연된 로딩을 하면 필요한 공유 목적 파일을 자유롭게 로드할 수 있습니다. 반면 자동으로 로드하면 이에 대한 자유도가 감소합니다.