public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Edward Peschko <esp5@pge.com>
To: Richard Henderson <rth@redhat.com>
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
Date: Mon, 24 Jan 2005 15:53:11 -0800	[thread overview]
Message-ID: <20050124235311.GD19422@venus> (raw)
In-Reply-To: <20050124233849.GA29765@redhat.com>

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

  reply	other threads:[~2005-01-25  0:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-24 22:24 forestalling GNU incompatibility - proposal for binary relative dynamic linking Edward Peschko
2005-01-24 22:47 ` Edward Peschko
2005-01-24 23:08 ` Mike Frysinger
2005-01-24 23:12   ` Edward Peschko
2005-01-24 23:10 ` Richard Henderson
2005-01-24 23:16   ` Edward Peschko
2005-01-24 23:38     ` Richard Henderson
2005-01-24 23:53       ` Edward Peschko [this message]
2005-01-25  0:29         ` Daniel Jacobowitz
2005-01-25  9:25 ` Adrian von Bidder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050124235311.GD19422@venus \
    --to=esp5@pge.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sources.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox