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