search

conda-forge / pyvips-feedstock

A conda-smithy repository for pyvips.
BSD 3-Clause "New" or "Revised" License
0 stars 4 forks source link

WIP: Try to build wit han older version of libvips #14

Closed hmaarrfk closed 2 years ago

hmaarrfk commented 2 years ago

Rebuilding: https://github.com/conda-forge/pyvips-feedstock/pull/12#issuecomment-975486957

Checklist

conda-forge-linter commented 2 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

hmaarrfk commented 2 years ago

@kleisauke I'm not sure what is wrong with 8.10. It builds, but segfaults.

I loosened the pinnings on the run export https://github.com/conda-forge/libvips-feedstock/pull/48

We should probably patch up older builds that depend on libvips to use the loosened exports.

kleisauke commented 2 years ago

It looks like it segfaults while importing pyvips. A GDB backtrace would be helpful, or maybe setting-up logging would help, for example this is what I see locally on a non-Conda environment (when installing pyvips against libvips 8.12, and then downgrading libvips to 8.10):

$ python3 -c "import logging;logging.basicConfig(level=logging.DEBUG);import pyvips"
DEBUG:pyvips:Loaded binary module _libvips
DEBUG:pyvips:Module generated for libvips 8.12
DEBUG:pyvips:Linked to libvips 8.12
DEBUG:pyvips:Inited libvips
# After downgrading libvips to 8.10
$ python3 -c "import logging;logging.basicConfig(level=logging.DEBUG);import pyvips"
DEBUG:pyvips:Loaded binary module _libvips
DEBUG:pyvips:Module generated for libvips 8.12
DEBUG:pyvips:Linked to libvips 8.10
DEBUG:pyvips:Binary module load failed: bad wrapper version
DEBUG:pyvips:Falling back to ABI mode
DEBUG:pyvips:Loaded lib <cffi.api._make_ffi_library.<locals>.FFILibrary object at 0x7fadbfe91cf8>
DEBUG:pyvips:Loaded lib <cffi.api._make_ffi_library.<locals>.FFILibrary object at 0x7fadc0c39ef0>
DEBUG:pyvips:Inited libvips

Perhaps the fall-back to ABI mode doesn't work on Conda? If so, then the libvips versions should indeed match during compile-time and run-time for API mode. We sanity-check this here: https://github.com/libvips/pyvips/blob/caceec98fa7f63ae6bc7bcb991c2ec946b16554a/pyvips/__init__.py#L39-L40

kleisauke commented 2 years ago

It seems that it fails to load the ImageMagick dependency with libvips 8.10.

DEBUG:pyvips:Binary module load failed: libMagickCore-7.Q16HDRI.so.9: cannot open shared object file: No such file or directory
DEBUG:pyvips:Falling back to ABI mode
...
Segmentation fault
kleisauke commented 2 years ago

Although I'm not sure why it segfaults when that occurs. For example, when I test this locally:

$ ldd /usr/lib64/libvips.so.42 | grep Magick
        libMagickCore-6.Q16.so.7 => /lib64/libMagickCore-6.Q16.so.7 (0x00007f020c156000)
$ mv /lib64/libMagickCore-6.Q16.so.7 /lib64/libMagickCore-6.Q16.so.7.old
$ python3 -c "import logging;logging.basicConfig(level=logging.DEBUG);import pyvips"
DEBUG:pyvips:Binary module load failed: libMagickCore-6.Q16.so.7: cannot open shared object file: No such file or directory
DEBUG:pyvips:Falling back to ABI mode
Traceback (most recent call last):
  File "/usr/local/lib64/python3.6/site-packages/pyvips/__init__.py", line 19, in <module>
    import _libvips
ImportError: libMagickCore-6.Q16.so.7: cannot open shared object file: No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib64/python3.6/site-packages/pyvips/__init__.py", line 71, in <module>
    vips_lib = ffi.dlopen(_vips_libname)
  File "/usr/lib64/python3.6/site-packages/cffi/api.py", line 141, in dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)
  File "/usr/lib64/python3.6/site-packages/cffi/api.py", line 802, in _make_ffi_library
    backendlib = _load_backend_lib(backend, libname, flags)
  File "/usr/lib64/python3.6/site-packages/cffi/api.py", line 797, in _load_backend_lib
    raise OSError(msg)
OSError: cannot load library 'libvips.so.42': libMagickCore-6.Q16.so.7: cannot open shared object file: No such file or directory.  Additionally, ctypes.util.find_library() did not manage to locate a library called 'libvips.so.42'
$ mv /lib64/libMagickCore-6.Q16.so.7.old /lib64/libMagickCore-6.Q16.so.7
hmaarrfk commented 2 years ago

It might be that there is an issue with the package imagemagick. There used to be some undefined dependencies a year back, on glib

https://github.com/conda-forge/imagemagick-feedstock/issues/146

Though I'm not too sure. I'm going to try to rebuild this with the loosened libvips pinning.

hmaarrfk commented 2 years ago

I'm going to close this since it isn't something I'm too keen on debugging. Thank you or chiming in. I think we were able to improve the recipe for libvips with your knowledge.

There might be issues with imagemagick :/

kleisauke commented 2 years ago

No problem, I'm glad I could help.