我有一个为 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 的正确方法，其作者说：“我有一个 32 位二进制文件，需要libgmp.so.3x86_64 安装。”在该线程中，他们建议安装已编译的 32 位版本 Ubuntu 软件包，我就是这么做的，只是为了添加/usr/lib/libgmp.so.3和/usr/lib/libgmp.so.3.5.2并将locate libgmp错误（如预期的那样）更改为
./foo: error while loading shared libraries: libgmp.so.3: wrong ELF class: ELFCLASS32
所以我写信给二进制作者，他非常有帮助地重新编译，但回信说库现在有 140 MB，所以最好的选择是我自己重新编译。
为什么对 的二元依赖性不能libgmp.so.3满足libgmp.so.10？
这是否意味着该软件仅依赖于某个库版本？难道这不能是“软编码”吗？
共享库是否总是会破坏与其先前版本的向后兼容性（我认为不会）？
我认为我的选择是：
A。下载并编译libgmp.so.3x64
b.重新编译软件
C。运行风险：我可以编写一个链接来使用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)
答案1
从您的 ldd 输出来看，它看起来并不位于知道搜索共享库/usr/lib/x86_64-linux-gnu/的路径中。ld您可以通过ldconfig -v使用超级用户权限运行来检查这一点，这将输出 LD 可以找到的所有共享库的列表。如果您在该列表中找不到 libgmp，则需要编辑您的库/etc/ld.so.conf.d/[your-system-arch].conf以/usr/lib/x86_64-linux-gnu/放入库搜索路径。