Binary relocatability part 1

[Alexandre Julliard]

Mike Hearn <m.hearn at signal.QinetiQ.com> writes:

> Still, I'm not sure why this has to be so generic. I think not people
> modify the standard install layout, and if they do, they probably
> don't care about binary relocatability. Why do we have to make the
> code so very complex to make it work for 100% of people when much
> simpler code could work for 95%? When do the costs outweigh the
> benefits?

Of course, by the same reasoning, 95% of people are happy with the
way things work now, so why add complexity to make it relocatable?
And really, it's not that hard to do it right.

> There's another issue: I'm not sure what you're asking me to do :( Do
> you mean if somebody does, eg
>
> ./configure --bindir=a/b/c --libdir=x/y/z
>
> that the rpath is set to
>
> ${ORIGIN}/../../../x/y/z ?

Yes.

> If so got any tips for how to implement this?

Start from bindir, add ".." until you get to the common part of the
two paths, then append the rest of the libdir path.

-- 
Alexandre Julliard
julliard at winehq.org