From: u-wsnj@aetey.se
To: musl@lists.openwall.com
Subject: OT: Re: dynamic linking (Re: [musl] musl and android)
Date: Thu, 15 Jan 2015 16:56:38 +0100 [thread overview]
Message-ID: <20150115155638.GB14316@example.net> (raw)
In-Reply-To: <20150115133445.GQ4574@brightrain.aerifal.cx>
Actually I do not suggest any change, musl suits my usage model well
(kudos for the support of running the loader explicitly)!
On Thu, Jan 15, 2015 at 08:34:45AM -0500, Rich Felker wrote:
> That's why I said i depends on your perspective. From your perspective
> this does not work. From most traditional distributions' perspectives,
> it does.
Well said.
The traditional distributions choose to live with the far reaching
consequences of their technical choices. I argue that some constraints
(iow sacrifices) are not necessary and only exist as a consequence
of the unfortunate choices.
> > Unfortunately, no. $ORIGIN does not and can not replace a run time
> > choice of the dynamic loader.
> If you're distributing the binary and dynamic loader/libc and all
> libraries it needs together, I'd assume they'd all be in the same
> directory, or else in ../lib/ relative to the binary. In that case
You suggest a somewhat more relaxed set of assumptions than the
traditional ones. Yes this would be useful, but unfortunately still
setting some more or less arbitrary boundaries.
> $ORIGIN works perfectly fine. Note that $ORIGIN is _not_ an
> environment variable; it's a dynamic-linker feature for locating
> libraries relative to the ELF file (main executable or other library)
> that needs (via DT_NEEDED) them, and the same concept would work for
> PT_INTERP.
Indeed, good to point this out for a casual reader.
Using an environment variable would be otherwise a quite general solution
but I guess this would be very hard to convince the kernel developers to
implement (presumably hardly possible to implement without redesigning
the kernel security model).
Regards,
Rune
next prev parent reply other threads:[~2015-01-15 15:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-15 9:13 musl and android Рысь
2015-01-15 11:01 ` Rich Felker
2015-01-15 12:00 ` dynamic linking (Re: [musl] musl and android) u-wsnj
2015-01-15 12:15 ` Rich Felker
2015-01-15 13:04 ` u-wsnj
2015-01-15 13:34 ` Rich Felker
2015-01-15 15:56 ` u-wsnj [this message]
2015-01-15 13:53 ` musl and android Рысь
2015-01-18 6:32 ` Рысь
2015-01-18 6:44 ` Rich Felker
2015-01-18 8:01 ` Рысь
2015-01-18 16:40 ` Rich Felker
2015-01-19 18:00 ` Рысь
2015-01-21 10:34 ` Рысь
2015-01-21 18:36 ` Rich Felker
2015-01-22 2:37 ` Рысь
2015-01-31 15:08 ` Рысь
2015-02-03 5:52 ` Rich Felker
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=20150115155638.GB14316@example.net \
--to=u-wsnj@aetey.se \
--cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).