> On Fri, Dec 11, 2015 at 10:18 AM, Theo de Raadt <dera...@cvs.openbsd.org>
> wrote:
> >> Just found I can set LD_DEBUG to see the full translation process of ld.so.
> >> This seems to confirm what I've seen in the source: ld.so uses cwd
> >> instead of process file location for $ORIGIN interpolation.
> > ^^^^^^^^^^^^^^^^^^^^^
> >
> > What is that? Generally Unix has no way of doing this. You can inspect
> > your executable's __progname, which is cloned from argv at crt startup,
> > but it may not contain an absolute path. So what do you really mean here?
>
> I'm not sure what Solaris does for this, but it looks like glibc on
> Linux does readlink("/proc/self/exe") and if that fails and the
> process trusts its environment** then it falls back to the
> LD_ORIGIN_PATH environment variable. $ORIGIN then expands to
> dirname() of that.
Oh, I was certain that is what this would do.
That is why I said "Generally Unix has no way of doing this".
/proc/self/exe, or anything else like it, is DEFINATELY NOT
in POSIX or any other cross-vendor Unix standard.
> I guess we could stick 'path' into an auxiliary vector value and have
> ld.so do the realpath() call if $ORIGIN is used? It would be that or
> have the kernel store the whole path for the life of the process for
> obtaining with sysctl(). Right now it only stores the last component
> of the (resolved) original path in p_comm.
Quite expensive, for such a small need.
Since Unix operating systems don't have a way to do this in general,
how did this become part of the ld.so spec?
