gographics / imagick

Go binding to ImageMagick's MagickWand C API
https://godoc.org/github.com/gographics/imagick/imagick
Other
1.76k stars 183 forks source link

Header file error. #258

Closed Ucag closed 3 years ago

Ucag commented 3 years ago

I followed the README install process and this error occurred.

System info:

Window 10 x64
go version go1.15.5 windows/amd64
msys2 with mingw64

And installed ImageMagick version following README is

$ convert --version
Version: ImageMagick 7.0.10-11 Q16 x86_64 2021-05-20 https://imagemagick.org
Copyright: © 1999-2020 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP(4.5)
Delegates (built-in): bzlib cairo djvu fftw flif fontconfig freetype gslib gvc heic jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png ps raqm raw rsvg tiff webp wmf xml zlib

pkg-config is able to find ImageMagick, here is the output:

$ pkg-config --cflags --libs MagickWand
-fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -D_DLL -D_MT -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -D_DLL -D_MT -ID:/msys64/mingw64/include/ImageMagick-7 -LD:/msys64/mingw64/lib -lMagickWand-7.Q16HDRI -lMagickCore-7.Q16HDRI

and build for v3 succeeded, no error reported.

however, when get the library, this error represented:

$ go get gopkg.in/gographics/imagick.v2/imagick
go: found gopkg.in/gographics/imagick.v2/imagick in gopkg.in/gographics/imagick.v2 v2.6.0
# gopkg.in/gographics/imagick.v2/imagick
..\..\go\pkg\mod\gopkg.in\gographics\imagick.v2@v2.6.0\imagick\affine_matrix.go:8:10: fatal error: wand/MagickWand.h: No such file or directory
    8 | #include <wand/MagickWand.h>
      |          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

After look at the header file in the include directory, I found that, the header file path is MagickWand/MagickWand.h instead of wand/MagickWand.h . How can I solve this problem?

justinfx commented 3 years ago

I'm not sure I follow your logic. You said you successfully built for v3, using ImageMagick7. That sounds great and is what I would expect. But then you said you tried to install v2, which is for ImageMagick6, and ran into header issues. If you installed ImageMagick7 then use v3 of this binding:

go get gopkg.in/gographics/imagick.v3/imagick

Why are you surprised to see header issues if you are using a mismatched binding version? Did you also install ImageMagick6 somewhere?

Ucag commented 3 years ago

I'm not sure I follow your logic. You said you successfully built for v3, using ImageMagick7. That sounds great and is what I would expect. But then you said you tried to install v2, which is for ImageMagick6, and ran into header issues. If you installed ImageMagick7 then use v3 of this binding:

go get gopkg.in/gographics/imagick.v3/imagick

Why are you surprised to see header issues if you are using a mismatched binding version? Did you also install ImageMagick6 somewhere?

Actually, I'm following the README process. In README, it did build v3 but install v2, I think there might be some backward support? And in the pacman instruction, no specific ImageMagick version is required or the latest version is for the default.

Of course, if you build v3 then you can successfully install v3. However, the API is different which will also result in error when run example in README even after my trying to fix the error. I'll present the error later.

Ucag commented 3 years ago

Here is the error when build v3 and install v3.

code

package main

import (
    "gopkg.in/gographics/imagick.v3/imagick"
)

func main() {
    imagick.Initialize()
    defer imagick.Terminate()

    imagick.NewMagickWand()
}

error

# command-line-arguments
D:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\Users\ucag\AppData\Local\Temp\go-link-213484371\000048.o: in function `_cgo_a387bb336bd8_C2func_fdopen':
/cygdrive/d/Users/ucag/AppData/Local/Temp/go-build202000962/b001/cgo-gcc-prolog:55: undefined reference to `__errno'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: /cygdrive/d/Users/ucag/AppData/Local/Temp/go-build202000962/b001/cgo-gcc-prolog:57: undefined reference to `__errno'
collect2.exe: error: ld returned 1 exit status
justinfx commented 3 years ago

Actually, I'm following the README process. In README, it did build v3 but install v2, I think there might be some backward support? And in the pacman instruction, no specific ImageMagick version is required or the latest version is for the default.

I think what happened is you combined the information from the "Windows" section with the "Common" section as related steps. In the Windows section it does mention ImageMagic7, but in the "Common" section it refers to installing v2. Really you just need to go with the top level information about v2 needing IM6 and v3 needing IM7. The are not compatible in terms of linking against ImageMagick, but there are possible similarities in the actual Go binding code which may let you compile as long as you don't use something that changed in v3.

Here is the error when build v3 and install v3.

Hmm, at first you said it succeeded in building v3 with ImageMagick7. But now that you say it is failing, I am not entirely sure how to fix it, since I don't do any compiling on Windows machines. The Windows build support was contributed by other Windows users so I just hoped it would continue working. Does this seem similar? https://github.com/golang/go/issues/37553 They suggest a badly cached cgo file and maybe doing go clean -cache? Otherrwise it could be an issue with your mingw gcc version?

Ucag commented 3 years ago

Thanks, it works!

But there are some differences when I rebuild the lib. It takes more time to build the whole library that compilation speed is much slower than my first build. I think it might because of the wrong matching version of ImageMagic dll but cgo is not able to find out the error at compilation time until we call go run which would really call the dll lib.

The reason why I need it on window is that my client needs to run a local server on their machine for internal usage and it is almost impossible to ask them to configure Docker.

And I think the README instruction can be improved for windows users. I can offer a pr if needed.

Anyway, thanks for your contribute and patient reply.

justinfx commented 3 years ago

I would recommend not using go run. That is for quick tests with single files. Use go build to ensure you take advantage of caching. It should be slower the first time it needs to build and cache the ImageMagick code. But should be faster after that.

Feel free to submit changes to improve the windows docs. Thanks!