Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so
authorJustus Winter <4winter@informatik.uni-hamburg.de>
Tue, 9 Apr 2013 14:13:33 +0000 (16:13 +0200)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:54:19 +0000 (09:54 -0800)
21/0f7f6279761d795214462cb4ba1836443c5acf [new file with mode: 0644]

diff --git a/21/0f7f6279761d795214462cb4ba1836443c5acf b/21/0f7f6279761d795214462cb4ba1836443c5acf
new file mode 100644 (file)
index 0000000..2c52299
--- /dev/null
@@ -0,0 +1,148 @@
+Return-Path: <teythoon@jade-hamburg.de>\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 11534431FBC\r
+       for <notmuch@notmuchmail.org>; Tue,  9 Apr 2013 07:13:43 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       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 amDuD0dZCYXf for <notmuch@notmuchmail.org>;\r
+       Tue,  9 Apr 2013 07:13:42 -0700 (PDT)\r
+Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 1F669431FAE\r
+       for <notmuch@notmuchmail.org>; Tue,  9 Apr 2013 07:13:42 -0700 (PDT)\r
+Received: from mail.jade-hamburg.de (mail.jade-hamburg.de [85.183.11.228])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by mail.cryptobitch.de (Postfix) with ESMTPSA id A3A0F601883\r
+       for <notmuch@notmuchmail.org>; Tue,  9 Apr 2013 16:13:39 +0200 (CEST)\r
+Received: by mail.jade-hamburg.de (Postfix, from userid 401)\r
+       id 13276DF2A3; Tue,  9 Apr 2013 16:13:38 +0200 (CEST)\r
+Received: from thinkbox.jade-hamburg.de (cryptobitch.de [88.198.7.68])\r
+       (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
+       (No client certificate requested) (Authenticated sender: teythoon)\r
+       by mail.jade-hamburg.de (Postfix) with ESMTPSA id 74A42DF28B;\r
+       Tue,  9 Apr 2013 16:13:35 +0200 (CEST)\r
+Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.80)\r
+       (envelope-from <teythoon@thinkbox.jade-hamburg.de>)\r
+       id 1UPZIk-0004Jv-43; Tue, 09 Apr 2013 16:13:34 +0200\r
+Content-Type: text/plain; charset="utf-8"\r
+MIME-Version: 1.0\r
+Content-Transfer-Encoding: quoted-printable\r
+To: Jed Brown <jed@59A2.org>,  notmuch@notmuchmail.org\r
+From: Justus Winter <4winter@informatik.uni-hamburg.de>\r
+In-Reply-To: <1365475646-22926-1-git-send-email-jed@59A2.org>\r
+References: <1365475646-22926-1-git-send-email-jed@59A2.org>\r
+Message-ID: <20130409141333.7736.41695@thinkbox.jade-hamburg.de>\r
+User-Agent: alot/0.3.3+\r
+Subject: Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so\r
+Date: Tue, 09 Apr 2013 16:13:33 +0200\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:13:43 -0000\r
+\r
+Hi Jed,\r
+\r
+Quoting Jed Brown (2013-04-09 04:47:26)\r
+> If libnotmuch.so is installed to a path that is not searched by\r
+> dlopen(3), we must import it using an absolute path because the Python\r
+> bindings do not have the luxury of RPATH linking.  So strip off the\r
+> trailing directories from the install location and try CDLL with an\r
+> absolute path.\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. It seems to work\r
+just fine:\r
+\r
+teythoon@thinkbox ~ % python -c 'import notmuch; print("\n".join(l.strip() =\r
+for l in open("/proc/self/maps") if "notmuch" in l))'\r
+7f4214339000-7f4214357000 r-xp 00000000 00:17 2120750                    /h=\r
+ome/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0\r
+7f4214357000-7f4214557000 ---p 0001e000 00:17 2120750                    /h=\r
+ome/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0\r
+7f4214557000-7f4214559000 rw-p 0001e000 00:17 2120750                    /h=\r
+ome/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0\r
+teythoon@thinkbox ~ % python3.2 -c 'import notmuch; print("\n".join(l.strip=\r
+() for l in open("/proc/self/maps") if "notmuch" in l))'\r
+7fa5ecea4000-7fa5ecec2000 r-xp 00000000 00:17 2120750                    /h=\r
+ome/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0\r
+7fa5ecec2000-7fa5ed0c2000 ---p 0001e000 00:17 2120750                    /h=\r
+ome/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0\r
+7fa5ed0c2000-7fa5ed0c4000 rw-p 0001e000 00:17 2120750                    /h=\r
+ome/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0\r
+teythoon@thinkbox ~ % env | grep '\.local'\r
+PATH=3D/home/teythoon/.local/bin:/usr/local/stow/enlightenment/bin:/usr/loc=\r
+al/bin:/usr/bin:/bin:/usr/games\r
+LOCAL=3D/home/teythoon/.local\r
+PYTHONPATH=3D/home/teythoon/.local/lib/python2.7/site-packages\r
+LD_LIBRARY_PATH=3D/home/teythoon/.local/lib\r
+PKG_CONFIG_PATH=3D/home/teythoon/.local/lib/pkgconfig\r
+teythoon@thinkbox ~ % unset LD_LIBRARY_PATH\r
+teythoon@thinkbox ~ % python -c 'import notmuch; print("\n".join(l.strip() =\r
+for l in open("/proc/self/maps") if "notmuch" in l))'\r
+7fd30b43c000-7fd30b457000 r-xp 00000000 fe:00 4241                       /u=\r
+sr/lib/libnotmuch.so.3.0.0\r
+7fd30b457000-7fd30b657000 ---p 0001b000 fe:00 4241                       /u=\r
+sr/lib/libnotmuch.so.3.0.0\r
+7fd30b657000-7fd30b658000 rw-p 0001b000 fe:00 4241                       /u=\r
+sr/lib/libnotmuch.so.3.0.0\r
+teythoon@thinkbox ~ % python3.2 -c 'import notmuch; print("\n".join(l.strip=\r
+() for l in open("/proc/self/maps") if "notmuch" in l))'\r
+7fadb5704000-7fadb571f000 r-xp 00000000 fe:00 4241                       /u=\r
+sr/lib/libnotmuch.so.3.0.0\r
+7fadb571f000-7fadb591f000 ---p 0001b000 fe:00 4241                       /u=\r
+sr/lib/libnotmuch.so.3.0.0\r
+7fadb591f000-7fadb5920000 rw-p 0001b000 fe:00 4241                       /u=\r
+sr/lib/libnotmuch.so.3.0.0\r
+\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
+\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
+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
+Cheers,\r
+Justus\r