Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so

diff --git a/45/b51aed6dfe59939a7c991d92b610db354a4c41 b/45/b51aed6dfe59939a7c991d92b610db354a4c41
new file mode 100644 (file)
index 0000000..e6e87d3
--- /dev/null
+++ b/45/b51aed6dfe59939a7c991d92b610db354a4c41
@@ -0,0 +1,148 @@
+Return-Path: <five9a2@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id CB32C431FBC\r
+       for <notmuch@notmuchmail.org>; Tue,  9 Apr 2013 07:57:08 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.301\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.301 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=1, \r
+       FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id 2X54zkeGnGSx for <notmuch@notmuchmail.org>;\r
+       Tue,  9 Apr 2013 07:57:08 -0700 (PDT)\r
+Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com\r
+       [209.85.223.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 33E79431FAE\r
+       for <notmuch@notmuchmail.org>; Tue,  9 Apr 2013 07:57:08 -0700 (PDT)\r
+Received: by mail-ie0-f177.google.com with SMTP id tp5so8620857ieb.36\r
+       for <notmuch@notmuchmail.org>; Tue, 09 Apr 2013 07:57:07 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+       h=x-received:sender:from:to:cc:subject:in-reply-to:references\r
+       :user-agent:date:message-id:mime-version:content-type;\r
+       bh=23WQoIPTgSk0tuJozkAUgP5/DJEnd+i86uLP3bjQiXs=;\r
+       b=YwC5qlK/ezEGSPAZE0WOg1G+bVNw7tWd20e5h51Qs3MaBXgEqvFZ/3xLtmzBNTTJIh\r
+       NNfj1HSNCITlh7+3MoIlh4ciZXIlVm7SWZYgiUfRVonEhRr5/YFQsV3+tD6AvvJIEJXr\r
+       ABOTE33GIjhqkeM6h+0PUc6Ywi6tV8+u7+awyLcdErDiQygNgzjmWrIO9cg42rqGxGJ+\r
+       VZWBiiKdvAI2ETOE1iaSdu/2ChOkX4Iousu0NAzKRwI1Z5zxfMOLI/wvtXmBPI9InVS0\r
+       0i0gwHMnLPHrcl20B5U72siFYEo9Q2pg6DVHkb1rs8lsie0FY5VRjgywFIeTJk3DhWiy\r
+       brDQ==\r
+X-Received: by 10.50.7.69 with SMTP id h5mr10905593iga.69.1365519426923;\r
+       Tue, 09 Apr 2013 07:57:06 -0700 (PDT)\r
+Received: from localhost (vis-v410v070.mcs.anl-external.org. [130.202.17.70])\r
+       by mx.google.com with ESMTPS id\r
+       ip2sm22891004igc.5.2013.04.09.07.57.05\r
+       (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
+       Tue, 09 Apr 2013 07:57:06 -0700 (PDT)\r
+Sender: Jed Brown <five9a2@gmail.com>\r
+From: Jed Brown <jed@59A2.org>\r
+To: Justus Winter <4winter@informatik.uni-hamburg.de>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so\r
+In-Reply-To: <20130409141333.7736.41695@thinkbox.jade-hamburg.de>\r
+References: <1365475646-22926-1-git-send-email-jed@59A2.org>\r
+       <20130409141333.7736.41695@thinkbox.jade-hamburg.de>\r
+User-Agent: Notmuch/0.15.2+78~g5404ac5 (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-unknown-linux-gnu)\r
+Date: Tue, 09 Apr 2013 09:57:05 -0500\r
+Message-ID: <87obdn7nwe.fsf@mcs.anl.gov>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+Cc: Sebastian Spaeth <Sebastian@SSpaeth.de>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 09 Apr 2013 14:57:09 -0000\r
+\r
+Justus Winter <4winter@informatik.uni-hamburg.de> writes:\r
+>\r
+> May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch\r
+> to a non-standard location as unprivileged user and to make this\r
+> library available I add its path to LD_LIBRARY_PATH. \r
+\r
+See libdir_in_ldconfig testing in configure: we make a significant\r
+effort to set RPATH appropriately when installing to a location that is\r
+not already searched (perhaps via LD_LIBRARY_PATH).  This currently does\r
+not apply to the Python bindings, so while you can install without\r
+LD_LIBRARY_PATH and still run the notmuch executable fine, you must set\r
+LD_LIBRARY_PATH to use the Python bindings.  That is the inconsistency I\r
+wanted to fix here.\r
+\r
+>> This is sort of a hack, but I don't know a less intrusive way to get\r
+>> libnotmuch.so from somewhere dlopen(3) doesn't already search.\r
+>> \r
+>> The absolute path version won't do the right thing in case of 'setup.py\r
+>> develop', otherwise we could use it in all cases.  It may still make\r
+>> sense to make the absolute path version take precedence.\r
+>\r
+> Well, if something like this is necessary and wanted (opinions\r
+> anyone?) at least let's not hardcode the assumption about the\r
+> directory layout but just walk up the tree until we find notmuch.so.3\r
+> or lib/notmuch.so.3. This way the bindings will find the correct\r
+> library even when they are included directly from within the source\r
+> tree.\r
+\r
+I actually wrote the more permissive version below, then decided I\r
+preferred the stricter behavior because there was less chance of\r
+accidentally finding a stale libnotmuch.so.3.  Note that in the source\r
+tree, notmuch-shared already has RPATH pointing to the install location\r
+so it's not valid without install.  The strict version of my patch has\r
+similar behavior in that Python bindings are only valid when installed.\r
+If you want to run them from the source tree, you'd have to add\r
+/path/to/notmuch/lib to LD_LIBRARY_PATH.\r
+\r
+diff --git a/bindings/python/notmuch/globals.py b/bindings/python/notmuch/globals.py\r
+index c7632c3..2fd383f 100644\r
+--- a/bindings/python/notmuch/globals.py\r
++++ b/bindings/python/notmuch/globals.py\r
+@@ -24,7 +24,16 @@ from ctypes import CDLL, Structure, POINTER\r
+ try:\r
+     nmlib = CDLL("libnotmuch.so.3")\r
+ except:\r
+-    raise ImportError("Could not find shared 'notmuch' library.")\r
++    import os.path\r
++    path = os.path.abspath(__file__)\r
++    while True:\r
++        path = os.path.dirname(path)\r
++        try:\r
++            nmlib = CDLL(os.path.join(path, 'libnotmuch.so.3'))\r
++            break\r
++        except:\r
++            if path == '/':\r
++                raise ImportError("Could not find shared 'notmuch' library.")\r
+ \r
+ from .compat import Python3StringMixIn, encode_utf8 as _str\r
+ \r
+\r
+> Otoh, adding such behavior might be 'surprising' and lead to many\r
+> problems down the road like spurious bug reports just because the\r
+> magic library finder locates a rogue libnotmuch.so.3 somewhere.\r
+>\r
+>> An alternative would be to find libnotmuch.so using the notmuch\r
+>> executable.\r
+>\r
+> How would you do that? fork'ing and exec'ing is not an option (and I'm\r
+> not sure what one could achieve by exec'ing it, but how else would you\r
+> talk to the dynamic linker?) , and poking around in binaries to get\r
+> their rpath isn't either in my opinion. And you would have to locate\r
+> the 'right' binary in the first place?\r
+\r
+I don't like the indirection either, but the binary is compiled with\r
+knowledge of prefix/RPATH, so if we wanted a single canonical location\r
+to specify this information, I would make it the binary.\r
+\r
+If you don't want to trust Python install directory hierarchy, we could\r
+have 'setup.py install' write some info about RPATH.\r