lib依存関係を満たす

x64（現在のアーキテクチャ）用にコンパイルされたプログラム（fooここで呼びます）があります。実行しようとすると、次のようになります。

./foo: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory

出力の関連部分locate：

/usr/lib/x86_64-linux-gnu/libgmp.so 
/usr/lib/x86_64-linux-gnu/libgmp.so.10
/usr/lib/x86_64-linux-gnu/libgmp.so.10.1.3

周りを見回している間、この質問を見つけました。Mint：/lib/i386-linux-gnu/libgmp.so.3をインストールする正しい方法、作成者は、「x86_64のインストールが必要な32ビットバイナリがあります」と言いました。そのスレッドでは、エラーを追加して変更するためlibgmp.so.3にUbuntuパッケージのコンパイルされた32ビットバージョンをインストールすることを提案しました（予想通り）/usr/lib/libgmp.so.3/usr/lib/libgmp.so.3.5.2locate libgmp

./foo: error while loading shared libraries: libgmp.so.3: wrong ELF class: ELFCLASS32

だから私はバイナリプロデューサーに手紙を送り、彼は非常に便利に再コンパイルしましたが、ライブラリは今140MBなので、最良の選択は直接再コンパイルすることだと返信しました。

ペアのバイナリ依存関係がlibgmp.so.3満たされないのはなぜですかlibgmp.so.10？

これは、ソフトウェアが特定のライブラリバージョンにのみ依存することを意味しますか？これは「ソフトコーディング」ではないでしょうか？

共有ライブラリは常に以前のバージョンとの互換性を破ります（そうではないと思います）？

私の選択は次のとおりです。

ㅏ。libgmp.so.3x64のダウンロードとコンパイル

b。ソフトウェアを再コンパイルします。

氏。ランタイムリスク：（libgmp.so.10実際には）使用するリンクを作成できますかlibgmp.so.3？

動作しますか？長所/短所は何ですか？

添付：

追加: binのldd

linux-vdso.so.1 =>  (0x00007fff290fa000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f8061064000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8060e46000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8060b3f000)
libbz2.so.1 => /lib/x86_64-linux-gnu/libbz2.so.1 (0x00007f806092f000)
llibz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8060716000)
libgmp.so.3 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8060350000)
/lib64/ld-linux-x86-64.so.2 (0x00007f80612a0000)