[xsd-users] Issue with using xsd generated code in DLLs with Visual Studio 2010

[Timo Geusch]

Hi Boris,

> -----Original Message-----
> From: Boris Kolpackov [mailto:boris at codesynthesis.com]
> Sent: Tuesday, September 21, 2010 7:07 AM
> To: Timo Geusch
> Cc: xsd-users at codesynthesis.com; Thomas Witt
> Subject: Re: [xsd-users] Issue with using xsd generated code in DLLs
> with Visual Studio 2010
> 
> Hi Timo,
> 
> Timo Geusch <timo.geusch at styleadvisor.com> writes:
> 
> > I've just tried this with a subset of the DLLs in the project.
> > Unfortunately the suggested workaround still results in the same
> > problem - the "root" DLL still exports symbols that are part of
> > the std namespace - say, std::basic_string<char>::front() that
> > subsequently clashes with the same symbol in one of the 'leaf'
> > DLLs
> 
> Are the clashing symbols in the leaf DLL also exported?

It doesn't get that far - the link stage of the build aborts before it completes due to the duplicate symbols that are both exported by the root DLL and present in the leaf DLL's object files.

I have a very minimal test project here that consists of two DLLs, a root DLL and a leaf DLL. The leaf DLL needs to link with the import library of the root DLL; If the root DLL contains an exported class that derives from std::string _and_ the leaf DLL makes use of std::string, the link stage for the leaf DLL will fail due to the root DLL exporting the symbols for std::string which have also been instantiated in the leaf DLL's object files. So this is not a problem specific to libxsd but rather a general issue.

> My understanding of how all this can work is as follows:
> 
> 1. In the root DLL the XML Schema types are exported which
>    triggers instantiation and exporting of types that they
>    derive from, e.g., std::basic_string<char>.
> 
> 2. The leaf DLL includes the XML Schema types from the root
>    DLL but now they are imported. The base classes are
>    imported as well so the leaf DLL uses them from the root
>    DLL instead of instantiating its own.
> 
> The only tricky part here is that this may rely on the XML Schema
> types being included into every C++ file in the leaf DLL. If
> there is a C++ file that doesn't know anything about XML Schema
> types (and as a result, that std::basic_string is imported),
> then it can instantiate the class which can lead to the symbol
> clash.

Not quite. The DLLs we're talking about here make quite extensive use of the standard C++ library classes, including those that Microsoft changed. So, say the root DLL is built and exports these symbols (that are now not part of the C++ runtime lib/dll anymore like they were in VS2008, but are now header-only). Then you build one of the leaf DLLs which also uses, say, std::basic_string in its various incarnations. As we're talking header only here, the leaf dll also creates instantiations of these symbols in the object files. When you then try to link the leaf DLL you'll end up in the unfortunate situation that the linker sees a conflict between the symbols present in the object files that it is attempting to link and the root DLL it is also attempting to link to.

The VS2010 linker is not able to resolve this conflict and as a result, none of the leaf DLLs link, even though they compile.

> > because in the default build settings, the affected C++ classes
> > are header-only.
> 
> Which classes are referring to? I am not sure I follow you here.

std::basic_string and its permutations, from memory some of the stream classes are also affected. The link I included in my original email should contain links to a few additional bug reports that give at least a partial view of which classes are affected. In our case it's mainly std::basic_string/std::string.

With best regards,
Timo