I have a program (which I will call
foo here) compiled for x64 (my current arch). When I try to run it, it goes:
./foo: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory
Relevant part of
/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
Looking around, I found the question Mint: correct way to install /lib/i386-linux-gnu/libgmp.so.3, whose author says: "I have a 32-bit binary that needs
libgmp.so.3 on an x86_64 installation." In that thread, they suggest installing the compiled for 32-bit version Ubuntu package, which I did, only to add
locate libgmp and (as should be expected) change the error to
./foo: error while loading shared libraries: libgmp.so.3: wrong ELF class: ELFCLASS32
So I wrote the binary author, who very helpfully recompiled, but wrote me back saying the library is now 140 MB, so best option is I recompile myself.
Why isn't the binary dependency on
libgmp.so.3 satisfied by
Does this mean the software depends on a certain library version only? Couldn't this be "soft-coded"?
Does a shared library always break backwards compatibility with its previous version (I thought it didn't)?
My options as I perceive them are:
a. Downloading and compiling
libgmp.so.3 for x64
b. Recompiling the software
c. Running risks: Would I be able to write a link to use
libgmp.so.10 (as it were
Would them work? What would be pros/cons?
extra: ldd for the bin
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)