Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import error #8

Open
yr-wang-hit opened this issue May 23, 2022 · 3 comments
Open

import error #8

yr-wang-hit opened this issue May 23, 2022 · 3 comments

Comments

@yr-wang-hit
Copy link

By
from fswatch import Monitor

The error is : undefined symbol: fsw_init_library
What happens and how to resolve it?
Thanks a lot .

jun0 added a commit to jun0/pyfswatch that referenced this issue Jun 30, 2022
On Ubuntu GNU/Linux (and probably other similar systems), you need to
call ctypes.util.find_library without the "lib" prefix.
@terzeron
Copy link

terzeron commented Nov 1, 2022

Hello,
I got an error in importing fswatch in silicon mac, macos 12.2.
This may be a bug made by combination of both find_library() of ctypes.util and installation path of homebrew of silicon mac.

>>> import fswatch
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/terzeron/.pyenv/versions/tm/lib/python3.10/site-packages/fswatch/__init__.py", line 2, in <module>
    from .fswatch import Monitor
  File "/Users/terzeron/.pyenv/versions/tm/lib/python3.10/site-packages/fswatch/fswatch.py", line 4, in <module>
    from fswatch import libfswatch
  File "/Users/terzeron/.pyenv/versions/tm/lib/python3.10/site-packages/fswatch/libfswatch.py", line 9, in <module>
    fsw_init_library = lib.fsw_init_library
  File "/Users/terzeron/.pyenv/versions/3.10.7/lib/python3.10/ctypes/__init__.py", line 387, in __getattr__
    func = self.__getitem__(name)
  File "/Users/terzeron/.pyenv/versions/3.10.7/lib/python3.10/ctypes/__init__.py", line 392, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, fsw_init_library): symbol not found

The official documentation of Python ctypes says that

If wrapping a shared library with ctypes, 
it may be better to determine the shared library name at development time, 
and hardcode that into the wrapper module 
instead of using find_library() to locate the library at runtime.

The ctypes.util.find_library() is very system dependent. I think that it's not suitable for dynamic loading of library with name known already.

So I coded like this;

import ctypes
import sys

if sys.platform == "linux":
    lib = ctypes.CDLL("libfswatch.so")
elif sys.platform == "darwin":
    lib = ctypes.CDLL("libfswatch.dylib")
elif sys.platform == "cygwin":
    lib = ctypes.CDLL("cygfswatch-11.dll")
else:
    raise Exception("can't load fswatch library dynamically")

fsw_init_library = lib.fsw_init_library

(I've tested this in Ubuntu Linux and M1 macos and not in cygwin)

Would you fix this problem?

Thank you.

@nayyarv
Copy link

nayyarv commented Jun 9, 2023

Thanks @terzeron it fixed the issue for me (also on a silicon mac).

nayyarv pushed a commit to nayyarv/pyfswatch that referenced this issue Jun 9, 2023
@pengw0048
Copy link

pengw0048 commented Jul 6, 2023

I think it has to do with the version of python the user runs. By default, find_library() won't be able to find the brew version of fswatch.

However, the brew version of python has an additional search path injected on top of this line in the canonical cpython to make it search under /opt/homebrew/lib. It happens here.

@nayyarv's fix won't work for cases where the libs aren't on the search path either. Homebrew/brew#13481 seems to suggest there's no generic way to make brew-installed libraries globally available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants