차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- linuxfromscratch:12.1:032-toolchain_technical_notes [2024/06/14 15:17] – [ii. 툴체인 기술 설명] baecy
+++ linuxfromscratch:12.1:032-toolchain_technical_notes [2024/06/14 15:55] (현재) – [기타 절차적 세부 사항] baecy
@@ 줄 21: / 줄 21: @@
 <WRAP info center round 90%>
 **참고** \\
-LFS 책은 크로스(또는 네이티브) 툴체인을 빌드하는 일반적인 튜토리얼이 아니며 포함하지도 않습니다. 이 책의 명령어를 LFS 빌드 이외의 다른 목적으로 크로스 툴체인에 사용하지 마시고, 자신이 하고 있는 일이 무엇인지 잘 이해하지 못한다면 사용하지 마세요.
+LFS 책은 크로스(또는 네이티브) 툴체인을 빌드하는 일반적인 튜토리얼이 아니며 포함하지도 않습니다. 자신이 하고 있는 일이 무엇인지 명확하게 이해하지 못한다면 이 책의 명령어를 LFS 빌드 이외의 다른 목적의 크로스 툴체인에 사용하지 마세요.
 </WRAP>
-크로스 컴파일에는 몇 가지 개념이 포함되어 있습니다. 이 섹션은 처음 읽을 때는 생략할 수 있지만, 나중에 다시 읽어보면 프로세스를 더 잘 이해하는 데 도움이 될 것입니다.
+크로스 컴파일에는 몇 가지 개념이 포함되어 있습니다. 이 섹션은 처음 읽을 때는 생략할 수 있지만, 나중에 다시 읽어보면 과정을 더 잘 이해하는 데 도움이 될 것입니다.
 먼저 이 장에서 용되는 몇 가지 용어를 정의해 보겠습니다.
   * **Build** \\ 프로그램을 빌드하는 머신입니다. 이 머신을 "호스트"라고도 합니다.
-  * **Host** \\ 빌드된 프로그램이 실행될 컴퓨터/시스템입니다. 이 "호스트"의 사용은 다른 섹션에서와 동일하지 않다는 점에 유의하세요.
+  * **Host** \\ 빌드된 프로그램이 실행될 컴퓨터/시스템입니다. 이 "호스트" 명칭의 사용은 다른 장의 그것과 동일하지 않다는 점에 유의하세요.
   * **Target** \\ 컴파일러에만 사용됩니다. 컴파일러가 대상 코드를 생성하는 컴퓨터입니다. 빌드와 호스트 모두와 다를 수 있습니다.
-예를 들어 다음 시나리오("캐나다 크로스"라고도 함)를 상상해 보겠습니다. 느린 머신에만 컴파일러가 있고, 이를 머신 A라고 하고 컴파일러를 ccA라고 합니다. 또한 빠른 머신(B)도 있지만 (B)용 컴파일러는 없으며, 세 번째 느린 머신(C)용 코드를 생성하려고 합니다. 머신 C용 컴파일러를 세 단계로 빌드하겠습니다.
+예를 들어 다음 시나리오("Canadian Cross"라고도 함)를 상상해 보겠습니다. 느린 머신에만 컴파일러가 있고, 이를 머신 A라고 하고 컴파일러를 ccA라고 합니다. 또한 빠른 머신(B)도 있지만 (B)용 컴파일러는 없으며, 세 번째 느린 머신(C)에서 실행되는 코드를 생성하려고 합니다. 머신 C용 컴파일러를 세 단계로 빌드하겠습니다.
 ^  Stage  ^  Build  ^  Host ^  Target  ^  Action  ^
@@ 줄 38: / 줄 38: @@
 |  3  |  B  |  C  |  C  | 머신 **B**에서 ''cc2''을 이용해서 ''컴파일러 ccC'' 빌드  |
-그런 다음 빠른 머신 B에서 cc2를 사용하여 머신 C에 필요한 모든 프로그램을 컴파일할 수 있습니다. B가 C용으로 제작된 프로그램을 실행할 수 없으며 머신 C 자체가 실행될 때까지 새로 빌드한 프로그램을 테스트할 방법이 없다는 점에 유의하세요. 예를 들어 ccC에서 테스트 스위트를 실행하려면 네 번째 단계를 추가해야 할 수 있습니다.
+그런 다음 빠른 머신 B에서 cc2를 사용하여 머신 C에 필요한 모든 프로그램을 컴파일할 수 있습니다. B가 C용으로 제작된 프로그램을 실행할 수 없으며 머신 C 자체가 실행될 때까지 새로 빌드한 프로그램을 테스트할 방법이 없다는 점에 유의하세요. 예를 들어 ccC의 테스트 스위트를 실행하려면 네 번째 단계를 추가해야 할 수 있습니다.
 ^  Stage  ^  Build  ^  Host ^  Target  ^  Action  ^
@@ 줄 51: / 줄 51: @@
 <WRAP info center round 90%>
 **참고** \\
-이 책에서 크로스 컴파일된 모든 패키지는 autoconf-base 빌드 시스템을 사용합니다. Autoconf-base 빌드 시스템은 시스템 트리플렛이라고 하는 cpu-vendor-kernel-os 형식의 시스템 유형을 허용합니다. 공급업체 필드는 관련이 없는 경우가 많으므로 자동 설정에서는 생략할 수 있습니다.
+이 책에서 크로스 컴파일하는 모든 패키지는 autoconf-base 빌드 시스템을 사용합니다. Autoconf-base 빌드 시스템은 시스템 트리플렛(삼중 항)이라고 하는 cpu-vendor-kernel-os 형식의 시스템 유형을 허용합니다. 공급업체 필드(vendor)는 관련이 없는 경우가 많으므로 autoconf에서는 생략할 수 있습니다.
-눈치 빠른 독자라면 왜 "삼중 항"이 네 가지 구성 요소 이름을 가리키는지 궁금할 것입니다. 커널 필드와 OS 필드는 하나의 "시스템" 필드로 시작되었습니다. 이러한 세 개의 필드 형식은 오늘날에도 일부 시스템(예: ''x86_64-unknown-freebsd'')에서 여전히 유효합니다. 그러나 두 시스템이 동일한 커널을 공유하면서도 너무 달라서 동일한 삼중항을 사용하여 설명할 수 없습니다. 예를 들어 휴대폰에서 실행되는 Android는 동일한 유형의 CPU(ARM64)에서 실행되고 동일한 커널(Linux)을 사용하지만 ARM64 서버에서 실행되는 Ubuntu와는 완전히 다릅니다.
+눈치 빠른 독자라면 왜 "삼중 항"이 네 가지 구성 요소 이름을 가리키는지 궁금할 것입니다. 커널 필드와 OS 필드는 하나의 "시스템" 필드로 시작되었습니다. 이러한 세 개의 필드 형식은 오늘날에도 일부 시스템(예: ''x86_64-unknown-freebsd'')에서 여전히 유효합니다. 그러나 두 시스템이 동일한 커널을 공유하면서도 너무도 다른 경우 동일한 삼중항을 사용하여 설명할 수 없습니다. 예를 들어 휴대폰에서 실행되는 Android는 동일한 유형의 CPU(ARM64)에서 실행되고 동일한 커널(Linux)을 사용하지만 ARM64 서버에서 실행되는 Ubuntu와는 완전히 다릅니다.
 에뮬레이션 계층이 없으면 휴대폰에서 서버용 실행 파일을 실행할 수 없으며 그 반대의 경우도 마찬가지입니다. 따라서 이러한 시스템을 명확하게 지정하기 위해 "시스템" 필드를 커널 및 OS 필드로 구분했습니다. 이 예제에서 Android 시스템은 ''aarch64-unknown-linux-android''로 지정되고 Ubuntu 시스템은 ''aarch64-unknown-linux-gnu''로 지정됩니다.
-"삼중 항"이라는 단어는 어휘집에 계속 포함되어 있습니다. 시스템 트리플렛을 확인하는 간단한 방법은 많은 패키지의 소스와 함께 제공되는 **config.guess** 스크립트를 실행하는 것입니다. binutils 소스의 압축을 풀고 **./config.guess** 스크립트를 실행한 다음 출력을 기록해 두세요. 예를 들어 32비트 인텔 프로세서의 경우 출력은 //i686-pc-linux-gnu//입니다. 64비트 시스템에서는 //x86_64-pc-linux-gnu//가 됩니다. 대부분의 리눅스 시스템에서는 더 간단한 **gcc -dumpmachine** 명령으로 비슷한 정보를 얻을 수 있습니다.
+"삼중 항"이라는 단어는 사전에 계속 포함되어 있습니다. 시스템의 트리플렛을 확인하는 간단한 방법은 많은 패키지의 소스와 함께 제공되는 **config.guess** 스크립트를 실행하는 것입니다. binutils 소스의 압축을 풀고 **./config.guess** 스크립트를 실행한 다음 출력을 기록해 두세요. 예를 들어 32비트 인텔 프로세서의 경우 출력은 //i686-pc-linux-gnu//입니다. 64비트 시스템에서는 //x86_64-pc-linux-gnu//가 됩니다. 대부분의 리눅스 시스템에서는 더 간단한 **gcc -dumpmachine** 명령으로 비슷한 정보를 얻을 수 있습니다.
-또한 동적 로더라고도 하는 플랫폼의 동적 링커의 이름을 알고 있어야 합니다(binutils의 일부인 표준 링커 **ld**와 혼동하지 마세요). 패키지 glibc에서 제공하는 동적 링커는 프로그램에 필요한 공유 라이브러리를 찾아서 로드하고 프로그램을 실행할 준비를 한 다음 실행합니다. 32비트 Intel 시스템의 동적 링커 이름은 ''ld-linux.so.2''이며, 64비트 시스템에서는 ''ld-linux-x86-64.so.2''입니다. 동적 링커의 이름을 확인하는 가장 확실한 방법은 다음과 같이 실행하여 호스트 시스템에서 임의의 바이너리를 검사하고 출력을 메모하는 것입니다: **readelf -l <바이너리 파일명> | grep interpreter**. 모든 플랫폼을 포괄하는 권위 있는 참조는 glibc 소스 트리의 루트에 있는 ''shlib-versions'' 파일에 있습니다.
+또한 동적 로더라고도 하는 플랫폼의 동적 링커의 이름을 알고 있어야 합니다(binutils의 일부인 표준 링커 **ld**와 혼동하지 마세요). 패키지 glibc에서 제공하는 동적 링커는 프로그램에 필요한 공유 라이브러리를 찾아서 로드하고 프로그램을 실행할 준비를 한 다음 실행합니다. 32비트 Intel 시스템의 동적 링커 이름은 ''ld-linux.so.2''이며, 64비트 시스템에서는 ''ld-linux-x86-64.so.2''입니다. 동적 링커의 이름을 확인하는 가장 확실한 방법은 다음과 같이 실행하여 호스트 시스템에서 임의의 바이너리를 검사하고 출력을 메모하는 것입니다: **readelf -l <바이너리 파일명> | grep interpreter**. 모든 플랫폼을 포괄하는 참조는 glibc 소스 트리의 루트에 있는 ''shlib-versions'' 파일에 있습니다.
 </WRAP>
-LFS에서 교차 컴파일을 가장하기 위해 호스트 삼중 항의 이름을 약간 조정하여 ''LFS_TGT'' 변수의 "vendor" 필드를 "lfs"로 변경합니다. 또한 크로스 링커와 크로스 컴파일러를 빌드할 때 필요한 호스트 파일을 찾을 수 있는 위치를 알려주기 위해 //--with-sysroot// 옵션을 사용합니다. 이렇게 하면 [[.:06-cross_compiling_temporary_tools|6장]]에서 빌드한 다른 어떤 프로그램도 빌드 머신의 라이브러리에 링크할 수 없게 됩니다. 두 단계만 필수이며 테스트를 위해 한 단계가 더 필요합니다.
+LFS에서 크로스 컴파일을 가장하기 위해 호스트 삼중 항의 이름을 약간 조정하여 ''LFS_TGT'' 변수의 "vendor" 필드를 "lfs"로 변경합니다. 또한 크로스 링커와 크로스 컴파일러를 빌드할 때 필요한 호스트 파일을 찾을 수 있는 위치를 알려주기 위해 //--with-sysroot// 옵션을 사용합니다. 이렇게 하면 [[.:06-cross_compiling_temporary_tools|6장]]에서 빌드한 다른 어떤 프로그램도 빌드 머신의 라이브러리에 링크할 수 없게 됩니다. 두 단계만 필수이며 테스트를 하기 위해서 한 단계가 더 필요합니다.
 ^  Stage  ^  Build  ^  Host  ^  Target  ^  Action  ^
@@ 줄 79: / 줄 79: @@
 따라서 gcc 2단계를 빌드할 때 빌드 시스템에 cc1로 libgcc 및 libstdc++를 재빌드하도록 지시하지만, libstdc++는 이전의 제한된 빌드 대신 새로 재빌드된 libgcc에 링크합니다. 이렇게 하면 재빌드된 libstdc++가 완전히 작동합니다.
-[[.:08-installing_basic_system_software|8장]](또는 "3단계")에서는 LFS 시스템에 필요한 모든 패키지를 빌드합니다. 이전 장에서 패키지가 이미 LFS 시스템에 설치되어 있더라도 패키지를 다시 빌드합니다. 이러한 패키지를 다시 빌드하는 주된 이유는 패키지를 안정적으로 만들기 위해서입니다. 완성된 LFS 시스템에 LFS 패키지를 다시 설치하는 경우 다시 설치된 패키지의 내용은 [[.:08-installing_basic_system_software|8장]]에서 처음 설치했을 때와 동일한 패키지 내용이어야 합니다. [[.:06-cross_compiling_temporary_tools|6장]] 또는 [[.:07-entering_chroot_and_building_additional_tempory_tools|7장]]에 설치된 임시 패키지는 이 요구 사항을 충족할 수 없는데, 그 이유는 일부 패키지가 선택적 종속성 없이 빌드되고 자동 컴파일로 인해 [[.:06-cross_compiling_temporary_tools|6장]]에서 일부 기능 검사를 수행할 수 없기 때문에 임시 패키지에 선택적 기능이 부족하거나 최적이 아닌 코드 루틴이 사용되기 때문입니다. 또한 패키지를 다시 빌드하는 사소한 이유는 테스트 스위트를 실행하기 위해서입니다.
+[[.:08-installing_basic_system_software|8장]](또는 "3단계")에서는 LFS 시스템에 필요한 모든 패키지를 빌드합니다. 이전 장에서 패키지가 이미 LFS 시스템에 설치되어 있더라도 패키지를 다시 빌드합니다. 이러한 패키지를 다시 빌드하는 주된 이유는 패키지를 안정적으로 만들기 위해서입니다. 완성된 LFS 시스템에 LFS 패키지를 다시 설치하는 경우 다시 설치된 패키지의 내용은 [[.:08-installing_basic_system_software|8장]]에서 처음 설치했을 때와 동일한 패키지 내용이어야 합니다. [[.:06-cross_compiling_temporary_tools|6장]] 또는 [[.:07-entering_chroot_and_building_additional_tempory_tools|7장]]에 설치된 임시 패키지는 이 요구 사항을 충족할 수 없는데, 그 이유는 일부 패키지가 선택적 종속성 없이 빌드되고 자동 컴파일로 인해 [[.:06-cross_compiling_temporary_tools|6장]]에서 일부 기능 검사를 수행할 수 없기 때문에 임시 패키지에 선택적 기능이 부족하거나 최적이 아닌 코드 루틴이 사용되기 때문입니다. 또한 패키지를 다시 빌드하는 이유중에 하나는 테스트 스위트를 실행하기 위해서입니다.
 ----
-==== 기타 절차적 세부 사항 ====
+==== 세부 진행 사항 ====
 크로스 컴파일러는 최종 시스템의 일부가 아니므로 별도의 ''$LFS/tools'' 디렉터리에 설치됩니다.
-Binutils가 먼저 설치되는 이유는 gcc와 glibc의 **configure** 실행이 어셈블러와 링커에서 다양한 기능 테스트를 수행하여 어떤 소프트웨어 기능을 활성화 또는 비활성화할지 결정하기 때문입니다. 이것은 처음에 생각하는 것보다 더 중요합니다. gcc 또는 glibc를 잘못 구성하면 툴체인이 미묘하게 손상될 수 있으며, 이러한 손상으로 인한 영향은 전체 배포의 빌드가 거의 끝날 때까지 나타나지 않을 수 있습니다. 테스트 스위트 실패는 일반적으로 너무 많은 추가 작업을 수행하기 전에 이 오류를 강조 표시합니다.
+Binutils가 먼저 설치되는 이유는 gcc와 glibc의 **configure** 실행이 어셈블러와 링커에서 다양한 기능 테스트를 수행하여 어떤 소프트웨어 기능을 활성화 또는 비활성화할지 결정하기 때문입니다. 이 첫 과정은 생각보다 매우 중요합니다. gcc 또는 glibc를 잘못 구성하면 툴체인이 미묘하게 손상될 수 있으며, 이러한 손상으로 인한 영향은 전체 배포의 빌드가 거의 끝날 때까지 나타나지 않을 수 있습니다. 테스트 스위트 실패는 일반적으로 너무 많은 추가 작업을 수행하기 전에 이 오류를 강조 표시합니다.
-Binutils는 어셈블러와 링커를 ''$LFS/tools/bin''과 ''$LFS/tools/$LFS_TGT/bin''의 두 위치에 설치합니다. 한 위치의 도구는 다른 위치에 하드 링크됩니다. 링커의 중요한 측면은 라이브러리 검색 순서입니다. **ld**에 //--verbose// 플래그를 전달하면 자세한 정보를 얻을 수 있습니다. 예를 들어, **$LFS_TGT-ld --verbose | grep SEARCH**는 현재 검색 경로와 그 순서를 보여줍니다. (이 예제는 //lfs// 사용자로 로그인한 상태에서만 표시된 대로 실행할 수 있습니다. 나중에 이 페이지로 돌아오면 **$LFS_TGT-ld**를 **ld**로 바꾸세요).
+Binutils는 어셈블러와 링커를 ''$LFS/tools/bin''과 ''$LFS/tools/$LFS_TGT/bin''의 두 위치에 설치합니다. 한 위치의 도구는 다른 위치에 하드 링크됩니다. 링커의 중요한 기능은 라이브러리 검색 순서입니다. **ld**에 //--verbose// 플래그를 전달하면 자세한 정보를 얻을 수 있습니다. 예를 들어, **$LFS_TGT-ld --verbose | grep SEARCH**는 현재 검색 경로와 그 순서를 보여줍니다. (이 예제는 //lfs// 사용자로 로그인한 상태에서만 표시된 대로 실행할 수 있습니다. 나중에 이 페이지로 돌아오면 **$LFS_TGT-ld**를 **ld**로 바꾸세요).
 다음으로 설치되는 패키지는 gcc입니다. **configure**를 실행하는 동안 볼 수 있는 예는 다음과 같습니다.
@@ 줄 101: / 줄 101: @@
 프로그램을 컴파일하는 동안 -v 명령줄 옵션을 전달하면 **gcc**에서 자세한 정보를 얻을 수 있습니다. 예를 들어 **$LFS_TGT-gcc -v example.c**(또는 나중에 다시 돌아오는 경우 **$LFS_TGT-** 없이)는 포함된 헤더에 대한 **gcc**의 검색 경로와 순서를 포함하여 전처리기, 컴파일 및 어셈블리 단계에 대한 자세한 정보를 표시합니다.
-다음은 처리된 Linux API 헤더입니다. 이를 통해 표준 C 라이브러리(glibc)가 Linux 커널이 제공하는 기능과 인터페이스할 수 있습니다.
+다음은 처리된 Linux API 헤더입니다. 이를 통해 표준 C 라이브러리(glibc)가 Linux 커널이 제공하는 기능과 연동될 수 있습니다.
-다음은 glibc입니다. glibc를 빌드할 때 가장 중요한 고려 사항은 컴파일러, 바이너리 도구 및 커널 헤더입니다. 컴파일러는 일반적으로 configure 스크립트에 전달된 //--host// 매개변수와 관련된 컴파일러(예: 우리의 경우 컴파일러는 **$LFS_TGT-gcc**)를 사용하므로 문제가 되지 않습니다. 바이너리 도구와 커널 헤더는 조금 더 복잡할 수 있습니다. 따라서 위험을 감수하지 않고 사용 가능한 구성 스위치를 사용하여 올바른 선택을 적용합니다. **configure**를 실행한 후 빌드 디렉터리에 있는 ''config.make'' 파일의 내용을 확인하여 모든 중요한 세부 정보를 확인하세요. 사용할 바이너리 도구를 제어하기 위해 //CC="$LFS_TGT-gcc"//(''$LFS_TGT''가 확장된 상태)를 사용하고 컴파일러의 포함 검색 경로를 제어하기 위해 -//nostdinc// 및 //-isystem// 플래그를 사용하는 것을 주목하세요. 이러한 항목은 빌드 기계 측면에서 매우 자급자족적이며 일반적으로 도구 체인 기본값에 의존하지 않는 glibc 패키지의 중요한 측면을 강조합니다.
+다음은 glibc입니다. glibc를 빌드할 때 가장 중요한 고려 사항은 컴파일러, 바이너리 도구 및 커널 헤더입니다. 컴파일러는 일반적으로 configure 스크립트에 전달된 //--host// 매개변수와 관련된 컴파일러(예: 우리의 경우 컴파일러는 **$LFS_TGT-gcc**)를 사용하므로 문제가 되지 않습니다. 바이너리 도구와 커널 헤더는 조금 더 복잡할 수 있습니다. 따라서 위험을 감수하지 않고 사용 가능한 구성 스위치를 사용하여 올바른 선택을 적용합니다. **configure**를 실행한 후 빌드 디렉터리에 있는 ''config.make'' 파일의 내용을 확인하여 모든 중요한 세부 정보를 확인하세요. 사용할 바이너리 도구를 제어하기 위해 //CC="$LFS_TGT-gcc"//(''$LFS_TGT''가 확장된 상태)를 사용하고 컴파일러의 포함 검색 경로를 제어하기 위해 -//nostdinc// 및 //-isystem// 플래그를 사용하는 것을 주목하세요. 이러한 항목은 빌드 기계에 대해 독립적이며, 일반적으로 툴체인 기본값에 의존하지 않는 glibc 패키지를 빌드하도록 합니다.
-위에서 언급했듯이 표준 C++ 라이브러리가 다음에 컴파일되고, [[06-cross_compiling_temporary_tools|6장]]에서는 빌드 시 순환 종속성을 끊기 위해 교차 컴파일해야 하는 다른 프로그램이 이어서 컴파일됩니다. 이러한 모든 패키지의 설치 단계에서는 DESTDIR 변수를 사용하여 LFS 파일시스템에 강제로 설치합니다.
+위에서 언급했듯이 표준 C++ 라이브러리가 다음에 컴파일되고, [[06-cross_compiling_temporary_tools|6장]]에서는 빌드 시 순환 종속성을 끊기 위해 교차 컴파일해야 하는 다른 프로그램이 이어서 컴파일됩니다. 이러한 모든 패키지의 설치 단계에서는 ''DESTDIR'' 변수를 사용하여 LFS 파일시스템에 설치합니다.
-[[06-cross_compiling_temporary_tools|6장]] 마지막에 네이티브 LFS 컴파일러가 설치됩니다. 먼저 다른 프로그램과 동일한 DESTDIR 디렉터리에 binutils-pass2가 빌드된 다음, 중요하지 않은 일부 라이브러리를 생략한 두 번째 gcc 패스가 빌드됩니다. gcc의 구성 스크립트에 있는 이상한 로직으로 인해 호스트가 대상과 동일하지만 빌드 시스템과 다른 경우 ''CC_FOR_TARGET''이 **cc**로 끝납니다. 그렇기 때문에 구성 옵션 중 하나로 //CC_FOR_TARGET=$LFS_TGT-gcc//가 명시적으로 선언됩니다.
+[[06-cross_compiling_temporary_tools|6장]] 마지막에 네이티브 LFS 컴파일러가 설치됩니다. 먼저 다른 프로그램과 동일한 ''DESTDIR'' 디렉터리에 binutils-pass2가 빌드된 다음, 중요하지 않은 일부 라이브러리를 생략된 gcc-pass2가 빌드됩니다. gcc의 설정 스크립트에 있는 이상한 로직으로 인해 호스트가 대상과 동일하지만 빌드 시스템과 다른 경우 ''CC_FOR_TARGET''이 **cc**로 끝납니다. 그렇기 때문에 구성 옵션 중 하나로 //CC_FOR_TARGET=$LFS_TGT-gcc//가 명시적으로 선언됩니다.
-[[.:07-entering_chroot_and_building_additional_tempory_tools|7장]]에서 루트 환경으로 들어가면 툴체인의 올바른 작동에 필요한 프로그램의 임시 설치가 수행됩니다. 이 시점부터 핵심 툴체인은 독립적이고 자체 호스팅됩니다. [[.:08-installing_basic_system_software|8장]]에서는 완전한 기능을 갖춘 시스템에 필요한 모든 패키지의 최종 버전을 빌드, 테스트 및 설치합니다.
+[[.:07-entering_chroot_and_building_additional_tempory_tools|7장]]에서 //chroot// 환경으로 들어가면 툴체인의 올바른 작동에 필요한 프로그램의 임시 설치가 수행됩니다. 이 시점부터 핵심 툴체인은 독립적이고 자체적으로 호스팅됩니다. [[.:08-installing_basic_system_software|8장]]에서는 완전한 기능을 갖춘 시스템에 필요한 모든 패키지의 최종 버전을 빌드하고 테스트 및 설치합니다.