[bug] Python bindings fail to load shared libraries in MacOS El Capitan

[bug] Python bindings fail to load shared libraries in MacOS El Capitan

[Robert Künnemann]

Hi!

The python bindings fail to load libnotmuch with the new version of
MacOS X (10.11). Running "afew", a tagger written in Python gives:

Traceback (most recent call last):
  File "/usr/local/Cellar/afew/HEAD/libexec/bin/afew", line 9, in <module>
    load_entry_point('afew==0.0.0', 'console_scripts', 'afew')()
  File "build/bdist.macosx-10.9-x86_64/egg/pkg_resources.py", line 356, in load_entry_point
    """Return `name` entry point of `group` for `dist` or raise ImportError"""
  File "build/bdist.macosx-10.9-x86_64/egg/pkg_resources.py", line 2476, in load_entry_point
    except ValueError:
  File "build/bdist.macosx-10.9-x86_64/egg/pkg_resources.py", line 2190, in load
    parse_map = classmethod(parse_map)
  File "/Library/Python/2.7/site-packages/afew-0.0.0-py2.7.egg/afew/commands.py", line 27, in <module>
    from afew.Database import Database
  File "/Library/Python/2.7/site-packages/afew-0.0.0-py2.7.egg/afew/Database.py", line 23, in <module>
    import notmuch
  File "/usr/local/lib/python2.7/site-packages/notmuch/__init__.py", line 54, in <module>
    from .database import Database
  File "/usr/local/lib/python2.7/site-packages/notmuch/database.py", line 24, in <module>
    from .globals import (
  File "/usr/local/lib/python2.7/site-packages/notmuch/globals.py", line 32, in <module>
    raise ImportError("Could not find shared 'notmuch' library.")
ImportError: Could not find shared 'notmuch' library.

Setting DYLD_FALLBACK_LIBRARY_PATH to /usr/local/lib (where
libnotmuch4.dylib resides) did not help.

As Eric Wang's response in this thread suggested
http://stackoverflow.com/questions/32905322/oserror-dlopenlibsystem-dylib-6-image-not-found
I've substituted 

nmlib = CDLL("libnotmuch.so.{0:s}".format(SOVERSION))

in globals.py

nmlib = CDLL("/usr/local/lib/libnotmuch.{0:s}.dylib".format(SOVERSION))

This resolved the problem for me.

With kind regards, Robert Künnemann

Re: [bug] Python bindings fail to load shared libraries in MacOS El Capitan

[David Bremner]

Robert Künnemann <robert@kunnemann.de> writes:
>
> nmlib = CDLL("libnotmuch.so.{0:s}".format(SOVERSION))
>
> in globals.py
>
> nmlib = CDLL("/usr/local/lib/libnotmuch.{0:s}.dylib".format(SOVERSION))

In recent versions of notmuch there's already code there to detect MacOS
and do something different. Are you saying that detection is not
working? Also, it seems like you are coding the absolute path name of
the library. Is that really necessary?

d

Re: [bug] Python bindings fail to load shared libraries in MacOS El Capitan

[Robert Künnemann]

Hi!

On 21/10, David Bremner wrote:
>Robert Künnemann <robert@kunnemann.de> writes:
>>
>> nmlib = CDLL("libnotmuch.so.{0:s}".format(SOVERSION))
>>
>> in globals.py
>>
>> nmlib = CDLL("/usr/local/lib/libnotmuch.{0:s}.dylib".format(SOVERSION))
>
>In recent versions of notmuch there's already code there to detect MacOS
>and do something different. Are you saying that detection is not
>working?
It is working and adds the suffix ".dylyb" to the library name.

>Also, it seems like you are coding the absolute path name of
>the library. Is that really necessary?
It seems so. Two responses in the thread I mentioned
http://stackoverflow.com/questions/32905322/oserror-dlopenlibsystem-dylib-6-image-not-found
suggest the same, and it solved the issue for me.

I am happy to try out other, better solutions.

Cheers, Robert

Re: [bug] Python bindings fail to load shared libraries in MacOS El Capitan

[David Bremner]

Robert Künnemann <robert@kunnemann.de> writes:

>>Also, it seems like you are coding the absolute path name of
>>the library. Is that really necessary?
> It seems so. Two responses in the thread I mentioned
> http://stackoverflow.com/questions/32905322/oserror-dlopenlibsystem-dylib-6-image-not-found
> suggest the same, and it solved the issue for me.

I don't think hard-coding the install location of the library is
something we can do upstream, so it probably needs someone with a Mac to
roll up their sleeves and add something to use the prefix information
from Makefile.config. Hopefully this could also eliminate the current
runtime check for the system type.

d