Using -rpath and $ORIGIN with libtool-based projects?

I am trying to incorporate a libtool-based package into a project of my own, perhaps in a non-standard way. Here is my goal:

1. Build external project:

   ./configure --prefix=$HOME/blah --etcetera && make && make install
   

2. Build my own project which depends upon the external project's shared libraries and executables at runtime:

   gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program
   

3. Package everything into a single "localized" tarball... that is, while I have everything in $HOME/blah on the build host I want the ability to extract the tarball to any arbitrary directory (on some other host) without having to futz with my environment. The intent is to allow multiple versions of my project to coexist side-by-side without any nasty "cross-pollination".

I know that I can use -rpath '$ORIGIN/../lib' for my project to ensure that the right shared libraries always get loaded at runtime. However, it seems that libtool insists on assigning its own -rpath setting based on the exact path of $HOME/blah/lib, which breaks if I happen to untar everything into a different directory (say, for example, $HOME/blah.2011-06-02).

Is there a way around this limitation? I see a rather lengthy rpath discussion betw开发者_开发百科een debian and libtool folks on the topic, but it's somewhat old and inconclusive beyond "we disagree".

Among the options presented here on Rpathissue on the debian Wiki, using chrpath in your 'install' step or some post-processing script sounds like a viable option. (It's available on a bunch of distros via your favorite package manager.)

It doesn't require patching libtool which is a plus IMO.

Note that it has some limitations: can only save the new rpath if it's shorter (or same length) as the original one.

The other (pragmatic) option is to remove the rpath (chrpath can do that), and just have a wrapper script that sets LD_LIBRARY_PATH to whatever is necessary for your app. That has a chance of being slightly more portable too (if you handle the other shared library path environment vars some OSes have).