Hi there,

I believe there's potentially a bug in the handling of signposting the
notmuch dynamic library when installed in non-standard prefixes. For
example, Homebrew moved their standard prefix on macOS from /usr/local
to /opt/homebrew for machines running with Apple's ARM-based chip(s),
which has caused another piece of software (https://github.com/pazz/alot)
to fail to find `notmuch.dylib` because of the way `globals.py` handles it.

With notmuch installed in /opt/homebrew and notmuch's library available
in /opt/homebrew/lib, alot builds successfully but then aborts at
runtime because it cannot find the shared library:

```
~> alot
Traceback (most recent call last):
  File
"/opt/homebrew/opt/notmuch/lib/python3.9/site-packages/notmuch/globals.py",
line 28, in <module>
    nmlib = CDLL("libnotmuch.{0:s}.dylib".format(SOVERSION))
  File
"/opt/homebrew/Cellar/python@3.9/3.9.4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/ctypes/__init__.py",
line 374, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlopen(libnotmuch.5.dylib, 6): image not found
```

I've attached a patch that resolves the issue for me locally using
Homebrew installed in /opt/homebrew, and I expect as long as a user's
custom python was configured to search the path it was installed inside
(by modifying `DEFAULT_LIBRARY_FALLBACK` in `macholib/dyld.py`) it
should work for any custom prefix on macOS. You may well be able to
achieve the same result a different way, my python knowledge is fairly
rusty.

Hope this helps,

Dominyk
===
Sent from macOS