Re: Code::Blocks and Magick++.h
Bob Friesenhahn <[email protected]> Sun, 14 Apr 2013 11:54:41 -0500 (CDT)
| Newsgroups | gmane.comp.video.graphicsmagick.apis |
|---|---|
| Message-ID | <[email protected]> |
On Sun, 14 Apr 2013, Herbert Elwood Gilliland III wrote: > M:\DEV\Empire - Codeblocks\Empire In The Sky\ImageLoaders.cpp|14|error: request for member 'read' in 'magick', > which is of non-class type 'Magick::Image() It seems that Magick::Image magick(); should be Magick::Image image; since otherwise it is just a prototype declaration. I strongly recommend structuring code using Magick++ as described in the Magick::Exception documentation: http://www.graphicsmagick.org/Magick++/Exception.html Careful structuring of the code helps quite a lot with diagnosing issues when something goes wrong. > This is not GraphicsMagick, it is ImageMagick, which is why those methods may not be found. Where can i get > prebuilt mingw-compatible binaries for graphicsmagick? A few weeks ago I compared the headers and .cpp files provided by ImageMagick's variant of Magick++ and found them to be remarkably similar. Compile-time interoperability must be high. There is no prebuilt MinGW binaries for GraphicsMagick but (given a properly working MinGW/MSYS installation) it is trivially easy to configure and compile GraphicsMagick for MinGW using the procedure described at http://www.graphicsmagick.org/INSTALL-unix.html#building-under-mingw-msys I recommend reading the whole page since most of the "Unix" instructions also apply for the MinGW build. The key thing to make sure of if you use --enable-shared for a DLL build, is that the exception throw/catch test passes when you do 'make check'. If it fails, then there is a bug in the compiler. For some reason, catching C++ exceptions thrown from a DLL is difficult for MinGW compiler developers to get right. There is no such problem if you build the Magick++ library as a static library. Building GraphicsMagick/Magick++ yourself assures interoperability and allows you to choose how it is built. Unless you install a 32/64-bit version of Windows Ghostscript matching your 32/64-bit build of GraphicsMagick you can expect any tests depending on Ghostscript (e.g. PDF) to fail. The MinGW build of GraphicsMagick is quite API and functionally similar to the Visual Studio build (e.g. decorated with dllimport/dllexport) except that it requires libtool if you request building using modules and the delegates.mgk file is not as well tuned for Windows (you can use the one from "VisualMagick\bin\delegates.mgk" which is better adjusted for Windows). Bob -- Bob Friesenhahn [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Graphicsmagick-apis mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/graphicsmagick-apis