Dooglus added support for Magick++ back in October of 2007.
dooglus.rincevent.net/synfig/log … -10-28.log
At that time, I wasn’t able to follow along with him. I’m now at the stage where I can build Synfig myself, but…
We have a problem enabling Magick++ under Windows. When building ImageMagick under msys, libMagick++.dll.a is not created.
/bin/sh ./libtool --silent --tag=CXX --mode=link g++ -g -O2 -Wall -W -version-info 1:0:0 -L/C/GTK/lib -Wl,–rpath -Wl,/C/GTK/lib -lfreetype -lz -o Magick++/lib/libMagick++.la -rpath /usr/local/lib Magick++/lib/Blob.lo Magick++/lib/BlobRef.lo Magick++/lib/CoderInfo.lo Magick++/lib/Color.lo Magick++/lib/Drawable.lo Magick++/lib/Exception.lo Magick++/lib/Functions.lo Magick++/lib/Geometry.lo Magick++/lib/Image.lo Magick++/lib/ImageRef.lo Magick++/lib/Montage.lo Magick++/lib/Options.lo Magick++/lib/Pixels.lo Magick++/lib/STL.lo Magick++/lib/Thread.lo Magick++/lib/TypeMetric.lo magick/libMagickCore.la wand/libMagickWand.la
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries
It seems that this is deliberately done as part of the ImageMagick configure scripts as they understand that there are “problems with C++ exceptions under MinGW with a shared library”
imagemagick.org/discourse-se … =1&t=11936
Linking in as part of libmodmagickpp generates the message -
c:/mingw/bin/…/lib/gcc/mingw32/3.4.5/…/…/…/…/include/c++/3.4.5/bits/basic_string.tcc:148: warning: ‘__r’ might be used uninitialized in this function
/bin/sh …/…/…/libtool --mode=link mingw32-g++ -DNDEBUG -O1 -W -Wall -LC:/GTK/lib -L/usr/local/lib -lole32 -no-undefined -Wl,–export-all-symbols -Wl,–subsystem=console -Wl,–enable-runtime-pseudo-reloc -o libmod_magickpp.la -rpath C:/PROGRA~1/Synfig/lib/synfig/modules -module -lMagick++ -no-undefined -avoid-version libmod_magickpp_la-main.lo libmod_magickpp_la-trgt_magickpp.lo…
…/…/synfig/libsynfig.la -Lc:/GTK/lib -lxml+±2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 -lintl -liconv -lkernel32 -luser32 -Lc:/GTK/lib -lsigc-2.0
*** Warning: This system can not link to static lib archive /usr/local/lib/libMagick++.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.
rm -fr .libs/libmod_magickpp.a .libs/libmod_magickpp.la .libs/libmod_magickpp.lai
ar cru .libs/libmod_magickpp.a .libs/libmod_magickpp_la-main.o .libs/libmod_magickpp_la-trgt_magickpp.o
ranlib .libs/libmod_magickpp.a
creating libmod_magickpp.la
(cd .libs && rm -f libmod_magickpp.la && ln -s …/libmod_magickpp.la libmod_magickpp.la)
and no libmod_magick.dll.a 
I’ve taken this as far as I think I can (further than I thought), and I’m writing this up in the hopes that it will help bootstrap someone else. I pass the baton on to someone else more experienced with shared libraries and/or building under msys.
Oh yes, and if you do figure out how to make it work, the synfig-core win32inst.nsi.in file need updating with mod_magickpp.nsh entries also. Otherwise the resulting windows installer won’t include magickpp as a target.
Chris