From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8735 invoked by alias); 23 Sep 2010 14:08:32 -0000 Received: (qmail 8691 invoked by uid 48); 23 Sep 2010 14:08:19 -0000 Date: Thu, 23 Sep 2010 14:08:00 -0000 Message-ID: <20100923140819.8690.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug other/45760] GCC build fails: can't find MPC In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "redi at gcc dot gnu dot org" 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: 2010-09/txt/msg02607.txt.bz2 ------- Comment #3 from redi at gcc dot gnu dot org 2010-09-23 14:08 ------- GCC doesn't set runpaths in executables, this is intentional: http://gcc.gnu.org/faq.html#rpath If you don't want those support libs installed for their own sake and are only installing them for GCC to use, then a simpler way to build it is to put the gmp, mpfr and mpc sources under gcc-4.5.1 (renamed from gmp-x.y.z to just gmp, and similarly for mpfr and mpc) and then just configure gcc without any --with-{gmp,mpfr,mpc} options. That way gcc will build with those sources and doesn't need to find the shared libs. Or you can build the libs with --disable-shared so that gcc will have to link statically to libgmp.a, which also avoids needing to find the shared libs. Or you can just make sure the shared lib can be found, using LD_LIBRARY_PATH or LD_RUN_PATH or ldconfig. (In reply to comment #0) > But libmpc.so.2 is there. I even took care of creating artificial symbolic > links to satisfy this bizarre 'powerpc64-unknown-linux-gnu' under ROOT. Don't do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45760