Building Magick++ under Windows

Dooglus added support for Magick++ back in October of 2007. … -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/ -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/ wand/
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” … =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 -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/ -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/
*** 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/ .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
(cd .libs && rm -f && ln -s …/

and no libmod_magick.dll.a :frowning:

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 file need updating with mod_magickpp.nsh entries also. Otherwise the resulting windows installer won’t include magickpp as a target.


We should find some other methods when building the code on windows.