From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6584 invoked by alias); 25 Jan 2005 00:01:19 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 5814 invoked from network); 25 Jan 2005 00:01:03 -0000 Received: from unknown (HELO mta02.pge.com) (131.89.129.72) by sourceware.org with SMTP; 25 Jan 2005 00:01:03 -0000 Received: from mta13.comp.pge.com (mta13.comp.pge.com [10.245.211.128]) by mta02.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j0P00tv8005929; Mon, 24 Jan 2005 16:00:55 -0800 (PST) Received: from venus.comp.pge.com (venus.comp.pge.com [10.244.96.57]) by mta13.comp.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j0P00tTW026235; Mon, 24 Jan 2005 16:00:55 -0800 (PST) Received: (from esp5@localhost) by venus.comp.pge.com (8.8.8p2+Sun/8.8.8) id PAA20064; Mon, 24 Jan 2005 15:53:11 -0800 (PST) X-Authentication-Warning: venus.comp.pge.com: esp5 set sender to esp5@pge.com using -f Date: Tue, 25 Jan 2005 00:01:00 -0000 From: Edward Peschko To: Richard Henderson Cc: gcc@gcc.gnu.org, libc-alpha@sources.redhat.com, binutils@sources.redhat.com, linux-kernel@vger.kernel.org Subject: Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking Message-ID: <20050124235311.GD19422@venus> References: <20050124222449.GB16078@venus> <20050124231047.GC29545@redhat.com> <20050124231636.GC19422@venus> <20050124233849.GA29765@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050124233849.GA29765@redhat.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-01/txt/msg00403.txt.bz2 On Mon, Jan 24, 2005 at 03:38:49PM -0800, Richard Henderson wrote: > On Mon, Jan 24, 2005 at 03:16:36PM -0800, Edward Peschko wrote: > > cool.. any chance for some syntactic sugar so me (and other > > users/vendors) wouldn't need to change any of their build scripts > > and compilation processes? > > Uh, like what? That's about as simple as you can get. > > > r~ I don't understand. Which is simpler, changing an environmental variable, or adding extra CFLAGS to every single compile and recompiling? In addition, in your --rpath example, the relative pathing is hardcoded into the executable, wheras with "*" you could modify the runtime behavior of the executable at runtime. I suppose you could change this with chrpath, but why bother? What if you want to test out two versions of relative libraries side by side? And in any case, I'm not even sure if you can change the runtime path to something longer than what currently exists in the executable using chrunpath. And finally, certain programs (glibc, for example) seem to get into to trouble (ie: not compile) when you use --rpath flags. So, what's the issue with "*"? Ed