RHEL 8에서 C 및 C++ 애플리케이션 개발

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

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

동적 및 정적 연결은 다음과 같은 여러 방법으로 비교할 수 있습니다.

나열된 단점으로 인해 특히 전체 애플리케이션 및 glibc 및 libstdc++ 라이브러리의 경우 정적 연결을 피할 수 있습니다.

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

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

$ gcc ... -Iinclude_path ...

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

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

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

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

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

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

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

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

동적 라이브러리는 연결 시간과 런타임 모두에 필요한 독립 실행형 실행 파일로 사용할 수 있습니다. 애플리케이션의 실행 파일과는 별개로 유지됩니다.

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

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

GCC 와 연결하는 동안 경로 library_path를 rpath 로 저장합니다.

$ gcc ... -Llibrary_path -lfoo -Wl,-rpath=library_path ...

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

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

$ ./program

rpath 설정 없이 프로그램을 실행하려면 path library_path 에 라이브러리가 있음 :

$ export LD_LIBRARY_PATH=library_path:$LD_LIBRARY_PATH
$ ./program

rpath 값을 제외하면 유연성이 제공되지만, 프로그램을 실행할 때마다 LD_LIBRARY_PATH 변수를 설정해야 합니다.

동적 링커 동작에 대한 자세한 설명은 이 문서의 범위를 벗어납니다. 자세한 내용은 다음 리소스를 참조하십시오.

경우에 따라 일부 라이브러리를 정적 및 일부 동적으로 연결해야 할 수도 있습니다. 이러한 상황은 몇 가지 도전 과제입니다.

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

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

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

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

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

프로그램을 연결하려면 먼저 라이브러리를 정적으로 연결(libfirst.a) 및 두 번째 동적으로 연결(libsecond.so).

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

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

동적으로 로드된 라이브러리(공유 오브젝트)는 soname 이라는 메커니즘을 사용하여 여러 호환 가능한 라이브러리 버전을 관리합니다.

foo 라이브러리 버전 X.Y 는 버전 번호에서 동일한 X 값을 가진 다른 버전과 ABI와 호환됩니다. 호환성을 유지하는 마이너 변경으로 숫자 Y 가 증가합니다. 호환성을 중단시키는 주요 변경 사항은 숫자 X 를 증가시킵니다.

실제 foo 라이브러리 버전 X.Y 는 libfoo.so.x.y 파일로 존재합니다. 라이브러리 파일 내에서 soname이 libfoo.so.x 값으로 기록되어 호환성을 나타냅니다.

애플리케이션이 빌드되면 링커에서 libfoo.so 파일을 검색하여 라이브러리를 찾습니다. 이 이름의 심볼릭 링크가 있어야 실제 라이브러리 파일을 가리키는 심볼릭 링크가 있어야 합니다. 그런 다음 링커는 라이브러리 파일에서 soname을 읽고 이를 애플리케이션 실행 파일에 기록합니다. 마지막으로 링커는 이름 또는 파일 이름이 아닌 soname을 사용하여 라이브러리에 대한 종속성을 선언하는 애플리케이션을 생성합니다.

런타임 동적 링커가 애플리케이션을 실행하기 전에 연결하면 애플리케이션 실행 파일에서 soname을 읽습니다. 이 soname은 libfoo.so.x 입니다. 이 이름의 심볼릭 링크가 있어야 실제 라이브러리 파일을 가리키는 심볼릭 링크가 있어야 합니다. 이렇게 하면 soname이 변경되지 않기 때문에 버전의 Y 구성 요소에 관계없이 라이브러리를 로드할 수 있습니다.

$ objdump -p somelibrary | grep SONAME

somelibrary 를 검사할 라이브러리의 실제 파일 이름으로 바꿉니다.

동적으로 연결된 라이브러리(공유 오브젝트)는 다음을 허용합니다.

다음 단계에 따라 소스에서 동적 라이브러리를 빌드하고 설치합니다.

오브젝트 파일을 특수 유형의 아카이브 파일로 변환하여 정적 연결을 위한 라이브러리를 만들 수 있습니다.

특정 프로젝트의 소스 파일에서 사용 가능한 양식(일반적으로 실행 파일)을 만들려면 몇 가지 필수 단계를 수행합니다. 작업 및 해당 시퀀스를 기록하여 나중에 반복할 수 있습니다.

Red Hat Enterprise Linux에는 이러한 목적을 위해 설계된 빌드 시스템인 GNU make 가 포함되어 있습니다.

옵션 없이 make 를 실행하면 현재 디렉터리에서 Makefile을 찾아 기본 대상에 도달하려고 시도합니다. 실제 Makefile 파일 이름은 Makefile,makefile 및 GNUmakefile 중 하나일 수 있습니다. 기본 대상은 Makefile 콘텐츠에서 결정됩니다.

일반적으로 Makefile에는 소스 파일을 컴파일하는 규칙, 결과 개체 파일을 연결하는 규칙 및 계층 구조의 맨 위 진입점 역할을 하는 대상이 포함됩니다.

단일 파일 hello.c 로 구성된 C 프로그램을 빌드하려면 다음 Makefile 을 고려해 보십시오.

all: hello

hello: hello.o
        gcc hello.o -o hello

hello.o: hello.c
        gcc -c hello.c -o hello.o

이 예에서는 대상에 도달하기 위해 hello 파일이 필요함 을 보여줍니다. hello를 얻으려면 hello .o (gcc로 링크됨 )가 필요하며 hello.c (gcc에 의해 컴파일됨 )에서 생성됩니다.

target all 은 마침표(.)로 시작하지 않는 첫 번째 대상이기 때문에 기본 대상입니다. 인수 없이 make 를 실행하면 현재 디렉터리에 이 Makefile 이 포함된 경우 실행 중인 make 와 같습니다.

CC=gcc
CFLAGS=-c -Wall
SOURCE=hello.c
OBJ=$(SOURCE:.c=.o)
EXE=hello

all: $(SOURCE) $(EXE)

$(EXE): $(OBJ)
        $(CC) $(OBJ) -o $@

%.o: %.c
        $(CC) $(CFLAGS) $< -o $@

clean:
        rm -rf $(OBJ) $(EXE)

이러한 Makefile에 소스 파일을 추가하려면 SOURCE 변수가 정의된 행에만 추가하면 됩니다.

이 예제의 단계에 따라 Makefile을 사용하여 샘플 C 프로그램을 빌드합니다.

make 에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.

Red Hat Enterprise Linux 8에서 GCC 툴체인은 GCC 8.2 릴리스 시리즈를 기반으로 합니다. Red Hat Enterprise Linux 7 이후 주요 변경 사항은 다음과 같습니다.

자세한 내용은 2.5.2절. “RHEL 8 GCC의 보안 개선 사항” 의 내용을 참조하십시오.

다음은 보안과 관련된 GCC 변경 사항이며 Red Hat Enterprise Linux 7.0 릴리스 이후 추가됩니다.

std:: string 및 std::list 에서 C++ ABI 변경

libstdc++ 라이브러리의 std::string 및 std::list 클래스의 ABI(Application Binary Interface)는 RHEL 7(GCC 4.8)과 RHEL 8(GCC 8) 간에 변경되어 C++11 표준을 준수합니다. libstdc++ 라이브러리는 이전 ABI와 새 ABI를 모두 지원하지만, 일부 다른 C++ 시스템 라이브러리는 지원하지 않습니다. 따라서 이러한 라이브러리에 대해 동적으로 연결되는 애플리케이션을 다시 빌드해야 합니다. 이는 C++98을 포함한 모든 C++ 표준 모드에 영향을 미칩니다. 또한 이전 ABI가 시스템 라이브러리와의 호환성을 유지하기 위해 RHEL 7용 Red Hat Developer Toolset 컴파일러로 구축된 애플리케이션에도 영향을 미칩니다.

GCC는 더 이상 Ada, Go 및 Objective C/C++ 코드를 빌드하지 않습니다.

Ada(GNAT), GCC Go 및 Objective C/C++ 언어에서 코드 빌드 기능이 GCC 컴파일러에서 제거되었습니다.

Go 코드를 빌드하려면 대신 Go Toolset을 사용합니다.

실행 코드를 디버깅하는 동안 두 가지 유형의 정보를 통해 프로그래머를 확장하고 바이너리 코드를 이해할 수 있습니다.

이러한 정보를 디버깅 정보라고 합니다.

Red Hat Enterprise Linux는 실행 바이너리, 공유 라이브러리 또는 debuginfo 파일에 ELF 형식을 사용합니다. 이러한 ELF 파일 내에 DWARF 형식은 디버그 정보를 유지하는 데 사용됩니다.

ELF 파일 내에 저장된 DWARF 정보를 표시하려면 readelf -w file 명령을 실행합니다.

디버깅 정보는 크기 때문에 기본적으로 실행 파일에 포함되지 않습니다. C 및 C++ 애플리케이션을 디버깅할 수 있도록 하려면 컴파일러에 이를 명시적으로 지시해야 합니다.

코드를 컴파일하고 연결할 때 GCC 를 사용하여 디버깅 정보를 생성할 수 있도록 하려면 -g 옵션을 사용합니다.

$ gcc ... -g ...

The debuginfo 및 debugsource 패키지에는 프로그램 및 라이브러리에 대한 디버깅 정보와 디버그 소스 코드가 포함되어 있습니다. Red Hat Enterprise Linux 리포지토리의 패키지에 설치된 애플리케이션 및 라이브러리의 경우 추가 채널에서 separate debuginfo 및 debugsource 패키지를 얻을 수 있습니다.

코드를 디버깅하려면 디버깅 정보가 필요합니다. 패키지에서 설치된 코드의 경우 gDB(GNU Debugger)는 누락된 디버그 정보를 자동으로 인식하고 패키지 이름을 해결하며 패키지를 가져오는 방법에 대한 구체적인 조언을 제공합니다.

실행 파일을 찾은 다음 이를 설치하는 패키지를 찾아 설치해야 하는 debuginfo 패키지를 수동으로 결정할 수 있습니다.

Red Hat Enterprise Linux에는 명령줄 사용자 인터페이스를 통해 프로그램 내에서 발생하는 상황을 조사할 수 있는 GNU 디버거(GDB)가 포함되어 있습니다.

프로세스를 검사하려면 GDB를 프로세스에 연결해야 합니다.

$ gdb program

program 을 파일 이름 또는 프로그램의 경로로 바꿉니다.

GDB는 프로그램의 실행을 시작하도록 설정합니다. run 명령으로 프로세스 실행을 시작하기 전에 중단점 및 the gdb 환경을 설정할 수 있습니다.

(gdb) file path/to/program

GDB 디버거가 프로그램에 연결되면 여러 명령을 사용하여 프로그램의 실행을 제어할 수 있습니다.

프로그램의 내부 변수 값을 표시하는 것은 프로그램이 수행하는 작업을 이해하는 데 중요합니다. GDB는 내부 변수를 검사하는 데 사용할 수 있는 여러 명령을 제공합니다. 다음은 다음 명령 중 가장 유용합니다.

대개는 작은 코드 부분만 조사됩니다. 중단점은 GDB가 코드의 특정 위치에서 프로그램의 실행을 중지하도록 지시하는 마커입니다. 중단점은 소스 코드 행과 가장 일반적으로 연관됩니다. 이 경우 중단자를 배치하려면 소스 파일 및 행 번호를 지정해야 합니다.

대부분의 경우 특정 데이터가 변경되거나 액세스될 때까지 프로그램을 실행하도록 하는 것이 유리합니다. 다음 예제는 가장 일반적인 사용 사례입니다.

일부 프로그램은 포크 또는 스레드를 사용하여 병렬 코드 실행을 수행합니다. 여러 동시 실행 경로를 디버깅하려면 특별한 고려 사항이 필요합니다.

GDB는 현재 스레드 의 개념을 사용합니다. 기본적으로 명령은 현재 스레드에만 적용됩니다.

Red Hat Enterprise Linux는 애플리케이션 상호 작용을 분석하기 위한 다양한 툴을 제공합니다.

strace 툴을 사용하면 애플리케이션에서 수행하는 시스템(커널) 호출을 모니터링할 수 있습니다.

$ strace ... |& tee your_log_file.log

ltrace 툴을 사용하면 라이브러리에서 사용할 수 있는 기능에 대한 애플리케이션의 호출을 모니터링할 수 있습니다(공유 오브젝트).

$ ltrace ... |& tee your_log_file.log

SystemTap 툴을 사용하면 커널 이벤트에 대한 사용자 지정 이벤트 핸들러를 등록할 수 있습니다. strace 툴과 비교하여 사용하기는 어렵지만 더 효율적이며 더 복잡한 처리 논리를 사용할 수 있습니다. strace.stp 라는 SystemTap 스크립트는 SystemTap과 함께 설치되며 SystemTap을 사용하여 strace 기능의 근사성을 제공합니다.

GNU Debugger(GDB)를 사용하면 프로그램 실행 중에 발생하는 다양한 상황에서 실행을 중지할 수 있습니다. 프로그램이 시스템 호출을 수행할 때 실행을 중지하려면 GDB catchpoint 를 사용합니다.

GNU Debugger(GDB)를 사용하면 프로그램 실행 중에 발생하는 다양한 상황에서 실행을 중지할 수 있습니다. 프로그램이 운영 체제에서 신호를 수신할 때 실행을 중지하려면 GDB catchpoint 를 사용합니다.

코어 덤프는 애플리케이션이 작동을 중지하고 ELF 형식으로 저장된 애플리케이션 메모리 부분의 사본입니다. 애플리케이션의 내부 변수 및 스택을 모두 포함하므로 애플리케이션의 최종 상태를 검사할 수 있습니다. 각 실행 파일 및 디버깅 정보로 보강된 경우 실행 중인 프로그램 분석과 유사한 방식으로 디버거를 사용하여 코어 덤프 파일을 분석할 수 있습니다.

Linux 운영 체제 커널은 이 기능이 활성화된 경우 코어 덤프를 자동으로 기록할 수 있습니다. 또는 실행 중인 애플리케이션에 신호를 보내 실제 상태와 관계없이 코어 덤프를 생성할 수 있습니다.

$ ulimit -a

애플리케이션 충돌을 기록하려면 코어 덤프 저장을 설정하고 시스템에 대한 정보를 추가합니다.

systemd 의 coredumpctl 도구는 충돌이 발생한 시스템의 코어 덤프 작업을 크게 간소화할 수 있습니다. 이 절차에서는 응답하지 않는 프로세스의 코어 덤프를 캡처하는 방법을 간략하게 설명합니다.

코어 덤프 디버깅의 워크플로를 사용하면 프로그램의 상태를 오프라인에서 분석할 수 있습니다. 경우에 따라 프로세스를 사용하여 환경에 액세스하기 어려운 경우와 같이 여전히 실행 중인 프로그램으로 이 워크플로를 사용할 수 있습니다. gcore 명령을 사용하여 실행 중인 동안 프로세스의 메모리를 덤프할 수 있습니다.

덤프되지 않은 프로세스 메모리를 표시할 수 있습니다. 이렇게 하면 리소스 및 프로세스 메모리에 중요한 데이터가 포함된 경우 추가 보안을 보장할 수 있습니다(예: 은행 또는 계정 애플리케이션 또는 전체 가상 시스템). 커널 코어 덤프(kdump)와 수동 코어 덤프(gcore, GDB)는 모두 이러한 방식으로 표시된 메모리를 덤프하지 않습니다.

경우에 따라 이러한 보호에 관계없이 프로세스 메모리의 전체 내용을 덤프해야 합니다. 다음 절차에서는 GDB 디버거를 사용하여 이 작업을 수행하는 방법을 설명합니다.

GCC Toolset 9는 다음 도구 및 버전을 제공합니다.

GCC Toolset의 GCC 컴파일러는 다음과 같은 C++ 표준을 사용할 수 있습니다.

모든 언어 표준은 표준 호환 변형이나 GNU 확장 모두에서 사용할 수 있습니다.

GCC Toolset과 함께 빌드된 개체를 RHEL 툴체인(특히 .o 또는. a 파일)과 혼합할 때 GCC Toolset 툴체인을 모든 링크에 사용해야 합니다. 이렇게 하면 GCC Toolset에서만 제공되는 최신 라이브러리 기능이 링크 시간에 해결됩니다.

$ scl enable gcc-toolset-9 'gcc -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-9 'gcc objfile.o -lsomelib'

이 권장 사항은 GCC 기본 Red Hat Enterprise Linux 버전을 사용하는 경우에도 적용됩니다.

$ scl enable gcc-toolset-9 'ld -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-9 'ld objfile.o -lsomelib'

이 권장 사항은 기본 Red Hat Enterprise Linux 버전 binutils 를 사용하는 경우에도 적용됩니다.

GCC Toolset 10은 다음 도구 및 버전을 제공합니다.

GCC Toolset의 GCC 컴파일러는 다음과 같은 C++ 표준을 사용할 수 있습니다.

모든 언어 표준은 표준 호환 변형이나 GNU 확장 모두에서 사용할 수 있습니다.

GCC Toolset과 함께 빌드된 개체를 RHEL 툴체인(특히 .o 또는. a 파일)과 혼합할 때 GCC Toolset 툴체인을 모든 링크에 사용해야 합니다. 이렇게 하면 GCC Toolset에서만 제공되는 최신 라이브러리 기능이 링크 시간에 해결됩니다.

$ scl enable gcc-toolset-10 'gcc -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-10 'gcc objfile.o -lsomelib'

이 권장 사항은 GCC 기본 Red Hat Enterprise Linux 버전을 사용하는 경우에도 적용됩니다.

$ scl enable gcc-toolset-10 'ld -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-10 'ld objfile.o -lsomelib'

이 권장 사항은 기본 Red Hat Enterprise Linux 버전 binutils 를 사용하는 경우에도 적용됩니다.

GCC Toolset 11은 다음과 같은 도구와 버전을 제공합니다.

GCC Toolset의 GCC 컴파일러는 다음과 같은 C++ 표준을 사용할 수 있습니다.

모든 언어 표준은 표준 호환 변형이나 GNU 확장 모두에서 사용할 수 있습니다.

GCC Toolset과 함께 빌드된 개체를 RHEL 툴체인(특히 .o 또는. a 파일)과 혼합할 때 GCC Toolset 툴체인을 모든 링크에 사용해야 합니다. 이렇게 하면 GCC Toolset에서만 제공되는 최신 라이브러리 기능이 링크 시간에 해결됩니다.

$ scl enable gcc-toolset-11 'gcc -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-11 'gcc objfile.o -lsomelib'

이 권장 사항은 GCC 기본 Red Hat Enterprise Linux 버전을 사용하는 경우에도 적용됩니다.

$ scl enable gcc-toolset-11 'ld -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-11 'ld objfile.o -lsomelib'

이 권장 사항은 기본 Red Hat Enterprise Linux 버전 binutils 를 사용하는 경우에도 적용됩니다.

GCC Toolset 12는 다음 도구 및 버전을 제공합니다.

GCC Toolset의 GCC 컴파일러는 다음과 같은 C++ 표준을 사용할 수 있습니다.

모든 언어 표준은 표준 호환 변형이나 GNU 확장 모두에서 사용할 수 있습니다.

GCC Toolset과 함께 빌드된 개체를 RHEL 툴체인(특히 .o 또는. a 파일)과 혼합할 때 GCC Toolset 툴체인을 모든 링크에 사용해야 합니다. 이렇게 하면 GCC Toolset에서만 제공되는 최신 라이브러리 기능이 링크 시간에 해결됩니다.

$ scl enable gcc-toolset-12 'gcc -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-12 'gcc objfile.o -lsomelib'

이 권장 사항은 GCC 기본 Red Hat Enterprise Linux 버전을 사용하는 경우에도 적용됩니다.

$ scl enable gcc-toolset-12 'ld -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-12 'ld objfile.o -lsomelib'

이 권장 사항은 기본 Red Hat Enterprise Linux 버전 binutils 를 사용하는 경우에도 적용됩니다.

GCC Toolset 12의 annobin 과 gcc 간의 동기화 문제로 인해 다음과 유사한 오류 메시지와 함께 컴파일이 실패할 수 있습니다.

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

이 문제를 해결하려면 annobin.so 파일에서 gcc-annobin.so 파일로 플러그인 디렉토리에 심볼릭 링크를 만듭니다.

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# ln -s annobin.so gcc-annobin.so

아키텍처 를 시스템에서 사용하는 아키텍처로 교체합니다.

GCC Toolset 13은 다음 툴과 버전을 제공합니다.

GCC Toolset의 GCC 컴파일러는 다음과 같은 C++ 표준을 사용할 수 있습니다.

모든 언어 표준은 표준 호환 변형이나 GNU 확장 모두에서 사용할 수 있습니다.

GCC Toolset과 함께 빌드된 개체를 RHEL 툴체인(특히 .o 또는. a 파일)과 혼합할 때 GCC Toolset 툴체인을 모든 링크에 사용해야 합니다. 이렇게 하면 GCC Toolset에서만 제공되는 최신 라이브러리 기능이 링크 시간에 해결됩니다.

$ scl enable gcc-toolset-13 'gcc -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-13 'gcc objfile.o -lsomelib'

이 권장 사항은 GCC 기본 Red Hat Enterprise Linux 버전을 사용하는 경우에도 적용됩니다.

$ scl enable gcc-toolset-13 'ld -lsomelib objfile.o'

이러한 방식으로 GCC Toolset의 라이브러리를 사용하면 링크러 오류 메시지 정의되지 않은 기호 참조가 생성됩니다. 이 문제를 방지하려면 표준 연결 방법을 따르고 오브젝트 파일을 지정하는 옵션 뒤에 라이브러리 추가 옵션을 지정합니다.

$ scl enable gcc-toolset-13 'ld objfile.o -lsomelib'

이 권장 사항은 기본 Red Hat Enterprise Linux 버전 binutils 를 사용하는 경우에도 적용됩니다.

경우에 따라 GCC Toolset 13의 annobin 과 gcc 간의 동기화 문제로 인해 다음과 유사한 오류 메시지와 함께 컴파일이 실패할 수 있습니다.

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

이 문제를 해결하려면 annobin.so 파일에서 gcc-annobin.so 파일로 플러그인 디렉토리에 심볼릭 링크를 만듭니다.

# cd /opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin
# ln -s annobin.so gcc-annobin.so

아키텍처 를 시스템에서 사용하는 아키텍처로 교체합니다.

GCC Toolset 13 컨테이너 이미지에서 제공되는 툴 버전은 GCC Toolset 13 구성 요소 버전과 일치합니다.

다음 섹션에서는 GCC Toolset 컨테이너 이미지에 액세스하고 실행하는 방법을 설명합니다.

이 예제에서는 GCC Toolset 13 툴체인 컨테이너 이미지를 가져와서 사용하는 방법을 보여줍니다.

다음 섹션에서는 다음 방법을 설명합니다.

다음 섹션에서는 annocheck를 사용하여 검사하는 방법을 설명합니다.

annobin 을 사용하면 바이너리 크기가 증가합니다. annobin 으로 컴파일된 바이너리의 크기를 줄이기 위해 중복 annobin 노트를 제거하면 됩니다. 중복 annobin 노트를 제거하려면 binutils 패키지의 일부인 objcopy 프로그램을 사용합니다.

GCC Toolset 12의 annobin 과 gcc 간의 동기화 문제로 인해 다음과 유사한 오류 메시지와 함께 컴파일이 실패할 수 있습니다.

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

이 문제를 해결하려면 annobin.so 파일에서 gcc-annobin.so 파일로 플러그인 디렉토리에 심볼릭 링크를 만듭니다.

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# ln -s annobin.so gcc-annobin.so

아키텍처 를 시스템에서 사용하는 아키텍처로 교체합니다.