From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1402 invoked by alias); 7 Feb 2006 05:48:20 -0000 Received: (qmail 1384 invoked by uid 48); 7 Feb 2006 05:48:19 -0000 Date: Tue, 07 Feb 2006 05:48:00 -0000 Message-ID: <20060207054819.1383.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/msg00153.txt.bz2 List-Id: ------- Comment #17 from Ralf dot Wildenhues at gmx dot de 2006-02-07 05:48 ------- (In reply to comment #16) > Please read the summary line: "Wrong libgcc_s.so.1 is used by lt-gij". Ld.so > will search DT_RPATH first for any shared libraries. Yes. So all that is missing is a notion in libtool to tell it "this path is to be added to the list of *uninstalled* run paths" which would be added to the relinked-for-execution executable (after all other uninstalled paths) but not the unrelinked one and not either to any uninstalled libraries (on ELF, of course). You have to have that notion anyway because otherwise there would be no way you could add the run path to libgcc_s to libtool safely at all (i.e. without ending up in installed files). In comment #8 you said: > I don't know how to do --disable-fast-install for gcc. As for --disable-fast-install, it's not optimal either. But libtool could create all libraries/programs with the uninstalled run paths (also the ones given by above new flag) and after that all other given ones. `make install' will surely have to relink all of those; but I don't see the necessity for a shell wrapper in this case either (on system where shlibpath_overrides_runpath=no). All there is missing for decent libtool support for "libtool + non-libtool libraries in one build tree" is a notion to pass uninstalled run paths and uninstalled link editor paths (-L), AFAICS. By the way, I don't see any reason why the installed run paths should not be put after the uninstalled ones (into the relinked-upon-execution executable). You have to assume anyway that incompatible libraries may be found in the default runtime linker search path, so really they are not contributing much to the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311