2.3. GCC에서 라이브러리 사용

특수 파일 이름 규칙은 라이브러리에 사용됩니다. foo라는 라이브러리는 lib foo .so 또는 libfoo . a 파일로 존재할 것으로 예상됩니다. 이 규칙은 GCC의 입력 옵션을 연결하지만 출력 옵션에 의해 자동으로 이해되지 않습니다.

개발자는 완전히 컴파일된 언어로 애플리케이션을 빌드할 때 정적 또는 동적 링크를 사용할 수 있습니다. 특히 Red Hat Enterprise Linux에서 C 및 C++ 언어 사용의 맥락에서 정적 연결과 동적 연결의 차이점을 이해하는 것이 중요합니다. 요약하면 Red Hat은 Red Hat Enterprise Linux용 애플리케이션에서 정적 링크를 사용하지 않는 것이 좋습니다.

정적 연결에는 여러 가지 단점이 있으며 특히 전체 애플리케이션 및 glibc 및 libstdc++ 라이브러리의 경우 피해야 합니다.

resource use: 정적 연결로 인해 더 큰 실행 파일이 더 많은 코드가 포함됩니다. 라이브러리에서 제공되는 이 추가 코드는 시스템의 여러 프로그램에서 공유할 수 없으므로 런타임 시 파일 시스템 사용량과 메모리 사용량을 늘릴 수 있습니다. 동일한 정적으로 연결된 프로그램을 실행하는 여러 프로세스가 여전히 코드를 공유합니다.

반면 정적 애플리케이션에는 더 적은 런타임 재배치가 필요하므로 시작 시간을 단축하고 개인 상주 설정 크기(RSS) 메모리가 줄어듭니다. 정적 연결을 위한 생성된 코드는 위치 독립 코드(PIC)에 의해 도입된 오버헤드로 인해 동적 연결을 위한 것보다 더 효율적일 수 있습니다.

보안: ABI 호환성을 제공하는 동적 링크 라이브러리는 이러한 라이브러리에 따라 실행 파일을 변경하지 않고도 업데이트할 수 있습니다. 이는 Red Hat이 보안 업데이트를 제공하는 Red Hat Enterprise Linux의 일부로 Red Hat에서 제공하는 라이브러리에서 특히 중요합니다. 이러한 라이브러리에 대한 정적 연결은 권장되지 않습니다.

호환성: 정적 연결은 운영 체제에서 제공하는 라이브러리 버전과 관계없이 실행 파일을 제공하는 것으로 보입니다. 그러나 대부분의 라이브러리는 다른 라이브러리에 의존합니다. 정적 연결을 사용하면 이 종속성은 유연성이 떨어지고 결과적으로 앞으로 및 이전 버전과의 호환성이 모두 손실됩니다. 정적 연결은 실행 파일이 빌드된 시스템에서만 작동하도록 보장됩니다.

지원 범위: Red Hat에서 제공하는 대부분의 정적 라이브러리는 CodeReady Linux Builder 채널에 있으며 Red Hat에서 지원하지 않습니다.

기능: 일부 라이브러리, 특히 GNU C 라이브러리(glibc)는 정적으로 연결된 경우 기능 감소를 제공합니다.

예를 들어 정적으로 연결된 경우 glibc 는 동일한 프로그램에서 dlopen() 함수에 대한 스레드 및 모든 형태의 호출을 지원하지 않습니다.

LTO(링크 시간 최적화)는 다음과 같은 이점이 있습니다.

라이브러리는 프로그램에서 재사용할 수 있는 코드의 패키지입니다. C 또는 C++ 라이브러리는 다음 두 부분으로 구성됩니다.

일반적으로 라이브러리의 헤더 파일은 애플리케이션 코드와 다른 디렉터리에 배치됩니다. GCC 헤더 파일이 어디에 있는지 알려주려면 -I 옵션을 사용합니다.

$ gcc ... -Iinclude_path ...

include_path 를 헤더 파일 디렉터리의 실제 경로로 바꿉니다.

예를 들어 상대 경로를 지정하려면 some/interesting/directory:

$ gcc ... -Isome/interesting/directory ...

I 옵션을 여러 번 사용하여 헤더 파일이 있는 여러 디렉터리를 추가할 수 있습니다. 헤더 파일을 찾을 때 이러한 디렉터리는 -I 옵션에 표시되는 순서대로 검색됩니다.

GCC에 라이브러리의 아카이브 또는 공유 오브젝트 파일이 어디에 있는지 알려주려면 -L 옵션을 사용합니다.

$ gcc ... -Llibrary_path -lfoo ...

library_path 를 라이브러리 디렉터리의 실제 경로로 바꿉니다.

L 옵션을 여러 번 사용하여 여러 디렉터리를 추가할 수 있습니다. 라이브러리를 찾으면 이러한 디렉터리가 -L 옵션 순서대로 검색됩니다.

옵션 순서는 중요합니다. GCC는 이 라이브러리가 있는 디렉토리를 모르는 한 라이브러리 foo 에 대해 연결할 수 없습니다. 따라서 라이브러리에 연결하는 -l 옵션을 사용하기 전에 -L 옵션을 사용하여 라이브러리 디렉터리를 지정합니다.

정적 라이브러리는 오브젝트 파일이 포함된 아카이브로 사용할 수 있습니다. 연결 후 결과 실행 파일의 일부가 됩니다.

정적 및 동적 연결참조

동적 라이브러리는 독립 실행형 실행 파일로 사용할 수 있으며, 연결 시간과 런타임에 필요합니다. 애플리케이션의 실행 파일과 무관하게 유지됩니다.

$ *gcc ... -L__library_path__ -l__foo__ ...*

프로그램이 동적 라이브러리에 연결되어 있는 경우 결과 프로그램은 항상 런타임 시 라이브러리를 로드해야 합니다. 라이브러리를 찾는 방법은 다음 두 가지가 있습니다.

GCC 와 연결하는 동안 library_path 를 실행 경로로 저장하기 위해 다음을 수행합니다.

$ gcc ... -Llibrary_path -lfoo -Wl,-run path=library_path ...

path library_path 는 libfoo.so 파일이 포함된 디렉토리를 가리켜야 합니다.

나중에 프로그램을 실행하려면 다음을 수행합니다.

$ ./program

이 문서에서는 동적 연결 동작을 자세히 다루지 않습니다. 자세한 내용은 다음 리소스를 참조하십시오.

$ man ld.so

$ cat /etc/ld.so.conf

$ ldconfig -v

경우에 따라 일부 라이브러리를 정적 및 기타 라이브러리를 동적으로 연결해야 하는 경우가 있습니다. 이 혼합 연결 접근 방식을 사용하려면 GCC가 다양한 라이브러리 유형을 처리하는 방법을 이해해야 합니다.

GCC 는 동적 라이브러리와 정적 라이브러리를 모두 인식합니다. lfoo 옵션이 발생하면 gcc 는 먼저 foo 라이브러리의 동적으로 연결된 버전이 포함된 공유 오브젝트( .so 파일)를 찾은 다음 라이브러리의 정적 버전이 포함된 아카이브 파일(.a)을 찾습니다. 따라서 이 검색으로 인해 다음과 같은 상황이 발생할 수 있습니다.

이러한 규칙으로 인해 연결을 위한 정적 또는 동적 라이브러리 버전을 선택하는 가장 좋은 방법은 gcc 에서 해당 버전만 찾는 것입니다. 이는 -L경로 옵션을 지정할 때 라이브러리 버전이 포함된 디렉터리를 사용하거나 남겨 두어 어느 정도 제어할 수 있습니다.

또한 동적 링크가 기본값이므로 두 버전이 모두 있는 라이브러리를 정적으로 연결해야 하는 유일한 상황은 링크에서 명시적으로 지정해야 합니다. 두 가지 가능한 해결 방법이 있습니다.

$ *gcc ... path/to/libfoo.a ...*

파일 확장자 .a 에서gcc 는 프로그램과 연결할 라이브러리임을 이해할 것입니다. 그러나 라이브러리 파일의 전체 경로를 지정하는 것은 덜 유연합니다.

gcc 에서 사용하는 ld 링커는 이 옵션의 라이브러리를 정적으로 연결하는 -Bstatic 옵션과 -Bdynamic 을 제공하여 동적으로 연결합니다. Bstatic 및 라이브러리를 링커에 전달한 후에는 다음 라이브러리가 -B dynamic 옵션과 동적으로 연결되도록 기본 동적 연결 동작을 수동으로 복원해야 합니다.

프로그램을 연결하려면 먼저 정적(lib first.a) 및 두 번째 동적으로(lib second.so ) 링크 라이브러리를 연결합니다.

$ gcc ... -Wl,-Bstatic -lfirst -Wl,-Bdynamic -lsecond ...