From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8492 invoked by alias); 28 Feb 2002 21:47:05 -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 8322 invoked from network); 28 Feb 2002 21:46:59 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 28 Feb 2002 21:46:59 -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 NAA27613; Thu, 28 Feb 2002 13:46:50 -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 NAA04681; Thu, 28 Feb 2002 13:46:44 -0800 (PST) Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g1SLkf415978; Thu, 28 Feb 2002 18:46:41 -0300 To: Daniel Jacobowitz Cc: Mark Mitchell , gcc@gcc.gnu.org Subject: Re: Installation proposal References: <11560000.1014832588@warlock.codesourcery.com> <20020227205456.A25584@nevyn.them.org> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Thu, 28 Feb 2002 14:06:00 -0000 In-Reply-To: Daniel Jacobowitz's message of "Wed, 27 Feb 2002 20:54:56 -0500" 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/msg01841.txt.bz2 On Feb 27, 2002, Daniel Jacobowitz wrote: > On Wed, Feb 27, 2002 at 10:44:52PM -0300, Alexandre Oliva wrote: >> > 3. We would test that our installations are really location-independent, >> > which they supposedly are. >> >> Not really. At least not cross toolchains that use a shared glibc as >> the C library, because glibc's libc.so is a linker script that >> references full pathnames into the install tree. Yet another problem >> about which we must make a conscious decision. > Which works perfectly well if you remove the full paths and let the > linker search this. I wonder why glibc doesn't just do that, then... I mean, this is a bug in glibc, no? > We're in the middle of fighting a losing war with libtool. Right now, > we edit installed .la libraries to remove the full path information > from them. I might add that, on GNU/Linux, this is entirely adequate; > it would be much simpler if we could get libtool not to generate such > things. Ditto for DT_RPATH. Patches to get libtool to take -L or -R flags out of link commands and .la files would be definitely welcome. It's been in my to-do list forever. -- 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