http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56259
--- Comment #3 from Caleb Sunstrum <novulae at hotmail dot com> 2013-02-20 01:47:02 UTC --- (In reply to comment #2) > This block of code was added to handle a special case seen on FreeBSD: > (a) on some versions of FreeBSD circa 2004, the system installed copy of gmp.h > was too old to support gcc > (b) by default, FreeBSD ports system installs into /usr/local Is there a reason why /path/to/gcc-source/configure --with-gmp=/usr/local doesn't work? I don't have access to these older FreeBSDs, so I can't comment. > > I note that the claimed serious side effects only happen when one installed > gmp > from ports (or otherwise installed it into /usr/local) *and* one attempted to > build a gcc with a copy of gmp co-located with gcc source. At the very least, this hack should propagate the settings downstream to mpfr and mpc. But since --with-gmp=/usr/local will (should) do the same thing, I don't see why it's necessary. > > We need to think about the default user (which will likely not unpack gmp, > mpfr > and mpc) into the gcc source tree. While I agree the default use case is important, I think it's more important to note that there is nothing to suggest that this hack in play, and diagnosing the failures + the unexpected side effects is quite difficult to do. I only noticed this when trying to figure out why MPFR and MPC were failing to build with GMP and tracing through the configure script. Conversely, if no --with-gmp is specified and the default GMP is too old, one could add additional text to the warning when configure fails - stating that the GMP found in the default location is too old, and they may wish to specify --with-gmp=/usr/local (if GMP exists there), or to build GMP from source as part of GCC.
