From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14452 invoked by alias); 20 Feb 2013 01:47:19 -0000 Received: (qmail 14224 invoked by uid 48); 20 Feb 2013 01:47:03 -0000 From: "novulae at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/56259] GCC's configure script has a hard-coded setting of 'with_gmp' for FreeBSD Date: Wed, 20 Feb 2013 01:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: novulae at hotmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg02022.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56259 --- Comment #3 from Caleb Sunstrum 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.