정적 라이브러리와 공유 라이브러리

라이브러리는 매번 소스를 다시 컴파일하지 않고 여러 프로그램에서 재사용할 수 있는 컴파일된 객체 파일 묶음입니다.

C에는 두 종류가 있습니다.

• 정적 라이브러리(.a): 링크할 때 실행 파일에 복사됩니다
• 공유 라이브러리(.so): 실행 중에 로드됩니다

두 종류의 라이브러리 모두 객체 파일에서 시작합니다. 평소처럼 -c를 사용해 소스를 컴파일합니다.

이 .o 파일은 보관 도구나 링커가 패키징할 원재료입니다.

ar 보관 도구는 객체 파일을 .a 보관 파일로 묶습니다. 관례적인 이름은 lib<name>.a입니다.

플래그의 의미는 다음과 같습니다. r은 삽입, c는 필요한 경우 생성, s는 색인 작성입니다.

검색 디렉터리에는 -L을, 라이브러리 이름에는 -l을 사용해 링크합니다. 이때 lib 접두사와 .a 접미사는 제외합니다.

필요한 코드는 실행 파일에 복사되어 실행 파일이 독립적으로 실행됩니다.

정적 링크는 단순하고 자체적으로 완결됩니다.

• 실행 파일이 모든 내용을 포함하므로 실행 시 의존성이 없습니다
• 하지만 각 프로그램이 사본을 포함하므로 바이너리가 더 커집니다
• 라이브러리의 버그를 수정하려면 해당 라이브러리를 사용한 모든 프로그램을 다시 링크해야 합니다

공유 라이브러리는 어떤 메모리 주소에도 로드될 수 있으므로 코드가 위치 독립적이어야 합니다. -fPIC으로 컴파일합니다.

이렇게 하면 고정 주소 대신 상대 주소 지정을 사용하는 코드가 생성됩니다.

-shared를 사용해 .so 파일을 빌드합니다. 관례적인 이름은 lib<name>.so입니다.

정적 보관 파일과 달리, 이는 로더가 실행 중에 매핑할 수 있는 실제 링크된 객체입니다.

링크 방식은 정적 라이브러리의 경우와 동일해 보입니다. 차이점은 코드가 복사되지 않고 참조만 기록된다는 것입니다.

실행 파일은 작게 유지되지만 이제 실행 중에 libmymath.so를 찾아야 합니다.

프로그램이 시작될 때 동적 로더는 표준 경로에서 .so 파일을 검색합니다. 현재 디렉터리의 라이브러리는 해당 목록에 포함되지 않습니다.

테스트할 때는 LD_LIBRARY_PATH(Linux)를 사용해 로더가 해당 라이브러리를 찾도록 지정할 수 있습니다.

공유 라이브러리는 단순함을 유연성과 맞바꿉니다.

• 메모리의 한 사본을 여러 프로그램이 공유하므로 RAM과 디스크 공간을 절약합니다
• .so의 버그 수정이 다시 링크하지 않아도 모든 프로그램에 적용됩니다
• 하지만 .so가 없거나 호환되지 않으면 프로그램이 시작되지 않습니다

마지막 위험이 흔히 말하는 '의존성 지옥'입니다.

바이너리가 어떤 항목에 링크되는지 확인하는 데 도움이 되는 도구는 두 가지입니다.

• ldd app은 로더가 실행 중에 필요로 하는 공유 라이브러리를 나열합니다
• nm libmymath.a는 라이브러리 내부의 기호(함수)를 나열합니다

ldd에 'not found'가 표시되면 로더가 검색 경로에서 해당 .so를 찾을 수 없다는 뜻입니다.

플래그와 목적을 연결해 보세요.

이제 두 종류의 라이브러리를 모두 빌드하고 링크할 수 있습니다.

• 정적: ar rcs libX.a *.o로 만들며, 코드가 바이너리에 복사되어 자체적으로 완결되지만 더 큽니다
• 공유: -fPIC으로 컴파일하고 -shared로 빌드하며, 코드가 실행 중에 로드됩니다
• 둘 다 -L과 -l로 링크하며, 공유 라이브러리에는 LD_LIBRARY_PATH와 같은 실행 시 검색 경로가 필요합니다

이제 전처리기부터 빌드까지 전체 도구 체계를 갖추었습니다.