load_library cannot find libary even though lib path listed in error exists

[airyclam]

Context

• I have ImageMagick installed on my M1 system using Homebrew.
• I have Wand 0.6.11 installed in a Conda virtual environment with Python 3.11.5

Issue

When I run from wand.image import Image, I receive error

File "/Users/<User>/opt/anaconda3/envs/<envname>/lib/python3.11/site-packages/wand/api.py", line 154, in <module>
    libraries = load_library()
                ^^^^^^^^^^^^^^
  File "/Users/<User>/opt/anaconda3/envs/<envname>/lib/python3.11/site-packages/wand/api.py", line 143, in load_library
    raise IOError('cannot find library; tried paths: ' + repr(tried_paths))
OSError: cannot find library; tried paths: ['/opt/homebrew/lib/libMagickWand.dylib', '/opt/homebrew/lib/libMagickWandHDRI.dylib', '/opt/homebrew/lib/libMagickWandHDRI-2.dylib', '/opt/homebrew/lib/libMagickWand-7.dylib', '/opt/homebrew/lib/libMagickWand-7HDRI.dylib', '/opt/homebrew/lib/libMagickWand-7HDRI-2.dylib', '/opt/homebrew/lib/libMagickWand-7.Q8.dylib', '/opt/homebrew/lib/libMagickWand-7.Q8HDRI.dylib', '/opt/homebrew/lib/libMagickWand-7.Q8HDRI-2.dylib', '/opt/homebrew/lib/libMagickWand-7.Q16.dylib', '/opt/homebrew/lib/libMagickWand-7.Q16HDRI.dylib', '/opt/homebrew/lib/libMagickWand-7.Q16HDRI-2.dylib', '/opt/homebrew/lib/libMagickWand-6.dylib', '/opt/homebrew/lib/libMagickWand-6HDRI.dylib', '/opt/homebrew/lib/libMagickWand-6HDRI-2.dylib', '/opt/homebrew/lib/libMagickWand-Q16.dylib', '/opt/homebrew/lib/libMagickWand-Q16HDRI.dylib', '/opt/homebrew/lib/libMagickWand-Q16HDRI-2.dylib', '/opt/homebrew/lib/libMagickWand-Q8.dylib', '/opt/homebrew/lib/libMagickWand-Q8HDRI.dylib', '/opt/homebrew/lib/libMagickWand-Q8HDRI-2.dylib', '/opt/homebrew/lib/libMagickWand-6.Q16.dylib', '/opt/homebrew/lib/libMagickWand-6.Q16HDRI.dylib', '/opt/homebrew/lib/libMagickWand-6.Q16HDRI-2.dylib']

However when I look at my libraries installed, I do have one of the libraries in the paths tried, specifically libMagickWand-7.Q16HDRI.dylib

ls /opt/homebrew/lib/

libMagick++-7.Q16HDRI.5.dylib		
libMagick++-7.Q16HDRI.a			
libMagick++-7.Q16HDRI.dylib		
libMagick++-7.Q16HDRI.la		
libMagickCore-7.Q16HDRI.10.dylib	
libMagickCore-7.Q16HDRI.a		
libMagickCore-7.Q16HDRI.dylib		
libMagickCore-7.Q16HDRI.la		
libMagickWand-7.Q16HDRI.10.dylib	
libMagickWand-7.Q16HDRI.a		
libMagickWand-7.Q16HDRI.dylib		
libMagickWand-7.Q16HDRI.la	

Wondering if there's something wrong with my setup or if anyone has debugging tips?

[Lilneo786]

Check that your LD_LIBRARY_PATH environment variable includes the path to the directory where the libMagickWand library is located. You can set it temporarily for your session using the following command: export LD_LIBRARY_PATH=/opt/homebrew/lib:$LD_LIBRARY_PATH

After setting the LD_LIBRARY_PATH, try importing Image again.

if not try:

Reinstall or Update Wand:

pip uninstall Wand
pip install Wand

Can also try to configure the library path config:

import os
os.environ['MAGICK_HOME'] = '/opt/homebrew'  # Set the path to your ImageMagick installation

OR:

Debug Wand Installation:

from wand import version
from wand.api import library
print("Wand Version:", version())
print("Wand Library Path:", library)

[airyclam]

I already have MAGICK_HOME env variable set as /opt/homebrew, you can tell because the error message has the correct file paths /opt/homebrew/lib/libMagickWand.dylib etc...

importing library won't work because api.py is called at initialization...

setting LD_LIBRARY_PATH and reinstalling wand didn't help.

[emcconville]

Folks have previously reported issues with M1 when mixing native & x86_64 libraries. Try running the following in the Conda's virtual environment.

>>>  import ctypes
>>>  ctypes.CDLL('/opt/homebrew/lib/libMagickWand-7.Q16HDRI.dylib')

If an OSError exception is thrown, then M1 arch would be the issue. Best suggestion would be to use containers like Docker, or Podman.

Else if the CDLL object is returned, then it's just a matter of ensuring MAGICK_HOME or LD_LIBRARY_PATH is defined in the virtual environment.

[airyclam]

I see, it does seem like an OS issue. Thanks for the help- will try Docker.

[airyclam]

I noticed that we catch both IO and OS errors here and raise an IO at the end of searching through all the paths- would it be beneficial to have different logic for OSError to at least keep the error message for debugging? The only concern would be if there's multiple incompatible OS installations and one compatible one, we would get noisy error messages.

[airyclam]

Nevermind, realized that there's no good way to differentiate between file not found and file incompatible errors besides parsing the error message.