From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10512 invoked by alias); 7 Feb 2006 17:18:36 -0000 Received: (qmail 10494 invoked by uid 48); 7 Feb 2006 17:18:35 -0000 Date: Tue, 07 Feb 2006 17:18:00 -0000 Message-ID: <20060207171835.10493.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "Ralf dot Wildenhues at gmx dot de" 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 X-SW-Source: 2006-q1/txt/msg00163.txt.bz2 List-Id: ------- Comment #21 from Ralf dot Wildenhues at gmx dot de 2006-02-07 17:18 ------- (In reply to comment #20) > What did you mean by *installed programs* In my notation, installed programs live below $prefix. They must not contain any reference to the build tree. You showed an installed program in comment #18, which has an erroneous run path. > The executable in question is > > [hjl@gnu-13 .libs]$ readelf -d > /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/gij > | grep RPATH > 0x000000000000000f (RPATH) Library rpath: > [/usr/gcc-4.2/lib/../lib64] This is an uninstalled program: it lives below $builddir. It should of course have a run path entry to the newly-built library (which also lives below $builddir). One of my points was that, if that uninstalled program also has a run path entry pointing to /usr/gcc-4.2/lib/../lib64, but that comes after all the run paths which point to inside $builddir, then that is not a big problem. > Is is your *installed programs*? No. > My point is when you run a newly built executable > in the build tree, it should use the newly built shared libraries in the build > tree. It is a long standing bug in gcc/libtool. Yes, correct. It's one of my medium term quests to fix this. The converse issue (from a libtool POV) is just GCC bug 5291. Again from a libtool POV it is convenient and useful to attack both issues at the same time. One of the open questions that I could not answer myself yet: When you issue `make install' for GCC, is there a guarantee by the GCC build machinery that - libraries are installed in the correct order (libgcc_s.so before libgcj)? I strongly assume yes. - For each libtool-created library, in case it needs to be relinked at install time, does the relink command have appropriate -L (and maybe -R) flags pointing to the installed non-libtool libraries (e.g., $prefix/lib/libgcc_s)? In comment #18, you show that for this build, the second question is true. I need to know however if it is true in any case, for any value of $host. Iff both questions can be affirmed, then the next question can also be made true: - If libtool erased both all `-L' and all `-R' flags pointing inside the build tree from the relink command that may be issued at `make install' time, would installation still succeed? Then we have a chance to fix this portably in libtool, not only for GNU/Linux. Another small but important question: - Do there exist directories in the GCC build tree where both libtool-created and non-libtool-created libraries are (possibly) built? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311