On Sun, Feb 17, 2002 at 12:21:29PM -0800, Justin Erenkrantz wrote:
> On Sun, Feb 17, 2002 at 11:59:09AM -0800, Zack Weinberg wrote:
> > I kind of wish there was a utility that could edit DT_RPATH entries in
> > an executable binary. This would allow one to create binaries with
> > -rpath pointing inside the build directory (which avoids the need to
> > set LD_WHATEVER during testing), and then adjust them to point to the
> > installed-library directory at installation time.
>
> AIUI, on some platforms, libtool can do this with the --relink
> command.
Well, see, that does what it sounds like, i.e. it relinks the binary.
There are several reasons why this is not an acceptable solution. The
simplest one is that making your Makefiles do that at install time
adds a nontrivial amount of complexity to the install rules.
A more complex reason -- where'd I put my Paranoid Operator from Hell
hat? Oh, over there. Imagine a setup where the sysadmin has
carefully limited the set of programs accesible to the privileged
account that does installations; in particular, he has removed all of
the toolchain. If "make install" tries to invoke the compiler or even
the linker, it will fail. An even more extreme person might insist on
using "make -n install" and reading the resulting list of batch
commands, and if there's anything in there that he doesn't like, or
any operation that isn't perfectly transparent, he doesn't install the
software.
And a third reason - personally the most convincing - is that libtool
--relink will set the rpaths according to $(prefix) at install time,
which is wrong; the install-time prefix is frequently different from
what it will be at runtime. (For instance, most binary-package
generation tools will invoke "make install" with prefix pointing at a
temporary directory that then gets sucked into a tarball.) The
hypothetical rpath editor would have this problem if used incorrectly,
but because it would be a simple do-what-I-say utility, it would be
easier for a Makefile author to use it correctly.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006