[RFC/PATCH] python: search parent lib directory for libnotmuch.so
Quoting Jed Brown (2013-04-09 16:57:05) > Justus Winter <4winter at informatik.uni-hamburg.de> writes: > > > > May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch > > to a non-standard location as unprivileged user and to make this > > library available I add its path to LD_LIBRARY_PATH. > > See libdir_in_ldconfig testing in configure: we make a significant > effort to set RPATH appropriately when installing to a location that is > not already searched (perhaps via LD_LIBRARY_PATH). This currently does > not apply to the Python bindings, so while you can install without > LD_LIBRARY_PATH and still run the notmuch executable fine, you must set > LD_LIBRARY_PATH to use the Python bindings. That is the inconsistency I > wanted to fix here. 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 > I don't like the indirection either, but the binary is compiled with > knowledge of prefix/RPATH, so if we wanted a single canonical location > to specify this information, I would make it the binary. > > If you don't want to trust Python install directory hierarchy, we could > have 'setup.py install' write some info about RPATH. 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. 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. Cheers, Justus
[RFC/PATCH] python: search parent lib directory for libnotmuch.so
Hi Jed,
Quoting Jed Brown (2013-04-09 04:47:26)
> If libnotmuch.so is installed to a path that is not searched by
> dlopen(3), we must import it using an absolute path because the Python
> bindings do not have the luxury of RPATH linking. So strip off the
> trailing directories from the install location and try CDLL with an
> absolute path.
May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch
to a non-standard location as unprivileged user and to make this
library available I add its path to LD_LIBRARY_PATH. It seems to work
just fine:
teythoon at thinkbox ~ % python -c 'import notmuch; print("\n".join(l.strip()
for l in open("/proc/self/maps") if "notmuch" in l))'
7f4214339000-7f4214357000 r-xp 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7f4214357000-7f4214557000 ---p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7f4214557000-7f4214559000 rw-p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
teythoon at thinkbox ~ % python3.2 -c 'import notmuch;
print("\n".join(l.strip() for l in open("/proc/self/maps") if "notmuch" in l))'
7fa5ecea4000-7fa5ecec2000 r-xp 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7fa5ecec2000-7fa5ed0c2000 ---p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7fa5ed0c2000-7fa5ed0c4000 rw-p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
teythoon at thinkbox ~ % env | grep '\.local'
PATH=/home/teythoon/.local/bin:/usr/local/stow/enlightenment/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
LOCAL=/home/teythoon/.local
PYTHONPATH=/home/teythoon/.local/lib/python2.7/site-packages
LD_LIBRARY_PATH=/home/teythoon/.local/lib
PKG_CONFIG_PATH=/home/teythoon/.local/lib/pkgconfig
teythoon at thinkbox ~ % unset LD_LIBRARY_PATH
teythoon at thinkbox ~ % python -c 'import notmuch; print("\n".join(l.strip()
for l in open("/proc/self/maps") if "notmuch" in l))'
7fd30b43c000-7fd30b457000 r-xp fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fd30b457000-7fd30b657000 ---p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fd30b657000-7fd30b658000 rw-p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
teythoon at thinkbox ~ % python3.2 -c 'import notmuch;
print("\n".join(l.strip() for l in open("/proc/self/maps") if "notmuch" in l))'
7fadb5704000-7fadb571f000 r-xp fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fadb571f000-7fadb591f000 ---p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fadb591f000-7fadb592 rw-p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
> ---
> This is sort of a hack, but I don't know a less intrusive way to get
> libnotmuch.so from somewhere dlopen(3) doesn't already search.
>
> The absolute path version won't do the right thing in case of 'setup.py
> develop', otherwise we could use it in all cases. It may still make
> sense to make the absolute path version take precedence.
Well, if something like this is necessary and wanted (opinions
anyone?) at least let's not hardcode the assumption about the
directory layout but just walk up the tree until we find notmuch.so.3
or lib/notmuch.so.3. This way the bindings will find the correct
library even when they are included directly from within the source
tree.
Otoh, adding such behavior might be 'surprising' and lead to many
problems down the road like spurious bug reports just because the
magic library finder locates a rogue libnotmuch.so.3 somewhere.
> An alternative would be to find libnotmuch.so using the notmuch
> executable.
How would you do that? fork'ing and exec'ing is not an option (and I'm
not sure what one could achieve by exec'ing it, but how else would you
talk to the dynamic linker?) , and poking around in binaries to get
their rpath isn't either in my opinion. And you would have to locate
the 'right' binary in the first place?
Cheers,
Justus
[PATCH] emacs: add missing paren to fix defun in notmuch-address.el.
On Tue, Apr 09 2013, David Bremner wrote: > Tomi Ollila writes: > >> On Tue, Apr 09 2013, Jed Brown wrote: >> >>> David Bremner writes: >>> Squashed sounds good to me too. Sorry I'm too lazy/busy at the moment to do it myself. >>> >>> I tested the attached and it's working as expected. Sent as an >>> attachment to preserve author information. >> >> LGTM (this time tested, too). Also compared diffs by hand, change as >> announced. >> comments in id:m26207wgyt.fsf at guru.guru-group.fi (amend!) apply. > > There seems to be a few warnings: > > In notmuch-bbdb/snarf-from: > notmuch-address.el:116:26:Warning: reference to free variable > `bbdb-get-addresses-headers' > > In notmuch-bbdb/snarf-to: > notmuch-address.el:122:29:Warning: reference to free variable > `bbdb-get-addresses-headers' > > In end of data: > notmuch-address.el:143:1:Warning: the following functions are not known to be > defined: bbdb-get-addresses, bbdb-update-records, notmuch-show-get-header > > Do we need a few defvars? For the above set, something like: (defvar bbdb-get-addresses-headers) (declare-function notmuch-show-get-header "notmuch-show" (header &optional props)) (declare-function bbdb-get-addresses "bbdb-com" (only-first-address uninteresting-senders get-header-content-function &rest get-header-content-function-args)) (declare-function bbdb-update-records "bbdb-com" (addrs auto-create-p offer-to-create)) > d Tomi
[PATCH] lib: Add a new prefix "list" to the search-terms syntax
On Mon, Apr 08, 2013 at 06:56:26PM -0300, David Bremner wrote: > Sure, no blame attaches. But somebody still needs to fix the patch or > convince us it doesn't need fixing. According to git grep -C2 _notmuch_message_gen_terms, there are seven calls to this function. Returned status checked zero times :-) > > Personally I see no reason in indexing list description. > That's an independent question. I guess there is the question of how > much overhead this introduces into In general, one or six unique descriptions per list (wild guess based on observation on my several long-running lists). Depending on list age and list administrator sanity. Indexing names for From/To/Cc fields brings bigger overhead, I guess. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130409/2492320e/attachment.pgp>
[RFC/PATCH] python: search parent lib directory for libnotmuch.so
Justus Winter <4winter at 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.
[RFC/PATCH] python: search parent lib directory for libnotmuch.so
Justus Winter <4winter at informatik.uni-hamburg.de> writes:
>
> May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch
> to a non-standard location as unprivileged user and to make this
> library available I add its path to LD_LIBRARY_PATH.
See libdir_in_ldconfig testing in configure: we make a significant
effort to set RPATH appropriately when installing to a location that is
not already searched (perhaps via LD_LIBRARY_PATH). This currently does
not apply to the Python bindings, so while you can install without
LD_LIBRARY_PATH and still run the notmuch executable fine, you must set
LD_LIBRARY_PATH to use the Python bindings. That is the inconsistency I
wanted to fix here.
>> This is sort of a hack, but I don't know a less intrusive way to get
>> libnotmuch.so from somewhere dlopen(3) doesn't already search.
>>
>> The absolute path version won't do the right thing in case of 'setup.py
>> develop', otherwise we could use it in all cases. It may still make
>> sense to make the absolute path version take precedence.
>
> Well, if something like this is necessary and wanted (opinions
> anyone?) at least let's not hardcode the assumption about the
> directory layout but just walk up the tree until we find notmuch.so.3
> or lib/notmuch.so.3. This way the bindings will find the correct
> library even when they are included directly from within the source
> tree.
I actually wrote the more permissive version below, then decided I
preferred the stricter behavior because there was less chance of
accidentally finding a stale libnotmuch.so.3. Note that in the source
tree, notmuch-shared already has RPATH pointing to the install location
so it's not valid without install. The strict version of my patch has
similar behavior in that Python bindings are only valid when installed.
If you want to run them from the source tree, you'd have to add
/path/to/notmuch/lib to LD_LIBRARY_PATH.
diff --git a/bindings/python/notmuch/globals.py
b/bindings/python/notmuch/globals.py
index c7632c3..2fd383f 100644
--- a/bindings/python/notmuch/globals.py
+++ b/bindings/python/notmuch/globals.py
@@ -24,7 +24,16 @@ from ctypes import CDLL, Structure, POINTER
try:
nmlib = CDLL("libnotmuch.so.3")
except:
-raise ImportError("Could not find shared 'notmuch' library.")
+import os.path
+path = os.path.abspath(__file__)
+while True:
+path = os.path.dirname(path)
+try:
+nmlib = CDLL(os.path.join(path, 'libnotmuch.so.3'))
+break
+except:
+if path == '/':
+raise ImportError("Could not find shared 'notmuch' library.")
from .compat import Python3StringMixIn, encode_utf8 as _str
> Otoh, adding such behavior might be 'surprising' and lead to many
> problems down the road like spurious bug reports just because the
> magic library finder locates a rogue libnotmuch.so.3 somewhere.
>
>> An alternative would be to find libnotmuch.so using the notmuch
>> executable.
>
> How would you do that? fork'ing and exec'ing is not an option (and I'm
> not sure what one could achieve by exec'ing it, but how else would you
> talk to the dynamic linker?) , and poking around in binaries to get
> their rpath isn't either in my opinion. And you would have to locate
> the 'right' binary in the first place?
I don't like the indirection either, but the binary is compiled with
knowledge of prefix/RPATH, so if we wanted a single canonical location
to specify this information, I would make it the binary.
If you don't want to trust Python install directory hierarchy, we could
have 'setup.py install' write some info about RPATH.
[PATCH] emacs: add missing paren to fix defun in notmuch-address.el.
On Tue, Apr 09 2013, Jed Brown wrote:
> David Bremner writes:
>
>> Squashed sounds good to me too. Sorry I'm too lazy/busy at the moment to
>> do it myself.
>
> I tested the attached and it's working as expected. Sent as an
> attachment to preserve author information.
LGTM (this time tested, too). Also compared diffs by hand, change as announced.
comments in id:m26207wgyt.fsf at guru.guru-group.fi (amend!) apply.
Tomi
>>From 5404ac5bf13f8b5349d5b94f9f2000e9d1832b83 Mon Sep 17 00:00:00 2001
> From: Daniel Bergey
> Date: Mon, 8 Apr 2013 19:55:04 -0500
> Subject: [PATCH] emacs: functions to import sender or recipient into BBDB [v2]
>
>>From a show buffer, notmuch-bbdb/snarf-from imports the sender into
> bbdb. notmuch-bbdb/snarf-to imports all recipients. Newly imported
> contacts are reported in the minibuffer / Messages buffer.
>
> Both functions use the BBDB parser to recognize email address formats.
>
> [v2] Fixes missing close parenthesis in original.
> Spotted by Karl Fogel .
> ---
> emacs/notmuch-address.el | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
> index 2bf762b..4eda098 100644
> --- a/emacs/notmuch-address.el
> +++ b/emacs/notmuch-address.el
> @@ -96,6 +96,47 @@ line."
> (when (notmuch-address-locate-command notmuch-address-command)
>(notmuch-address-message-insinuate))
>
> +;; functions to add sender / recipients to BBDB
> +
> +(defun notmuch-bbdb/snarf-headers (headers)
> + ;; Helper function to avoid code duplication in the two below
> + ;; headers should have the same format as bbdb-get-addresses-headers
> +
> + ;; bbdb-get-addresses reads these
> + ;; Ugh, pass-by-global
> + (let ((addrs (bbdb-get-addresses nil nil 'notmuch-bbdb/get-header-content))
> + (bbdb-get-addresses-headers headers) ; headers to read
> + (bbdb-gag-messages t)) ; suppress m/n processed message)
> +(bbdb-update-records addrs t t)))
> +
> +(defun notmuch-bbdb/snarf-from ()
> + "Import the sender of the current message into BBDB"
> + (interactive)
> + (notmuch-bbdb/snarf-headers
> + (list (assoc 'authors bbdb-get-addresses-headers
> +
> +(defun notmuch-bbdb/snarf-to ()
> + "Import all recipients of the current message into BBDB"
> + (interactive)
> + (notmuch-bbdb/snarf-headers
> + (list (assoc 'recipients bbdb-get-addresses-headers
> +
> +(defvar notmuch-bbdb/header-by-name
> + ;; both are case sensitive
> + '( ("From" . :From)
> + ("To" . :To)
> + ("CC" . :Cc)
> + ("BCC" . :Bcc)
> + ("Resent-From" . nil)
> + ("Reply-To" . nil)
> + ("Resent-To" . nil)
> + ("Resent-CC" . nil))
> + "Alist for dispatching header symbols as used by notmuch-show-get-header
> +from strings as used by bbdb-get-addresses")
> +
> +(defun notmuch-bbdb/get-header-content (name)
> + (notmuch-show-get-header (cdr (assoc name notmuch-bbdb/header-by-name
> +
> ;;
>
> (provide 'notmuch-address)
> --
> 1.8.2.1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: add missing paren to fix defun in notmuch-address.el.
Tomi Ollila writes: > On Tue, Apr 09 2013, Jed Brown wrote: > >> David Bremner writes: >> >>> Squashed sounds good to me too. Sorry I'm too lazy/busy at the moment to >>> do it myself. >> >> I tested the attached and it's working as expected. Sent as an >> attachment to preserve author information. > > LGTM (this time tested, too). Also compared diffs by hand, change as > announced. > comments in id:m26207wgyt.fsf at guru.guru-group.fi (amend!) apply. There seems to be a few warnings: In notmuch-bbdb/snarf-from: notmuch-address.el:116:26:Warning: reference to free variable `bbdb-get-addresses-headers' In notmuch-bbdb/snarf-to: notmuch-address.el:122:29:Warning: reference to free variable `bbdb-get-addresses-headers' In end of data: notmuch-address.el:143:1:Warning: the following functions are not known to be defined: bbdb-get-addresses, bbdb-update-records, notmuch-show-get-header Do we need a few defvars? d
Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so
Justus Winter <4win...@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. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so
Quoting Jed Brown (2013-04-09 16:57:05) > Justus Winter <4win...@informatik.uni-hamburg.de> writes: > > > > May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch > > to a non-standard location as unprivileged user and to make this > > library available I add its path to LD_LIBRARY_PATH. > > See libdir_in_ldconfig testing in configure: we make a significant > effort to set RPATH appropriately when installing to a location that is > not already searched (perhaps via LD_LIBRARY_PATH). This currently does > not apply to the Python bindings, so while you can install without > LD_LIBRARY_PATH and still run the notmuch executable fine, you must set > LD_LIBRARY_PATH to use the Python bindings. That is the inconsistency I > wanted to fix here. 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 > I don't like the indirection either, but the binary is compiled with > knowledge of prefix/RPATH, so if we wanted a single canonical location > to specify this information, I would make it the binary. > > If you don't want to trust Python install directory hierarchy, we could > have 'setup.py install' write some info about RPATH. 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. 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. Cheers, Justus ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so
Justus Winter <4win...@informatik.uni-hamburg.de> writes:
>
> May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch
> to a non-standard location as unprivileged user and to make this
> library available I add its path to LD_LIBRARY_PATH.
See libdir_in_ldconfig testing in configure: we make a significant
effort to set RPATH appropriately when installing to a location that is
not already searched (perhaps via LD_LIBRARY_PATH). This currently does
not apply to the Python bindings, so while you can install without
LD_LIBRARY_PATH and still run the notmuch executable fine, you must set
LD_LIBRARY_PATH to use the Python bindings. That is the inconsistency I
wanted to fix here.
>> This is sort of a hack, but I don't know a less intrusive way to get
>> libnotmuch.so from somewhere dlopen(3) doesn't already search.
>>
>> The absolute path version won't do the right thing in case of 'setup.py
>> develop', otherwise we could use it in all cases. It may still make
>> sense to make the absolute path version take precedence.
>
> Well, if something like this is necessary and wanted (opinions
> anyone?) at least let's not hardcode the assumption about the
> directory layout but just walk up the tree until we find notmuch.so.3
> or lib/notmuch.so.3. This way the bindings will find the correct
> library even when they are included directly from within the source
> tree.
I actually wrote the more permissive version below, then decided I
preferred the stricter behavior because there was less chance of
accidentally finding a stale libnotmuch.so.3. Note that in the source
tree, notmuch-shared already has RPATH pointing to the install location
so it's not valid without install. The strict version of my patch has
similar behavior in that Python bindings are only valid when installed.
If you want to run them from the source tree, you'd have to add
/path/to/notmuch/lib to LD_LIBRARY_PATH.
diff --git a/bindings/python/notmuch/globals.py
b/bindings/python/notmuch/globals.py
index c7632c3..2fd383f 100644
--- a/bindings/python/notmuch/globals.py
+++ b/bindings/python/notmuch/globals.py
@@ -24,7 +24,16 @@ from ctypes import CDLL, Structure, POINTER
try:
nmlib = CDLL("libnotmuch.so.3")
except:
-raise ImportError("Could not find shared 'notmuch' library.")
+import os.path
+path = os.path.abspath(__file__)
+while True:
+path = os.path.dirname(path)
+try:
+nmlib = CDLL(os.path.join(path, 'libnotmuch.so.3'))
+break
+except:
+if path == '/':
+raise ImportError("Could not find shared 'notmuch' library.")
from .compat import Python3StringMixIn, encode_utf8 as _str
> Otoh, adding such behavior might be 'surprising' and lead to many
> problems down the road like spurious bug reports just because the
> magic library finder locates a rogue libnotmuch.so.3 somewhere.
>
>> An alternative would be to find libnotmuch.so using the notmuch
>> executable.
>
> How would you do that? fork'ing and exec'ing is not an option (and I'm
> not sure what one could achieve by exec'ing it, but how else would you
> talk to the dynamic linker?) , and poking around in binaries to get
> their rpath isn't either in my opinion. And you would have to locate
> the 'right' binary in the first place?
I don't like the indirection either, but the binary is compiled with
knowledge of prefix/RPATH, so if we wanted a single canonical location
to specify this information, I would make it the binary.
If you don't want to trust Python install directory hierarchy, we could
have 'setup.py install' write some info about RPATH.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so
Hi Jed,
Quoting Jed Brown (2013-04-09 04:47:26)
> If libnotmuch.so is installed to a path that is not searched by
> dlopen(3), we must import it using an absolute path because the Python
> bindings do not have the luxury of RPATH linking. So strip off the
> trailing directories from the install location and try CDLL with an
> absolute path.
May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch
to a non-standard location as unprivileged user and to make this
library available I add its path to LD_LIBRARY_PATH. It seems to work
just fine:
teythoon@thinkbox ~ % python -c 'import notmuch; print("\n".join(l.strip() for
l in open("/proc/self/maps") if "notmuch" in l))'
7f4214339000-7f4214357000 r-xp 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7f4214357000-7f4214557000 ---p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7f4214557000-7f4214559000 rw-p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
teythoon@thinkbox ~ % python3.2 -c 'import notmuch; print("\n".join(l.strip()
for l in open("/proc/self/maps") if "notmuch" in l))'
7fa5ecea4000-7fa5ecec2000 r-xp 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7fa5ecec2000-7fa5ed0c2000 ---p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
7fa5ed0c2000-7fa5ed0c4000 rw-p 0001e000 00:17 2120750
/home/teythoon/.local/stow/notmuch/lib/libnotmuch.so.3.0.0
teythoon@thinkbox ~ % env | grep '\.local'
PATH=/home/teythoon/.local/bin:/usr/local/stow/enlightenment/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
LOCAL=/home/teythoon/.local
PYTHONPATH=/home/teythoon/.local/lib/python2.7/site-packages
LD_LIBRARY_PATH=/home/teythoon/.local/lib
PKG_CONFIG_PATH=/home/teythoon/.local/lib/pkgconfig
teythoon@thinkbox ~ % unset LD_LIBRARY_PATH
teythoon@thinkbox ~ % python -c 'import notmuch; print("\n".join(l.strip() for
l in open("/proc/self/maps") if "notmuch" in l))'
7fd30b43c000-7fd30b457000 r-xp fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fd30b457000-7fd30b657000 ---p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fd30b657000-7fd30b658000 rw-p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
teythoon@thinkbox ~ % python3.2 -c 'import notmuch; print("\n".join(l.strip()
for l in open("/proc/self/maps") if "notmuch" in l))'
7fadb5704000-7fadb571f000 r-xp fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fadb571f000-7fadb591f000 ---p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
7fadb591f000-7fadb592 rw-p 0001b000 fe:00 4241
/usr/lib/libnotmuch.so.3.0.0
> ---
> This is sort of a hack, but I don't know a less intrusive way to get
> libnotmuch.so from somewhere dlopen(3) doesn't already search.
>
> The absolute path version won't do the right thing in case of 'setup.py
> develop', otherwise we could use it in all cases. It may still make
> sense to make the absolute path version take precedence.
Well, if something like this is necessary and wanted (opinions
anyone?) at least let's not hardcode the assumption about the
directory layout but just walk up the tree until we find notmuch.so.3
or lib/notmuch.so.3. This way the bindings will find the correct
library even when they are included directly from within the source
tree.
Otoh, adding such behavior might be 'surprising' and lead to many
problems down the road like spurious bug reports just because the
magic library finder locates a rogue libnotmuch.so.3 somewhere.
> An alternative would be to find libnotmuch.so using the notmuch
> executable.
How would you do that? fork'ing and exec'ing is not an option (and I'm
not sure what one could achieve by exec'ing it, but how else would you
talk to the dynamic linker?) , and poking around in binaries to get
their rpath isn't either in my opinion. And you would have to locate
the 'right' binary in the first place?
Cheers,
Justus
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: add missing paren to fix defun in notmuch-address.el.
On Tue, Apr 09 2013, David Bremner wrote: > Tomi Ollila writes: > >> On Tue, Apr 09 2013, Jed Brown wrote: >> >>> David Bremner writes: >>> Squashed sounds good to me too. Sorry I'm too lazy/busy at the moment to do it myself. >>> >>> I tested the attached and it's working as expected. Sent as an >>> attachment to preserve author information. >> >> LGTM (this time tested, too). Also compared diffs by hand, change as >> announced. >> comments in id:m26207wgyt@guru.guru-group.fi (amend!) apply. > > There seems to be a few warnings: > > In notmuch-bbdb/snarf-from: > notmuch-address.el:116:26:Warning: reference to free variable > `bbdb-get-addresses-headers' > > In notmuch-bbdb/snarf-to: > notmuch-address.el:122:29:Warning: reference to free variable > `bbdb-get-addresses-headers' > > In end of data: > notmuch-address.el:143:1:Warning: the following functions are not known to be > defined: bbdb-get-addresses, bbdb-update-records, notmuch-show-get-header > > Do we need a few defvars? For the above set, something like: (defvar bbdb-get-addresses-headers) (declare-function notmuch-show-get-header "notmuch-show" (header &optional props)) (declare-function bbdb-get-addresses "bbdb-com" (only-first-address uninteresting-senders get-header-content-function &rest get-header-content-function-args)) (declare-function bbdb-update-records "bbdb-com" (addrs auto-create-p offer-to-create)) > d Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: add missing paren to fix defun in notmuch-address.el.
Tomi Ollila writes: > On Tue, Apr 09 2013, Jed Brown wrote: > >> David Bremner writes: >> >>> Squashed sounds good to me too. Sorry I'm too lazy/busy at the moment to >>> do it myself. >> >> I tested the attached and it's working as expected. Sent as an >> attachment to preserve author information. > > LGTM (this time tested, too). Also compared diffs by hand, change as > announced. > comments in id:m26207wgyt@guru.guru-group.fi (amend!) apply. There seems to be a few warnings: In notmuch-bbdb/snarf-from: notmuch-address.el:116:26:Warning: reference to free variable `bbdb-get-addresses-headers' In notmuch-bbdb/snarf-to: notmuch-address.el:122:29:Warning: reference to free variable `bbdb-get-addresses-headers' In end of data: notmuch-address.el:143:1:Warning: the following functions are not known to be defined: bbdb-get-addresses, bbdb-update-records, notmuch-show-get-header Do we need a few defvars? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib: Add a new prefix "list" to the search-terms syntax
On Mon, Apr 08, 2013 at 06:56:26PM -0300, David Bremner wrote: > Sure, no blame attaches. But somebody still needs to fix the patch or > convince us it doesn't need fixing. According to git grep -C2 _notmuch_message_gen_terms, there are seven calls to this function. Returned status checked zero times :-) > > Personally I see no reason in indexing list description. > That's an independent question. I guess there is the question of how > much overhead this introduces into In general, one or six unique descriptions per list (wild guess based on observation on my several long-running lists). Depending on list age and list administrator sanity. Indexing names for From/To/Cc fields brings bigger overhead, I guess. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
