차이

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

--- linuxfromscratch:12.1:032-toolchain_technical_notes [2024/06/14 15:38] – [LFS용 교차 컴파일 구현하기] baecy
+++ linuxfromscratch:12.1:032-toolchain_technical_notes [2024/06/14 15:55] (현재) – [기타 절차적 세부 사항] baecy
@@ 줄 83: / 줄 83: @@
 ----
-==== 기타 절차적 세부 사항 ====
+==== 세부 진행 사항 ====
 크로스 컴파일러는 최종 시스템의 일부가 아니므로 별도의 ''$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장]]에서는 완전한 기능을 갖춘 시스템에 필요한 모든 패키지의 최종 버전을 빌드하고 테스트 및 설치합니다.