|
Message-ID: <20150115121536.GO4574@brightrain.aerifal.cx> 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.