Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So it's a common error when installing MPFR that if more than one version of libgmp are installed you hit errors. This is quite well documented in the INSTALL file,

If I run locate libgmp the result is

/usr/local/Wolfram/Mathematica/7.0/SystemFiles/Libraries/Linux-x86-64   /libgmp.so.3
/usr/local/Wolfram/Mathematica/8.0/SystemFiles/Libraries/Linux-x86-64   /libgmp.so.10

The version I actually want to use I have just installed and can see in /usr/local/lib (odd that this doesn't appear above??). The INSTALL files says if this is the case then

  If you want to use the GMP version under /usr/local, then you
  should uninstall all the other GMP versions (header and library
  files) that may be seen in the search paths, but *NOT* the one
  under /usr (the version under /usr is provided by the OS vendor,
  and changing/removing anything related to it may break your
  system, and /usr should have a lower precedence than /usr/local

but I'm not sure exactly what to uninstall and indeed how, do I just delete? Moreover the locate libgmp doesn't even find the one under /usr anyhow.I don't want Maple or Mathematica to die on me...

Other fixes I've tried are export CPLUS_INCLUDE_PATH=usr/local/include , export C_INCLUDE_PATH=usr/local/include, export LIBRARY_PATH=usr/local/lib, export LD_LIBRARY_PATH=usr/local/lib, export LD_RUN_PATH=usr/local/lib as I read somewhere else that this may help, but to no avail. I've also patched with the latest.

I naievly just deleted libgmp.so.10.0.2 and libgmp.so.10 from /usr/lib/i386-linux-gnu/ and this seems to have caused major issues with gcc working, ahh

share|improve this question
up vote 2 down vote accepted

The version I actually want to use I have just installed and can see in /usr/local/lib (odd that this doesn't appear above??).

locate relies on a database that gets rebuilt periodically by updatedb. If you add files to your system between two runs of updatedb, locate naturally will not see them. (This database is why locate is far faster than a find over the entire filesystem. The downside is that its output can be outdated.)

There are ways to force updatedb to run again, but the method depends on the particular Linux distribution, and would be a different question anyway.

I'm not sure exactly what to uninstall and indeed how, do I just delete?

No, don't delete the copies belonging to Maple and Mathematica. It is extremely unlikely that their installers added these paths to the default library search path for the compiler.

You can check that with this command:

$ ld --verbose | grep SEARCH

You shouldn't see ~/maple or /usr/local/Wolfram anywhere within the output.

locate libgmp doesn't even find the one under /usr

It did, actually. The library in /usr/lib/i386-linux-gnu is the one your INSTALL document is referring to. The INSTALL document is literally true only for traditional, simple *ix systems. Sometimes *ixes diverge from the standard practice of placing files directly in /usr/lib. In this case, it's because of the ongoing 32-to-64-bit transition happening within the x86 Linux world.

Some day in the future, when all 32-bit systems are dead, Linux distros may revert to the old /usr/lib style.

Beware that the scheme your system appears to use isn't universal even within Linuxes. Another common scheme is to put 32-bit libraries in /usr/lib and 64-bit libraries in /usr/lib64.

The important point here is that these system library directories not be ahead of /usr/local/lib for your package's build system to do the right thing. The ld command I gave above will tell you this. If it turns out that /usr/local/lib is not ahead of /usr/lib* as the MPFR creators assumed, you will have to find a way to push it ahead.

One way to do that is:

$ ./configure LDFLAGS=-L/usr/local/lib

There may be a more elegant method, given in the INSTALL document. Or, say:

$ ./configure --help | grep -i gmp

That will tell you if there are any GMP-related configure script options that let you control which library it uses.

share|improve this answer
the ld command gives: EARCH_DIR("/usr/i686-linux-gnu/lib32"); SEARCH_DIR("=/usr/local/lib32"); SEARCH_DIR("=/lib32"); SEARCH_DIR("=/usr/lib32"); SEARCH_DIR("=/usr/local/lib/i386-linux-gnu"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib/i386-linux-gnu"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib/i386-linux-gnu"); SEARCH_DIR("=/usr/lib"); – fpghost Oct 29 '12 at 15:24
so it looks like the locals are behind the /usr/i686-linux-gnu/lib32 ? – fpghost Oct 29 '12 at 15:30
Well I've already exported a number of environment vars as mentioned in the OP ,e.g. export LIBRARY_PATH=usr/local/lib, export LD_LIBRARY_PATH=usr/local/lib, export LD_RUN_PATH=usr/local/lib – fpghost Oct 29 '12 at 15:34
the MPRF INSTALL basically says remove the old version but not the one in /usr, but I can't see what else there is to remove. – fpghost Oct 29 '12 at 15:34
First, don't remove anything. I thought I made that clear in my answer. Second, you are missing slashes on your export lines, between the equals sign and the usrs. usr/local/lib is not the same thing as /usr/local/lib. And third, if that doesn't help, try my LDFLAGS method: it should give the same result, but depending on the way they've set up their build system, it may work where the other does not. – Warren Young Oct 29 '12 at 16:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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