Legacy ImageMagick Discussions Archive

I'm trying to build a new Win32 version of RMagick using the latest Windows binary ImageMagick-6.4.8-6-Q8-windows-dll.exe. When I test using the new RMagick, the test fails with a number of "An application has made an attempt to load the C runtime library incorrectly" messages, and then " no decode delegate for this image format `images/Flower_Hat.jpg' @ constitute.c/ReadImage/526".

The convert command converts this image just fine, so I'm certain that the problem lies with the way that RMagick is built. However, I'm using the same version of Ruby and the same process and tools that I used for 6.4.5-3. I'm using Visual Studio 2005 (Visual C++ 2005 Express Edition).

Is it possible that the 6.4.8-6 binary was built using a different compiler that is incompatible with the one I'm using?

Any other suggestions?

The latest ImageMagick release is built with Visual Studio 2008 to support OpenMP. Can you try the 2008 express compiler? Its beneficial to the RMagick user since ImageMagick will run almost twice as fast on a dual-core system and three times as fast on a quad-core system. However, if you want to stick with 2005 we can build a release to your specifications. The previous release was built with 2003 which does not support OpenMP. We have the Visual 2005 compiler but we have the standard release which does not support OpenMP.

I'll try it. I also have to be compatible with the pre-built Ruby 1.8.6. I don't know what my constraint will be there. I'll ask on the Ruby Forum. I could also use the most recent IM binary that was built with the older compiler.

Thanks.

The Ruby folks have suggested an alternative using MinGW and MSYS, so I'll investigate that. Thanks for your offer to build a version to my spec. I really don't want to burden you with requests like that, but I'll hold on to your offer in case the MinGW approach fails.

Okay, I built RMagick with Visual C++ 2008 Express Edition and it seems to be playing well with ImageMagick 6.4.8-6 and (knock wood) with Ruby, too. This gives me some breathing room to work on the MinGW/MSYS approach.

Thanks for the tip!