바이너리 패키지는 호스트 시스템에서 어떻게 격리됩니까?

binutils, gcc 및 호스트 시스템에 있는 내용에 따라 다른 라이브러리에 연결되는 기타 패키지용 바이너리 패키지(rpm, deb 등)를 어떻게 생성합니까?

LFS 프로젝트에서는 호스트 시스템에서 새 시스템을 격리하기 위해 새 시스템에 대해 서로 다른 대상 트리플을 사용하여 크로스 컴파일을 위조합니다(여기). 이렇게 하면 호스트 시스템에만 존재하는 라이브러리에 대해 패키지가 링크되는 것을 방지할 수 있습니다. 그러나 유사한 접근 방식을 사용하여 바이너리 패키지를 빌드하는 경우 해당 패키지는 빌드된 시스템과 분명히 다른 대상 트리플을 갖게 됩니다.

나는 읽었다이것gcc에 대한 호스트 격리 구축을 논의하는 이메일 통신입니다. 그러나 결론은 LFS와 같은 가짜 크로스 컴파일이 호스트 시스템에서 격리된 gcc를 빌드하는 유일한 합리적인 방법이라는 것입니다.

--prefix 및 --with-sysroot를 빈 디렉토리로 설정하여 binutils를 빌드하려고 시도했지만 결과 바이너리가 내 호스트 시스템의 libfl에 연결되었습니다.

편집하다:

내 원래 설명이 불분명하다고 생각합니다. 좀 더 구체적인 예를 들어보겠습니다.

GNU 바이너리틸GNU flex에 의존하지 않습니다., 내 아치 시스템에서 실행하여 이를 확인할 수 있었고 ldd /usr/bin/ar에 연결되지 않은 것을 발견했습니다 libfl.so. 그럼에도 불구하고 Flex는 여전히 내 호스트 시스템에 설치되어 있습니다. 이제 binutils 바이너리를 컴파일하여 동일한 아키텍처를 사용하는 다른 시스템에 복사하고 싶습니다. 이 새로운 시스템에는 GNU Flex가 설치되어 있지 않지만 binutils는 GNU Flex에 의존하지 않으므로 이는 문제가 되지 않습니다. 문제는 호스트 시스템에서 binutils를 컴파일할 때 여기에 링크된다는 것입니다 libfl.so.2! binuitls를 빌드할 때 flex가 설치되어 있다는 것을 "알아서" 링크하기로 결정하기 때문이라고 생각합니다. 호스트 시스템에 존재하는 선택적 종속성(flex 등)에 연결하지 않고 소프트웨어(binutils 등)를 컴파일하는 방법을 알고 싶습니다. 확실히 바이너리 패키지 관리자가 소프트웨어를 컴파일하려고 할 때 동일한 문제에 직면하게 될까요?

Binutils는 이러한 상황의 한 예일 뿐입니다. 저는 패키지 관리자가 소프트웨어가 호스트 시스템의 선택적 종속성에 연결되는 것을 중지하는 데 사용할 수 있는 보다 일반적인 방법을 찾고 있습니다.