LoadError: Provider BinDeps.PackageManager failed to satisfy dependency libwand while building ImageMagick

[hpoit]

This is the continuation of #175, sorry, it should've been opened here in the first place. @bjarthur @staticfloat @timholy

[staticfloat]

EDIT: Moved this in from JuliaPackaging/Homebrew.jl#175

@hpoit Just FYI, you can use gist instead of google docs to share large pastes in a slightly more code-friendly format. :)

Are the two commas after the second Ptr supposed to be there? Not just (Ptr{UInt8}), "LIB_VERSION_NUMBER")?

Yes, the third argument to ccall() must be a tuple, so we use (Foo,) to create a 1-element tuple containing the type Foo instead of just the type Foo, which won't work. You can read more here.

I think I've managed to reproduce this locally. I'm looking into it real quick.

[staticfloat]

@bjarthur what happens if you run the following? I now can get a segfault reliably within MagickQueryConfigureOption:

const libwand = Libdl.dlopen(Pkg.dir("Homebrew", "deps/usr/lib/libMagickWand-6.Q16.dylib"))
genesis = Libdl.dlsym(libwand, :MagickWandGenesis)
ccall(genesis, Void, ())
println("Genesis complete")
mqco = Libdl.dlsym(libwand, :MagickQueryConfigureOption)
p = ccall(mqco, Ptr{UInt8}, (Ptr{UInt8},), "LIB_VERSION_NUMBER")
println(p)

[hpoit]

So MagickWand contains a list of images. p = ccall((:MagickQueryConfigureOption, libwand), Ptr{UInt8}, (Ptr{UInt8},), "LIB_VERSION_NUMBER") returns the configure options from query that match two references of LIB_VERSION_NUMBER of libwand, is that right Elliot?

[staticfloat]

I think MagickQueryConfigureOption allows the client (in this case, julia) to ask ("Query") libmagickwand what configuration options it has. In this case, we want to know what the version of the library is ("LIB_VERSION_NUMBER"). This should return a string, but instead it segfaults. I haven't gone so far as to build a debug version of libMagickWand with no optimization and debugging symbols embedded, but that would be the natural extension to try and figure out why it's segfaulting.

[hpoit]

If you search "ccall((:MagickQueryConfigureOption, libwand)" on Google, you will find a heck of a lot of related issues. I am trying to find a successful ccall from which to base on, or maybe just a call straight in C.

[hpoit]

I have absolutely no experience in debugging... But there's always a first time! What would optimizations and debug symbols look like? Which libMagickWand should we work on? I think we can learn from #7... Oh, you're in it! I'm going to read this short novel by tomorrow. Good night!

[hpoit]

I also want to understand what the two pointers are for in relation to the library version.

[bjarthur]

julia> const libwand = Libdl.dlopen(Pkg.dir("Homebrew", "deps/usr/lib/libMagickWand-6.Q16.dylib"))
Ptr{Void} @0x00007fe8fa4b1120

julia> genesis = Libdl.dlsym(libwand, :MagickWandGenesis)
Ptr{Void} @0x000000031cc3f098

julia> ccall(genesis, Void, ())

julia> println("Genesis complete")
Genesis complete

julia> mqco = Libdl.dlsym(libwand, :MagickQueryConfigureOption)
Ptr{Void} @0x000000031cc3e7dc

julia> p = ccall(mqco, Ptr{UInt8}, (Ptr{UInt8},), "LIB_VERSION_NUMBER")
Ptr{UInt8} @0x00007fe8f8bcd800

julia> println(p)
Ptr{UInt8} @0x00007fe8f8bcd800

[rsrock]

Joining the party over here...

julia> const libwand = Libdl.dlopen(Pkg.dir("Homebrew", "deps/usr/lib/libMagickWand-6.Q16.dylib"))
Ptr{Void} @0x00007ff2db866d20

julia> genesis = Libdl.dlsym(libwand, :MagickWandGenesis)
Ptr{Void} @0x0000000318748e2e

julia> ccall(genesis, Void, ())

julia> println("Genesis complete")
Genesis complete

julia> mqco = Libdl.dlsym(libwand, :MagickQueryConfigureOption)
Ptr{Void} @0x0000000318748572

julia> p = ccall(mqco, Ptr{UInt8}, (Ptr{UInt8},), "LIB_VERSION_NUMBER")

signal (11): Segmentation fault: 11
while loading no file, in expression starting on line 0
MagickQueryConfigureOption at /Users/rrock/.julia/v0.5/Homebrew/deps/usr/lib/libMagickWand-6.Q16.dylib (unknown line)
anonymous at ./<missing> (unknown line)
unknown function (ip: 0x1109ba1e1)
jl_call_method_internal at /Users/rrock/Documents/Code/julia/src/./julia_internal.h:189 [inlined]
jl_toplevel_eval_flex at /Users/rrock/Documents/Code/julia/src/toplevel.c:569
jl_toplevel_eval_in_warn at /Users/rrock/Documents/Code/julia/src/builtins.c:590
eval at ./boot.jl:234
jlcall_eval_19888 at /Users/rrock/Documents/Code/julia/usr/lib/julia/sys.dylib (unknown line)
jl_call_method_internal at /Users/rrock/Documents/Code/julia/src/./julia_internal.h:189 [inlined]
jl_apply_generic at /Users/rrock/Documents/Code/julia/src/gf.c:1945
eval_user_input at ./REPL.jl:64
unknown function (ip: 0x1109b4a36)
jl_call_method_internal at /Users/rrock/Documents/Code/julia/src/./julia_internal.h:189 [inlined]
jl_apply_generic at /Users/rrock/Documents/Code/julia/src/gf.c:1945
macro expansion at ./REPL.jl:95 [inlined]
#3 at ./event.jl:68
unknown function (ip: 0x110996daf)
jl_call_method_internal at /Users/rrock/Documents/Code/julia/src/./julia_internal.h:189 [inlined]
jl_apply_generic at /Users/rrock/Documents/Code/julia/src/gf.c:1945
jl_apply at /Users/rrock/Documents/Code/julia/src/./julia.h:1392 [inlined]
start_task at /Users/rrock/Documents/Code/julia/src/task.c:253
Allocations: 2977930 (Pool: 2976845; Big: 1085); GC: 3
[1]    12036 segmentation fault  julia

[hpoit]

@stevengj: The point is that if it (using Images) was fixed, even temporarily, on Alan's machine by a downgrade of Images.jl, that suggests to me that it may not be a configuration problem of ImageMagick but rather a bug in Images. Someone who can reproduce the problem should try to do a git bisect on Images.jl.

From JuliaImages/Images.jl#363, I'm saving it for later. Just gathering intel right now.

Thanks Ben, let me finish reading #7 and #363 and I'll come back to here. Ron hold on, let's fix this!!!! @SimonDanisch

[hpoit]

1. How do I check that these pointers are valid indices in the array that receives them?

2. Reported by @vchuravy init_deps not found when imagemagick is already installed on OSX #12: what other package depends on libwand that is correctly building on macOS, Linux, Windows? I would like to compare a build script that works with that of ImageMagick's.

julia> BinDeps.debug("ImageMagick")
INFO: Reading build script...
The package declares 1 dependencies.
 - Library "libwand"
    - Satisfied by:
      - System Paths at /usr/lib64/libMagickWand.so.2
    - Providers:
      - BinDeps.AptGet package libmagickwand4 (can't provide)
      - BinDeps.AptGet package libmagickwand5 (can't provide)
      - BinDeps.AptGet package libmagickwand-6.q16-2 (can't provide)
      - BinDeps.Pacman package imagemagick (can't provide)
      - BinDeps.Yum package ImageMagick

It's late, more tomorrow.

[timholy]

For those getting these crashes, do other functions work if you comment out any lines dealing with version information?

[hpoit]

They do for me, on macOS: https://gist.github.com/hpoit/7ba683a31e2fc056c1fd72943d1f8c25

[hpoit]

This might lead us somewhere. There might be undefined or missing references to libMagickWand.so.2, libMagick, libWand, and related libraries. I'm going to map them.

[hpoit]

Tim do you know why there is a major, minor, and micro version of MagickWand?

[hpoit]

Found what works for me. Pkg.build("ImageMagick") still doesn't work, but my Julia notebook does, so that's good enough for me. Thanks you all.

[timholy]

Let's keep this open, since obviously the current situation cost you a lot of wasted time and would be good to fix.

Tim do you know why there is a major, minor, and micro version of MagickWand?

That's semver numbering, presumably.

[hpoit]

You're right Tim, the issue hasn't been solved for this package. The solution to it is probably in the last link I posted of ImageMagick for macOS, or there's something wrong with Images, BinDeps, or even ccall.

…

On Feb 16, 2017, at 19:48, Tim Holy ***@***.***> wrote: Reopened #75. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[timholy]

Presumably closed by #90. Feel free to reopen or comment if not.