私のアプリケーションは、Debianポリシールールに従って、バイナリと一緒にパッケージ化する必要があるいくつかのプライベート共有ライブラリを使用しています
ユーザーが手動で呼び出す必要はないが、パッケージが機能するために必要なサポートファイルとランタイムサポートプログラムは、（バイナリの場合）/ usr/libのサブディレクトリに配置することをお勧めします。できれば/usr/ lib/package-nameの下に。
そこで、共有ライブラリ（libabc.soなど）を/ usr / lib /myapp/ディレクトリに配置します。debianパッケージを作成した後、/ usr / lib / myapp /がローダーによって検索されてディレクトリがロードされないため、バイナリのロードに失敗します。バイナリでRPATHを使用することはお勧めしません。それで、debianパッケージ、またはバイナリのコンパイルなど、それを機能させるためにどのような変更を加える必要がありますか。
あなたの共有ライブラリが他の (潜在的に将来の) アプリケーションに使用でき、ライブラリへのパブリック インターフェイスがある場合は、それを/usr/lib/直接 (またはむしろ/usr/lib/<host-triplet>マルチアーキテクチャ サポートのために) インストールすることを検討してください。
これがオプションでない場合 (共有ライブラリが本当にプライベートであるため)、他のアプリケーションがそれをどのように処理するかを確認してください。私のシステムを簡単に調べてみると、 と の両方ardourにgeditプライベート shlib があることがわかりました/usr/lib/<pkgname>/。
ardour（imo）かなりハックな方法を使用します。実行可能ファイル/usr/bin/ardour2は、実際には、LD_LIBRARY_PATHファッジで実際のバイナリを呼び出すワープシェルスクリプトにすぎません。
export LD_LIBRARY_PATH=/usr/lib/ardour2${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
/usr/lib/ardour2/ardour-bin
では、アップストリームはas (に移動するライブラリの autotools 用語) としてgeditインストールするように適切に移動しました。libgedit-private.sopkglib/usr/lib/<pkgname>
autotools解決を自動的に処理します（おそらく のようなものでrpath）。
最後に、debian-policy を読んだところ、プライベートではないライブラリ (他のアプリケーションで使用される可能性のあるライブラリ)rpathに対して眉をひそめています。これはここで問題になるとは思いませんが、もちろんこれはポリシーの私の解釈です。IRC やメーリング リストなどの Debian チャネルの 1 つに戻って確認することをお勧めします。