Security News
Oracle Drags Its Feet in the JavaScript Trademark Dispute
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
github.com/gographics/imagick/v3
Go Imagick is a Go bind to ImageMagick's MagickWand C API.
We support two compatibility branches:
im-7 (tag v3.x.x): 7.0.8-41 <= ImageMagick <= 7.x
master (tag v2.x.x): 6.9.1-7 <= ImageMagick <= 6.9.9-35
legacy (tag v1.x.x): 6.7.x <= ImageMagick <= 6.8.9-10
They map, respectively, through gopkg.in:
gopkg.in/gographics/imagick.v3/imagick
gopkg.in/gographics/imagick.v2/imagick
gopkg.in/gographics/imagick.v1/imagick
See examples/docker
brew install imagemagick
sudo apt-get install libmagickwand-dev
Thanks @vprus
pacman -S mingw-w64-x86_64-imagemagick
pacman -S mingw-w64-x86_64-gcc
set PATH=C:/Temp/gcc/msys64/mingw64/bin;%PATH%
set PKG_CONFIG_PATH=C:/Temp/gcc/msys64/mingw64/lib/pkgconfig
go build gopkg.in/gographics/imagick.v2/imagick
Check if pkg-config is able to find the right ImageMagick include and libs:
pkg-config --cflags --libs MagickWand
Then go get it:
go get gopkg.in/gographics/imagick.v2/imagick
Per the security update https://groups.google.com/forum/#!topic/golang-announce/X7N1mvntnoU you may need whitelist the -Xpreprocessor flag in your environment.
export CGO_CFLAGS_ALLOW='-Xpreprocessor'
If you want to specify CGO_CFLAGS/CGO_LDFLAGS manually at build time, such as for building statically or without pkg-config, you can use the "no_pkgconfig" build tag:
go build -tags no_pkgconfig gopkg.in/gographics/imagick.v2/imagick
The examples folder is full with usage examples ported from C ones found in here: http://members.shaw.ca/el.supremo/MagickWand/
Since this is a CGO binding, and the Go GC does not manage memory allocated by the C API, it is then necessary to use the Terminate() and Destroy() methods. Objects of type MagickWand, DrawingWand, PixelIterator and PixelWand are managed by Go GC if you create them via constructors.
package main
import "gopkg.in/gographics/imagick.v2/imagick"
func main() {
imagick.Initialize()
defer imagick.Terminate()
mw := imagick.NewMagickWand()
...
}
If you use struct literals, you should free resources manually:
package main
import "github.com/gographics/imagick/imagick"
func main() {
imagick.Initialize()
defer imagick.Terminate()
mw := imagick.MagickWand{...}
defer mw.Destroy()
...
}
Both methods are compatible if constructor methods used:
package main
import "github.com/gographics/imagick/imagick"
func main() {
imagick.Initialize()
defer imagick.Terminate()
mw := imagick.NewMagickWand()
defer mw.Destroy()
...
}
But you should NOT mix two ways of object creation:
package main
import "github.com/gographics/imagick/imagick"
func main() {
imagick.Initialize()
defer imagick.Terminate()
mw1 := imagick.MagickWand{...}
defer mw1.Destroy()
mw2 := imagick.NewMagickWand()
...
}
Calling Destroy()
on types that are either created via New*
or returned from other functions calls forces the cleanup of the item immediately as opposed to later after garbage collection triggers the finalizer for the object. It would be good practice to explicitly call Destroy()
to ensure C memory is freed sooner rather than later, depending on how often the GC is triggered.
Copyright (c) 2013-2016, The GoGraphics Team All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL HERBERT G. FISCHER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
FAQs
Unknown package
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
Security News
The Linux Foundation is warning open source developers that compliance with global sanctions is mandatory, highlighting legal risks and restrictions on contributions.
Security News
Maven Central now validates Sigstore signatures, making it easier for developers to verify the provenance of Java packages.