Building ImageMagick DLLs with static runtime

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
Post Reply
Smolingol
Posts: 4
Joined: 2011-03-30T13:35:15-07:00
Authentication code: 8675308

Building ImageMagick DLLs with static runtime

Post by Smolingol »

I wanted to link ImageMagick statically with the CRT while still producing DLLs for ImageMagick. I don't want to ship msvcr80.dll and I also don't want to statically link with IM. It turns out this is not an option in configure. I haven't completely gotten it to work this way, below are the steps I took and as far as I got.

Note: I've edited this post and my replies to this thread for clarity and to consolidate the progress I made, and where I gave up. Also, I'm sorry I put this in the wrong forum -- it should have gone in the Developers forum, not the Users forum.

First, I used configure to create a DLL that dynamically links with the runtime. This is the default option.

Next, I changed each project to use /MT and /MTd instead of /MD and /MDd. This resulted in all sorts of linker errors, because IM has a bunch of #ifdefs dependent on _DLL, and IM explicitly includes _DLL in the project preprocessor defines (even though it is implied by /MD, it is not implied by /MT).

Most of those #ifdefs can also be attained with _MAGICKDLL_ for the main projects and the likes of _JPEGDLL_ etc for coders. So I removed _DLL from each project and replaced it with the corresponding token.

This will allow you to compile and link, but it won't try to load modules. This is because MAGICKCORE_MODULES_SUPPORT is dependent on _DLL being idefined. Simply defining MAGICKCORE_MODULES_SUPPORT will get IM to try to load modules.

However, you may need to do some initialization that you didn't have to do before all of this, because DllMain is dependent on both ProvideDllMain and _DLL being defined. If you were reliant on DllMain to do MagickCoreGenesis/MagickCoreTerminus and/or set up paths for modules, you must now do that yourself.

At this point everything compiles and links, and IM is able to find modules and load modules in its path. However, when it tries to decode an image, after loading the module it finds that the coder is not in its module list, and results in a missing delegate error. This I have not figured out -- stepping through the code, everyhting looks good, but by the time it wants to decode an image, the list does not have the right coders in it.
Last edited by Smolingol on 2011-03-31T22:29:23-07:00, edited 4 times in total.
Smolingol
Posts: 4
Joined: 2011-03-30T13:35:15-07:00
Authentication code: 8675308

Re: Building ImageMagick DLLs with static runtime

Post by Smolingol »

(removed -- I consolidated posts to the top post for clarity)
Last edited by Smolingol on 2011-03-31T22:26:27-07:00, edited 2 times in total.
Smolingol
Posts: 4
Joined: 2011-03-30T13:35:15-07:00
Authentication code: 8675308

Re: Building ImageMagick DLLs with static runtime

Post by Smolingol »

(removed -- I consolidated posts to the top post for clarity)
Last edited by Smolingol on 2011-03-31T22:26:33-07:00, edited 2 times in total.
Smolingol
Posts: 4
Joined: 2011-03-30T13:35:15-07:00
Authentication code: 8675308

Re: Building ImageMagick DLLs with static runtime

Post by Smolingol »

(removed -- I consolidated posts to the top post for clarity)
Post Reply