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 (#xulrunner on 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.
msvcr80.dllmsvcp80.dllmsvcm80.dllMicrosoft.VC80.CRT.manifest
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)?
Comments (3)
Yeah, the CRT linkage is a mess. You can go have a look at bug 415928 for my most recent battles with it. Odds are you need to do something similar to get these libs to link properly. It is, in fact, a giant pain.
— Ted Mielczarek — 2008/02/14 6:02 am
I ran into a similar problem when trying to create a binary mozilla component that has other (non-mozilla) library dependencies.
I was stuck on this until I ran across your article here, which helped me to get a workaround solution (though I admit that I still do not understand it all).
I followed your method above (thanks for blogging it), but I found that I only had to include the "Microsoft.VC80.CRT.manifest" file itself, and did not require the actual msvc*.dll files at all. My extension component then works in Firefox/XulRunner on clean installs of Windows 2000 and XP, without the need to install the VC redistributable files.
This may work for your case as well...
— Todd Whiteman — 2008/02/25 10:50 am
Struggling with this one here.. I tool may just be overly dense.. you decide.
Situation: Using VS2008 creating a managed C++ DLL to be deployed to Vista environment that won't have the VS2008 runtime installed.
I set the manifest name in Project Properties » Manifest Tool » Input and Output » Embed Manifest (I assume I specify the file name in Project Properties » Manifest Tool » Input and Output » Additional Manifest Files). I left the options in Project Properties » Linker » Manifest File alone.
But when I build my DLL, and check the dependencies, it's still showing the "Microsoft.VC90.DebugCRT" as a dependent assembly in the build-generated manifest.
I'm all confused now...
— Tony B. — 2008/04/29 6:09 pm