From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25547 invoked by alias); 28 Feb 2002 01:28:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25423 invoked from network); 28 Feb 2002 01:28:53 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 28 Feb 2002 01:28:53 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA11033; Wed, 27 Feb 2002 17:28:46 -0800 (PST) Received: from free.redhat.lsd.ic.unicamp.br (vpnuser.sfbay.redhat.com [10.255.17.132] (may be forged)) by cse.cygnus.com (8.8.8+Sun/8.6.4) with ESMTP id RAA01427; Wed, 27 Feb 2002 17:28:42 -0800 (PST) Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g1S1Sct08832; Wed, 27 Feb 2002 22:28:38 -0300 To: Richard Henderson Cc: Tom Tromey , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: Installation proposal References: <11560000.1014832588@warlock.codesourcery.com> <87u1s290vo.fsf@creche.redhat.com> <20020227134857.A29637@redhat.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Wed, 27 Feb 2002 17:38:00 -0000 In-Reply-To: Richard Henderson's message of "Wed, 27 Feb 2002 13:48:57 -0800" Message-ID: User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg01728.txt.bz2 On Feb 27, 2002, Richard Henderson wrote: > On Wed, Feb 27, 2002 at 12:32:27PM -0700, Tom Tromey wrote: >> Don't shared libraries have to be relinked with knowledge of their >> real install location? > Not on sane systems. > Libtool seems to be of the opinion that this is necessary > everywhere, however. Please do not spread mis-information about libtool. You may have your reasons to dislike libtool, but what you're saying is not true. A sane system, to me, is one in which programs and libraries can find their dependencies without the user having to resort to setting LD_LIBRARY_PATH and *hoping* it will work, if they are installed in the location they were configured for. Libtool does in fact have to resort to relinking at install time in some situations to guarantee this property. I list such situations below: - on HPUX, when installing an executable linked using libtool that is linked with libtool libraries in their build-tree location. That's because HPUX's linker doesn't support the equivalent of -rpath, so the executable must be relinked after the library is installed such that it can store the default pathname of the library into the executable. This does not work for DESTDIR installations, and there's no way to overcome it on HPUX. - on most other systems, when a libtool shared library is linked with another libtool shared library, the latter still being in its build tree. Because libtool creates libraries in the build tree in such a way that they can be linked with and used in-place, it encodes build-tree pathnames into the library. Then, at install time, it re-links libraries such that the work in the install tree. Again, on HP-UX, DESTDIR installations don't work. The former is a problem for GCJ executables on HPUX. The latter would be a problem for GCJ because it contains inter-library dependencies. However, except on HPUX, it should work just fine, as long as a patch that fixes relinking in DESTDIR installations is put in. Assuming we're actually going to `make install' into the install-tree hold area, it would work just fine. Except that executables and libraries would be set up to find their dependencies in the final install tree, so, if you already have earlier versions in there, your results may be incorrect. Messing up with shared libraries with inter-dependencies is very dangerous business. Nothing is as simple as you'd like and, and there are some dynamic linkers in which LD_LIBRARY_PATH (or the equivalent) won't do what you want. In fact, on some systems there's no way to override the path used to search for dependencies of shared library, so the only hope is to get them correctly encoded into the shared library itself. Trying to fix it up with LD_LIBRARY_PATH afterwards just won't work. Beware! You were warned :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer