Legacy ImageMagick Discussions Archive

Hi all

Can I ask firstly whether or not it is possible to use the binary installer versions of ImageMagick with the MinGW compiler? I would like to use ImageMagick for a small project I am working on, and I was hoping it would not be necessary for me to compile all the sources from scratch...

If I can not use those binaries, can anyone point me at a simple step-by-step on how to compile an equivalent set of DLLs for use on MinGW, including support for JPEG, TIFF, PNG?

Cheers
JP

Answer to the first question appears to be: No, you can't use the binary installer files with MinGW, because MinGW and Visual C++ use different C++ ABI, mangle symbol names differently, etc. So I understand that GCC can't (at least directly) make use of C++ routines embedded in DLLs generated by Visual C++. Ability to use Visual C++ DLLs depends on the absence of name mangling, in other words C-based DLLs.

To compile ImageMagick on MinGW it appears to be necessary to first build zlib, libjpeg, libpng, libtiff and possibly other dependencies. There is, AFAICT, no possibility of using the GnuWin32 pre-built binaries for each of these (although obviously this *should* be possible, I can't find any evidence of people having achieved that).

Are there any suggestions on the use of GnuWin32 versions of libpng etc to ease the task of compiling ImageMagick?

We downloaded the latest release of ImageMagick under the MSYS shell and ImageMagick compiled without complaint as follows:

• bunzip -c ImageMagick-6.3.7-2.tar.bz2 | tar xvf -
  cd ImageMagick-6.3.7
  ./configure --disable-shared
  make
  make -k -i install
  convert logo: logo.miff
  identify -verbose logo.miff

We tried compiling with --enable-shared but an internal compiler error exception was thrown.

My goal here was to build ImageMagick without having to build all the dependencies first. Hence: did you link against GnuWin32 when you did as you described?

Also, for maximum ease of reuse, DLLs are best. When I attempted to build the DLLs, I didn't get an internal compiler error, I got linker errors. What version of MinGW do you have?

We are using MinGW-5.1.3 and MSYS 1.0.10.

Did you link against GnuWin32 DLLs?

Our goal was simply to see if the virgin distribution of ImageMagick would compiled under MinGW/MSYS. It did so we bailed. If you would like us to try something specific, just post the instructions here and we will try to reproduce any problems you are having.

I have described a build process for MinGW at the following url:
http://ascendwiki.cheme.cmu.edu/Buildin ... k_on_MinGW

The goal is to produce DLLs and EXEs for IM that don't required one to first compile all the dependencies, ie to use the GnuWin32 binaries instead.

My experience of this was that IM failed to build DLLs (with a linker error), but if there is a way to build DLLs, I'd be very pleased to hear.

Cheers
JP

We have not tried your method yet, but we have a method that works well. In the MSYS shell, we moved to the ImageMagick-6.3.7 folder and downloaded and unpacked the JPEG delegate library. We renamed it ImageMagick-6.3.7/jpeg and typed these commands in the jpeg folder:

• ./configure --disable-shared
  make

Next we moved to the ImageMagick-6.3.7 folder and typed these commands:

• ./configure --enable-delegate-build --disable-shared
  make
  make -k -i install
  convert logo: logo.jpg
  identify -verbose logo.jpg

ImageMagick created and identified the JPEG image as expected. If you want PNG support, download the distribution, unpack, and rename it ImageMagikc-6.3.7/png. Next build it and rerun the ImageMagick configure script and rebuild ImageMagick. You now have PNG support. Do the same for each of the libraries you require.

Presumably the above will work if you do not use the --disable-shared option to build dynamic shared libraries but as mentioned that causes an internal compiler exception for us.

Hi again,

Can you expand on what the barriers are that prevent successful building of IM DLLs would be on MinGW?

Cheers
JP

We're running into two barriers. Given the same MinGW/MSYS distribution on a Windows XP laptop and a desktop-- on the laptop we get an internal compiler error when we build with --enable-shared and on the desktop we get undefined references to the Freetype library even though -lfreetype is on the link line. The first problem suggests a bug in the gcc compiler. The second problem suggests a fault with the automake/autoconf scripts under MinGW/MSYS since these same scripts work fine for us under Linux/Solaris/Cygwin/Mac OS X/etc.. As mentioned, when we build a static version of ImageMagick, it works for us on both the laptop and desktop.

Thanks to your advice we found the problem. The problem was a dllimport bug but only for the Wand library. We set dllexport properly for the Magick library. We will have a patch in ImageMagick 6.3.7-3 Beta sometime tomorrow and you will be able to build a shared version of ImageMagick under MinGW/MSYS.