[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Jan 2015 07:15:36 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: dynamic linking (Re: musl and android)
On Thu, Jan 15, 2015 at 01:00:05PM +0100, u-wsnj@...ey.se wrote:
> On Thu, Jan 15, 2015 at 06:01:58AM -0500, Rich Felker wrote:
> > copy of the dynamic linker (libc.so/ld-musl) in the package
> > and executing the program via a wrapper script that manually invokes
> > the dynamic linker (so the hard-coded PT_INTERP pathname isn't
> > needed).
>
> > But these are not the approaches I'd like to be
> > recommending in the long term... :(
>
> Actually I believe (and know from long time experience) this to be
> the only "sane"/robust/general way to run dynamically linked executables.
It depends on your perspective. If you're viewing them as
self-contained entities, then yes, but if you're viewing them as
something running in an existing library ecosystem, there's no
problem.
> I don't think that the implications of hardcoding the interpreter
> path were well understood when dynamic linking was first deployed,
> the hardcoding merely became percepted as the only/natural approach
> when the purpose was to cheaply imitate the behaviour of statically
> linked programs. (This mimics the #!/... which is similarly
> limited/broken. The plain text scripts are though relatively easy
> to modify to hack around the limitation, according to local curcumstances)
I think this could be fixed easily by having the kernel support
$ORIGIN in PT_INTERP.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
