Sender: Jed Brown <five9a2@gmail.com>
From: Jed Brown <jed@59A2.org>
To: Justus Winter <4winter@informatik.uni-hamburg.de>, notmuch@notmuchmail.org
Subject: Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so
In-Reply-To: <20130409152128.7736.76003@thinkbox.jade-hamburg.de>
References: <1365475646-22926-1-git-send-email-jed@59A2.org>
	<20130409141333.7736.41695@thinkbox.jade-hamburg.de>
	<87obdn7nwe.fsf@mcs.anl.gov>
	<20130409152128.7736.76003@thinkbox.jade-hamburg.de>
User-Agent: Notmuch/0.15.2+78~g5404ac5 (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-unknown-linux-gnu)
Date: Tue, 09 Apr 2013 10:31:12 -0500
Message-ID: <87fvyz7mbj.fsf@mcs.anl.gov>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Sebastian Spaeth <Sebastian@SSpaeth.de>
Precedence: list

Justus Winter <4winter@informatik.uni-hamburg.de> writes:
> But why do we do that? I always thought that rpath causes more
> problems and is to be avoided if possible [0]. But otoh, I didn't even
> knew that the notmuch build system uses rpath.
>
> 0: e.g. http://wiki.debian.org/RpathIssue

RPATH is bad for distributions, but great for private installs.

> I actually have no strong feelings for or against this proposal. I'm
> merely surprised that there is an issue that you are trying to fix
> here since exactly this configuration has worked for me since the day
> I started using notmuch.

Sure, but you always set LD_LIBRARY_PATH instead of relying on RPATH.

> And from my point of view LD_LIBRARY_PATH is the correct way to
> instruct the dynamic linker (and as a similar facility the ctypes
> library loader) where to look for additional libraries.

LD_LIBRARY_PATH is inconvenient as hell if you have multiple installs
living in different places, i.e., you write /path/to/A/bin/notmuch and
have it use /path/to/B/lib/libnotmuch.so.3 just because you placed
/path/to/B/lib in your LD_LIBRARY_PATH at some point in the distant past
when it was needed by /path/to/B/bin/other-thing that may not even be
installed any more.

This happens a lot more with languages other than C and when you have
different compilers with mutually-incompatible ABIs or packages that
didn't bother with soname versioning.