45/b51aed6dfe59939a7c991d92b610db354a4c41

   1 Return-Path: <five9a2@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id CB32C431FBC\r
   6         for <notmuch@notmuchmail.org>; Tue,  9 Apr 2013 07:57:08 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.301\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.301 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=1, \r
  13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 2X54zkeGnGSx for <notmuch@notmuchmail.org>;\r
  17         Tue,  9 Apr 2013 07:57:08 -0700 (PDT)\r
  18 Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com\r
  19         [209.85.223.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 33E79431FAE\r
  22         for <notmuch@notmuchmail.org>; Tue,  9 Apr 2013 07:57:08 -0700 (PDT)\r
  23 Received: by mail-ie0-f177.google.com with SMTP id tp5so8620857ieb.36\r
  24         for <notmuch@notmuchmail.org>; Tue, 09 Apr 2013 07:57:07 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
  26         h=x-received:sender:from:to:cc:subject:in-reply-to:references\r
  27         :user-agent:date:message-id:mime-version:content-type;\r
  28         bh=23WQoIPTgSk0tuJozkAUgP5/DJEnd+i86uLP3bjQiXs=;\r
  29         b=YwC5qlK/ezEGSPAZE0WOg1G+bVNw7tWd20e5h51Qs3MaBXgEqvFZ/3xLtmzBNTTJIh\r
  30         NNfj1HSNCITlh7+3MoIlh4ciZXIlVm7SWZYgiUfRVonEhRr5/YFQsV3+tD6AvvJIEJXr\r
  31         ABOTE33GIjhqkeM6h+0PUc6Ywi6tV8+u7+awyLcdErDiQygNgzjmWrIO9cg42rqGxGJ+\r
  32         VZWBiiKdvAI2ETOE1iaSdu/2ChOkX4Iousu0NAzKRwI1Z5zxfMOLI/wvtXmBPI9InVS0\r
  33         0i0gwHMnLPHrcl20B5U72siFYEo9Q2pg6DVHkb1rs8lsie0FY5VRjgywFIeTJk3DhWiy\r
  34         brDQ==\r
  35 X-Received: by 10.50.7.69 with SMTP id h5mr10905593iga.69.1365519426923;\r
  36         Tue, 09 Apr 2013 07:57:06 -0700 (PDT)\r
  37 Received: from localhost (vis-v410v070.mcs.anl-external.org. [130.202.17.70])\r
  38         by mx.google.com with ESMTPS id\r
  39         ip2sm22891004igc.5.2013.04.09.07.57.05\r
  40         (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
  41         Tue, 09 Apr 2013 07:57:06 -0700 (PDT)\r
  42 Sender: Jed Brown <five9a2@gmail.com>\r
  43 From: Jed Brown <jed@59A2.org>\r
  44 To: Justus Winter <4winter@informatik.uni-hamburg.de>, notmuch@notmuchmail.org\r
  45 Subject: Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so\r
  46 In-Reply-To: <20130409141333.7736.41695@thinkbox.jade-hamburg.de>\r
  47 References: <1365475646-22926-1-git-send-email-jed@59A2.org>\r
  48         <20130409141333.7736.41695@thinkbox.jade-hamburg.de>\r
  49 User-Agent: Notmuch/0.15.2+78~g5404ac5 (http://notmuchmail.org) Emacs/24.3.1\r
  50         (x86_64-unknown-linux-gnu)\r
  51 Date: Tue, 09 Apr 2013 09:57:05 -0500\r
  52 Message-ID: <87obdn7nwe.fsf@mcs.anl.gov>\r
  53 MIME-Version: 1.0\r
  54 Content-Type: text/plain\r
  55 Cc: Sebastian Spaeth <Sebastian@SSpaeth.de>\r
  56 X-BeenThere: notmuch@notmuchmail.org\r
  57 X-Mailman-Version: 2.1.13\r
  58 Precedence: list\r
  59 List-Id: "Use and development of the notmuch mail system."\r
  60         <notmuch.notmuchmail.org>\r
  61 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  62         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  63 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  64 List-Post: <mailto:notmuch@notmuchmail.org>\r
  65 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  66 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  67         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  68 X-List-Received-Date: Tue, 09 Apr 2013 14:57:09 -0000\r
  69 \r
  70 Justus Winter <4winter@informatik.uni-hamburg.de> writes:\r
  71 >\r
  72 > May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch\r
  73 > to a non-standard location as unprivileged user and to make this\r
  74 > library available I add its path to LD_LIBRARY_PATH. \r
  75 \r
  76 See libdir_in_ldconfig testing in configure: we make a significant\r
  77 effort to set RPATH appropriately when installing to a location that is\r
  78 not already searched (perhaps via LD_LIBRARY_PATH).  This currently does\r
  79 not apply to the Python bindings, so while you can install without\r
  80 LD_LIBRARY_PATH and still run the notmuch executable fine, you must set\r
  81 LD_LIBRARY_PATH to use the Python bindings.  That is the inconsistency I\r
  82 wanted to fix here.\r
  83 \r
  84 >> This is sort of a hack, but I don't know a less intrusive way to get\r
  85 >> libnotmuch.so from somewhere dlopen(3) doesn't already search.\r
  86 >> \r
  87 >> The absolute path version won't do the right thing in case of 'setup.py\r
  88 >> develop', otherwise we could use it in all cases.  It may still make\r
  89 >> sense to make the absolute path version take precedence.\r
  90 >\r
  91 > Well, if something like this is necessary and wanted (opinions\r
  92 > anyone?) at least let's not hardcode the assumption about the\r
  93 > directory layout but just walk up the tree until we find notmuch.so.3\r
  94 > or lib/notmuch.so.3. This way the bindings will find the correct\r
  95 > library even when they are included directly from within the source\r
  96 > tree.\r
  97 \r
  98 I actually wrote the more permissive version below, then decided I\r
  99 preferred the stricter behavior because there was less chance of\r
 100 accidentally finding a stale libnotmuch.so.3.  Note that in the source\r
 101 tree, notmuch-shared already has RPATH pointing to the install location\r
 102 so it's not valid without install.  The strict version of my patch has\r
 103 similar behavior in that Python bindings are only valid when installed.\r
 104 If you want to run them from the source tree, you'd have to add\r
 105 /path/to/notmuch/lib to LD_LIBRARY_PATH.\r
 106 \r
 107 diff --git a/bindings/python/notmuch/globals.py b/bindings/python/notmuch/globals.py\r
 108 index c7632c3..2fd383f 100644\r
 109 --- a/bindings/python/notmuch/globals.py\r
 110 +++ b/bindings/python/notmuch/globals.py\r
 111 @@ -24,7 +24,16 @@ from ctypes import CDLL, Structure, POINTER\r
 112  try:\r
 113      nmlib = CDLL("libnotmuch.so.3")\r
 114  except:\r
 115 -    raise ImportError("Could not find shared 'notmuch' library.")\r
 116 +    import os.path\r
 117 +    path = os.path.abspath(__file__)\r
 118 +    while True:\r
 119 +        path = os.path.dirname(path)\r
 120 +        try:\r
 121 +            nmlib = CDLL(os.path.join(path, 'libnotmuch.so.3'))\r
 122 +            break\r
 123 +        except:\r
 124 +            if path == '/':\r
 125 +                raise ImportError("Could not find shared 'notmuch' library.")\r
 126  \r
 127  from .compat import Python3StringMixIn, encode_utf8 as _str\r
 128  \r
 129 \r
 130 > Otoh, adding such behavior might be 'surprising' and lead to many\r
 131 > problems down the road like spurious bug reports just because the\r
 132 > magic library finder locates a rogue libnotmuch.so.3 somewhere.\r
 133 >\r
 134 >> An alternative would be to find libnotmuch.so using the notmuch\r
 135 >> executable.\r
 136 >\r
 137 > How would you do that? fork'ing and exec'ing is not an option (and I'm\r
 138 > not sure what one could achieve by exec'ing it, but how else would you\r
 139 > talk to the dynamic linker?) , and poking around in binaries to get\r
 140 > their rpath isn't either in my opinion. And you would have to locate\r
 141 > the 'right' binary in the first place?\r
 142 \r
 143 I don't like the indirection either, but the binary is compiled with\r
 144 knowledge of prefix/RPATH, so if we wanted a single canonical location\r
 145 to specify this information, I would make it the binary.\r
 146 \r
 147 If you don't want to trust Python install directory hierarchy, we could\r
 148 have 'setup.py install' write some info about RPATH.\r