3

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 locate output:

/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 /usr/lib/libgmp.so.3 and /usr/lib/libgmp.so.3.5.2 to 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 libgmp.so.10?

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 libgmp.so.3)?

Would them work? What would be pros/cons?

PS:

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)
  • @G-Man thank you so much for the edit :) – cladelpino Oct 8 '15 at 12:30
0

From your ldd output, it doesn't look like /usr/lib/x86_64-linux-gnu/ is in the path that ld knows to search for shared libraries. You can check this by running ldconfig -v with superuser privileges, which will spit out a list of all the shared libraries LD can find. If you can't find libgmp in that list, you need to edit your /etc/ld.so.conf.d/[your-system-arch].conf to put /usr/lib/x86_64-linux-gnu/ in the library search path.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.