From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20146 invoked by alias); 11 Oct 2004 20:49:39 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 20131 invoked by uid 48); 11 Oct 2004 20:49:38 -0000 Date: Mon, 11 Oct 2004 20:49:00 -0000 Message-ID: <20041011204938.20129.qmail@sourceware.org> From: "tromey at gcc dot gnu dot org" To: java-prs@gcc.gnu.org In-Reply-To: <20040903202714.17311.hjl@lucon.org> References: <20040903202714.17311.hjl@lucon.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij X-Bugzilla-Reason: CC X-SW-Source: 2004-q4/txt/msg00075.txt.bz2 List-Id: ------- Additional Comments From tromey at gcc dot gnu dot org 2004-10-11 20:49 ------- I read that. What I observe is that .libs/gij is created by the build. Then if I run gij (not .libs/gij), it creates .libs/lt-gij. My understanding is that --enable-fast-install is what makes all this work as it does. .libs/gij has the install tree in its DT_RPATH -- but that is ok since this executable is never run from the build tree. It exists only so that installation can be as simple as "cp". .libs/lt-gij is relinked lazily, when gij is run. Its DT_RPATH is: opsy. readelf -d .libs/lt-gij |grep RPATH 0x0000000f (RPATH) Library rpath: [/home/tromey/gnu/Trunk/build/i686-pc-linux-gnu/libjava/.libs:/home/tromey/gnu/Trunk/install/lib] So to me it looks like we're missing an entry here for the libgcc_s.so directory. So, probably, your first patch is the way to go... I'd like a bona fide libtool expert to look at this though. I still don't understand why the second patch is needed. As for --disable-fast-install, did you try just passing that to the top-level configure? (I didn't) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311