Re: -rpath problem , relative paths not allowed

[Ralf Wildenhues]

Hi Mike,

First off: I've moderated your post through yesterday, but it also seems
to be a victim of the current list server issues; maybe all those
missing messages eventually appear.  Quoting generously thus:

* Mike Mattie wrote on Sat, Mar 25, 2006 at 05:59:22PM CET:
> as I understand it the -rpath arguement to libtool is actually the
> installation path of the shared object. I need that to be a relative
> path.

That is not supported at the moment, unfortunately.  It's a TODO item,
though.  Not trivial though to do right.

> The reason it needs to be relative is because the shared object is going
> into a .jar file, so an absolute path is meaningless for the loader.
> 
> my install target serves no other purpose than to assemble the contents
> of the .jar file before running the jar command.
> 
> Maybe I can pass it an absolute path formed by the build dir, plus the
> relative directory I actually want it to install to. But I am afraid
> that libtool has overloaded -rpath , and makes assumptions about what
> that is, beyond a install path to put the file. Why else would it care
> if it's relative or absolute ?

Well, I think when this semantics were invented, the thoughts were about
like this: there are shared library systems that simply won't allow you
anything except an absolute path, so being portable, this is what you
have to assume.  Certainly that was before java was supported by
Libtool.

> My question is this: can I pass an -rpath as a installation path without
>  that path showing up in my shared objects post compilation/link ?

Libtool does not put such a path into its output if it belongs to the
set of paths that are searched by the runtime loader by default; see the
sys_lib_dlsearch_path_spec variable.  But no, there is no documented way
at the moment to achieve what you need; you could override that variable
manually in the libtool script, as a hack.

Cheers,
Ralf