둘 다선형 FS그리고CLFS빌드하기 전에 GCC 소스에 패치를 적용하세요.
CLFS 패치는 LFS 패치보다 조금 더 복잡하지만 공통점은 동적 링커를 찾는 데 사용되는 경로를 변경한다는 것입니다. 이 경우 새 버전의 glibc가 빌드될 위치로 이동됩니다.
적어도 CLFS의 경우 크로스 툴체인을 구축하고 있으며 아마도 이 체인으로 구축된 어떤 것도 빌드 머신에서 실행할 수 없을 것이기 때문에 GCC가 프로그램에서 다음을 찾도록 하는 것은 아무런 차이가 없습니다. 동적 링커. 이것은 결코 발생하지 않는 런타임 작업이 아닌가? 또한 이 GCC를 사용하여 공유 라이브러리가 필요한 바이너리를 빌드하고 이를 타겟에서 실행하려고 하면 이제 동적 링커에 대한 경로가 잘못되지 않을까요?
또한 (C)LFS를 사용하면 STANDARD_STARTFILE_PREFIX_X을 가리키도록 수정할 수 있습니다 $INSTALL_PATH/tools/lib/. 이를 지정하면 해당 경로가 확인되지 않습니까 --with-sysroot? --with-sysroot접두사 또는 .--preint-search-dirs--with-sysroot
답변1
링크한 페이지는 LFS 6장의 최종 시스템을 구축하는 데 사용되는 임시 툴체인을 구축하는 데 사용됩니다. 이것GCC 6장패치 없이 컴파일되었습니다. 임시 도구 모음의 패치는 호스트 시스템에서 사용하는 도구에 관계없이 패키지의 추가 컴파일을 허용하는 데에만 사용됩니다.
답변2
(C)LFS는 빌드 머신과 가능한 한 접촉이 적은 Linux 시스템을 구축하기 위해 매우 열심히 노력합니다. 따라서 일부 단계는 불필요하거나 중복되거나 고안된 것처럼 보일 수 있습니다. 주요 문제를 해결하는 CLFS 프로세스(일부)는 다음과 같습니다.
- Ch5: 교차 binutils
- Ch5: 최초의 걸프만 횡단 협력
- Ch5: Glibc(크로스 컴파일러 및 대상 네이티브 컴파일러에서 사용할 수 있음), 접두사로 설치됨
/tools - Ch5: 크로스 gcc의 두 번째 패스입니다. 동적 링커 경로 패치는 $CLFS가 대상 파일 시스템의 루트인
/tools심볼릭 링크인 을 가리키도록 여기에 적용됩니다.$CLFS/tools - Ch6: 두 번째 cross-gcc 패스를 사용하여 대상에서 기본적으로 실행되는 gcc 버전을 포함하여 대상에 기본으로 제공되는 여러 가지 새로운 도구를 빌드합니다. 이 목록에서 눈에 띄게 누락된 것은 glibc의 또 다른 복사본입니다. 지금은 이전 빌드에서 수행되므로 이는 필요하지 않습니다.
/toolsCh10: 이제 빌드 머신과 같은 위치에 있는 대상 시스템으로 부팅/chroot합니다 . 이를 통해 이전에 빌드된 도구(네이티브로)가 동적 링커에 액세스할 수 있습니다. 이제 glibc를 다시 만들 것이지만 이번에는/usr(대신/tools/usr) 표준으로 들어갈 것입니다.
문제의 원인은 동적 링커 경로 및 빌드 시스템과 관련하여 발생한다는 사실과 관련이 있습니다. 대답은 기본적으로 OP(나)가 /tools 사이에 심볼릭 링크가 어떻게 존재하는지 고려하지 않았고 ${CLFS}/tools/tools를 링커의 루트 경로로 만들기 위해 패치를 적용했다는 것입니다.
이 질문에 대한 답변이 없습니다 STANDARD_STARTFILE_PREFIX_X.