When you can't statically link, manifest 2008/01/14
Manifest (verb): To embed XML describing libraries which are expected to be available at runtime, done in the course of developing software using Microsoft Visual Studio.
The wisdom of the collective T-Rex (
irc.mozilla.org) says that statically linking against the Microsoft C Runtime (
msvcr80.dll and friends) is the way to go. However I've run into a case where I cannot do this (deciding whether this is due to technical limitations or lack of competence is for readers to help me decide).
The image processing component of the Flickr Uploadr links against GraphicsMagick and Exiv2, libraries that do image processing and EXIF/IPTC metadata processing, respectively. Without them, it doesn't fly. Problem is, they both link the C Runtime themselves by using
std::string and such. Both of these libraries will build fine given the
/MT flag, which instructs them to statically link the C Runtime. When they themselves are statically linked into the XPCOM component later, all hell breaks loose. It seems that the static linker can't resolve the duplicate definitions caused by overzealous static linking.
The solution, as it stands, is simply to include the C Runtime and its manifest in the distribution. Placing the following files in Uploadr's
components/ directory has allowed life to go on for the moment.
Lastly, make sure your XPCOM project in Visual Studio is set to embed its manifest from Project Properties » Manifest Tool » Input and Output » Embed Manifest.
A more optimal solution might be to combine the Visual Studio projects for GraphicsMagick (and therefore libjpeg, etc), Exiv2 and the XPCOM component into one large tree that Visual Studio might be able to better manage. Has anyone out there done such a thing with Microsoft's static linker (even if not with XULRunner)?