バイナリパッケージはホストシステムからどのように分離されますか？

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はこのような状況の一例に過ぎません。私は、パッケージマネージャがソフトウェアがホストシステムのオプションの依存関係に接続するのを停止するために使用できるより一般的な方法を探しています。