[xsd-users] XSD & Windows DLL linkage issues with std::string

[Boris Kolpackov]

Nicolas Weidmann <n.weidmann at lombardodier.com> writes:

> I can create my DLL and test it without any issues.
>
> However as soon as I use my data-binding in another library that is also to
> be generated as a DLL, I get link errors regarding std::string:
> 
> data-binding.lib(data-binding.dll) : error LNK2005: "public: __cdecl std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<cha
> r> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QEAA at AEBV01@@Z) already defined in ClassUsingTheDataBinding.obj [LibraryUsingTheDatabinding.vcxproj]

Ok, let me describe the problem so that you have an idea about what's
going on here (this is the typical setup, yours is a variant with two
DLLs, but it's the same underlying problem):

1. XSD built-in types (e.g., xml_schema::string) derive from std::string
   (this is done so that you can "seamlessly" pass xml_schema::string
   where std::string is expected).

2. In VC++, when you export a class (xml_schema::string in our case,
   caused by the --export-xml-schema option), it automatically exports
   the base class. So in our case std::string (aka std::basic_string)
   gets exported as well. There doesn't seem to be any way to disable
   exporting of or "unexport" a base class in VC++.

3. When you build your executable, there could be some source files that
   include "xml-schema.hxx" (generated with --generate-xml-schema) and
   therefore "see" std::string as imported from the DLL. There could also be
   source files that do no include any generated code and therefore don't
   "see" std::string as imported but rather as defined in the
   executables. When you then try to link object files corresponding to such
   source files together, you get the multiple definition error (one is
   imported from the DLL while the other is locally defined).

The easiest solution is, well, not to package generated source code into
DLLs, if you are able to.

The next easiest solution is to address #3 by making sure that every
source file in the executable that includes <string> also includes
"xml-schema.hxx" so that they also "see" std::string as imported. This
is not a very clean but fairly easy fix.

The cleaner but more involved fix would be to address #1 and not
derive from std::string. This can be done with type customization
but it will also limit the xml_schema::string functionality (no
implicit substitution for std::string). If you would like to go
down this route, see:

http://wiki.codesynthesis.com/Tree/Customization_guide

And, specifically, the "Customizing the XML Schema built-in types"
section:

http://wiki.codesynthesis.com/Tree/Customization_guide#Customizing_the_XML_Schema_built-in_types