Re: RFE: allow $ORIGIN in the run-path

[Laszlo PETER]

Alexandre Oliva wrote:
> 
> On May 14, 2001, Laszlo PETER <address@hidden> wrote:
> 
> > I agree, things will go very wrong if your run-path does not match your
> > actual directory structure. The nice solution would be to produce this
> > string dynamically from $bindir and $libdir when using $ORIGIN.
> 
> This is very hard to do, in general.  Consider if bindir and libdir
> are unrelated pathnames, and some of the pathname components are
> soft-links.  Canonicalization of pathnames prior to computing the
> actual relationship between the pathnames is an option, but it might
> turn out to do the Wrong Thing (TM) if the user's aim is to keep some
> of the soft-links reconfigurable.

I don't think we should worry about changing paths. Sure, there are
a multitude of ways to break an application, there's nothing we
can do about it.

>  There's no one-size-fits-all solution for this problem.

Agree. I'd just like an option.

> And it gets worse: consider that libtool doesn't know, at
> program-build-time, where a program is going to be installed.  It
> can't even verify that the directory in which the dependence libraries
> are going to be installed is accessible as some relative pathname from
> the directory in which the program is going to be installed (remember
> that not all programs are installed in $(bindir).

Yes, this is the real problem here. I've written a prototype sed script
(see below) to generate a transformed rpath from a libdir and a bindir.
It's not difficult. But it needs to know these directories. The libdir
is given, you just have to step through all the libraries in the rpath
and produce the transformed rpath. But libtool needs to know the bindir
for the given binary at link time to use this approach.

> Perhaps we should introduce some flag that could be used at
> program-link-time that would tell libtool where it was going to be
> installed, and introduce a configure-option such as
> --with-rpath-transform (akin to --program-transform-name) that a user
> could use to get from $(libdir) to $ORIGIN/../lib.

That would be fine!

> The problem would
> be how to get the information about the program's and the library's
> installation directories into something unambiguous and usable for the
> rpath-transform sed program to manipulate.

Well, I'm not so much into the details of libtool, but I guess this could be
done by introducing a new option to libtool, something like --bindir=...
that you can pass with --mode=link. The directory passed on could be recorded
in the wrapper script and checked at --mode=install.
Again, no one would be forced to use this feature and it wouldn't break
the backward compatibility, but it would provide an solution for building
relocatable packages.

Here's my little sed script, I guess it could be written more elegantly
but it's good enough to be a prototype:

        {
        N
        s/^\(.*\)\/\(.*\)\(\n\)\1\/\(.*\)/\/\2\3\/\4/
        h
        s/^\(.*\)\n.*$/\1/
        s/[^\/.]/../g
        s/\.\.\.*/../g
        x
        s/^.*\n\(.*\)$/\1/
        H
        x
        s/^/$ORIGIN/
        s/\n//
        }

Here are some tests:

% ( echo /usr/local/bin; echo /usr/local/lib ) | sed -f transform-rpath.sed 
$ORIGIN/../lib
% ( echo /usr/local/bin; echo /opt/local/lib ) | sed -f transform-rpath.sed 
$ORIGIN/../../../opt/local/lib
% ( echo /usr/local/bin; echo /usr/local.old/lib ) | sed -f transform-rpath.sed 
$ORIGIN/../../local.old/lib
% ( echo /usr/local/libexec/prog/version; echo /usr/local/lib/prog/version ) \
   | sed -f transform-rpath.sed 
$ORIGIN/../../../lib/prog/version

% bindir=/usr/local/bin
% rpath="/usr/local/lib /opt/local/lib /usr/apache/lib"
% new_rpath=`( for rp in $rpath; do echo $bindir; echo $rp; done ) | sed -f 
transform-rpath.sed` 
% echo $new_rpath
$ORIGIN/../lib $ORIGIN/../../../opt/local/lib $ORIGIN/../../apache/lib


Laca