On Sat, Feb 16, 2002 at 04:31:32PM -0800, Blair Zajac wrote:
> Joe Orton wrote:
> > As I said before, doing it by *default* I consider bad behaviour, since
> > that would hard-code an rpath into the binary which is specific to the
> > build environment.
>
> So you're saying it's bad behavior for wget or openssh to link with -R
> to the directory containing the openssl libraries? That's exactly the
> behavior I want and I think most people want. Why is this something
> you consider bad behavior?
Because I think it's one of these things which is best left in the hands
of the knowledgeable sysadmin, rather than trying to second-guess them
in configure scripts.
> Would you take a patch to add -R support to configure.in in a default
> non-default form?
I spent some time thinking about this question: what would this
configure flag be? --enable-rpath wouldn't cut it: neon can be linked
against combinations of zlib, OpenSSL, libxml or expat, any of which may
be shared or static. I'm not sure how a hypothetical --enable-rpath
would make the right guesses about which to add rpaths for. So
--enable-rpath=/usr/foo/lib sounds much more reasonable, and that would
be simple to implement correctly. But that's a redundant configure
flag, and offers nothing over LDFLAGS="-R/usr/foo/lib" except more
characters to type. ;)
So I'm really much happier not changing anything, and saying: if you
want to add an rpath into binaries, you must know what you are doing,
and you don't need the help of a silly configure flag anyway, so pass it
in explicitly by using the appropriate LDFLAGS, or use LD_RUN_PATH, etc
etc.
Regards,
joe
---------------------------------------------------------------------
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