Re: dynamic linking (Re: [musl] musl and android)

[u-wsnj@aetey.se]

On Thu, Jan 15, 2015 at 07:15:36AM -0500, Rich Felker wrote:
> > > and executing the program via a wrapper script that manually invokes
> > > the dynamic linker (so the hard-coded PT_INTERP pathname isn't
> > > needed).

> > 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.

Right, it depends. For the second perspective you seem to imply that
an "ecosystem" is to be managed in a certain way.

Binaries belonging to my "library ecosystems" still can be subject to
the C library tests and upgrades on a per-binary basis, not only "all
binaries belonging to the same ecosystem at once", which is of course
possible as well.

This would be impossible if I'd rely on the hardcoded loader path.

> > 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.

Unfortunately, no. $ORIGIN does not and can not replace a run time
choice of the dynamic loader. As a simple example, consider a binary on
a readonly media. How would you convince the kernel to run a different
loader than assumed (among others) by the path to the mount point of
the media? In my eyes the mounting of the media (possibly with lots of
binaries on it) and running a certain loader for a certain binary are
very different things and do not have to / should not depend on each other.

Rune