From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10272 invoked by alias); 26 Oct 2008 19:26:49 -0000 Received: (qmail 10264 invoked by uid 22791); 26 Oct 2008 19:26:48 -0000 X-Spam-Check-By: sourceware.org Received: from smtpauth18.prod.mesa1.secureserver.net (HELO smtpauth18.prod.mesa1.secureserver.net) (64.202.165.31) by sourceware.org (qpsmtpd/0.31) with SMTP; Sun, 26 Oct 2008 19:25:53 +0000 Received: (qmail 9555 invoked from network); 26 Oct 2008 19:25:51 -0000 Received: from unknown (68.3.213.75) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 26 Oct 2008 19:25:51 -0000 Message-ID: From: "Kaveh R. Ghazi" To: "Geoff Keating" Cc: , , , References: Subject: Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits) Date: Mon, 27 Oct 2008 02:50:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01128.txt.bz2 From: "Geoff Keating" > I found that simply building MPFR in a non-default location (configure > --prefix && make) and then pointing GCC at it with --with-mpfr, as in > the installation instructions, causes the bootstrap to fail when first > running xgcc, because xgcc can't find the built MPFR dynamic library. First I'd like to thank you for running your regression tester, and I'm sorry this upgrade cause you so much difficulty. The issue you describe is PR 21547. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547 It's important IMHO to point out that this issue is not confined to MPFR. While MPFR's more stringent version requirements expose the problem more often, you'll find the same issue with GMP as well if you compile and install your own copy of that library in a non-default location. Basically, the problem is that the bootstrap process doesn't encode the -rpath during the link process of cc1. Doing this in a portable fashion and resolving the PR requires linking cc1 et al. with libtool. I don't have any experience with libtool myself. However since we use it elsewhere in GCC, it may be easy to incorporate. (Any libtool experts available to help out, or at least talk us through the process?) > If this is what users (or even developers) of GCC are supposed to be > doing, I'd suggest more documentation on what to do and how to do it. I think the steps you (or your assistant) went through was unfortunately unnecessarily complicated. The solution I use is to build MPFR and/or GMP using --disable-shared. Then you can install them anywhere you like, pass the location with --with-{mpfr,gmp} to GCC and since only the static library is available everything links and runs fine. Do you think putting this recommendation in the docs somewhere would have been useful to you in this situation? If so, I would be happy to prepare a patch. Regards, --Kaveh