[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn 0.9 rc2 tarball

From: Joe Orton <joe_at_manyfish.co.uk>
Date: 2002-02-18 23:04:33 CET

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



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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.