[xsd-users] Problems linking Code which uses XSD in Release mode

[Jan Klimke]

I found out that the usage of the Qname Type causes the linker error.
When i am using a line like this:
xml_schema::Qname("coll:UriComment")
Outside the DLL which contains the generated code the mentioned linker
error occurs. When using these classes inside the library everything
works fine.

For not reproducing the xml_schema Type definitions i generated a
separate file for that using the follwing xsd options:

--generate-polymorphic
--root-element-all
--generate-serialization
--generate-inline
--generate-doxygen
--export-symbol WFS_API
--hxx-suffix .h
--cxx-suffix .cpp
--ixx-suffix .inl
--include-with-brackets
--include-prefix wfs/
--hxx-prologue-file ../headerprologue.txt
--type-naming java
--function-naming java
--generate-forward
--generate-xml-schema xml_schema.xsd

Is it possible that those Types are not exported in certain cases or the
code is optimized away when linking in release mode !?


Jan

Jan Klimke schrieb:
> Hi Boris,
>
> here are some information about my solution setup.
>
> I put all files generated by the xsd compiler into a separate DLL-project.
> Another DLL should use the library. When linking this library in release
> mode the error occurs. An example project is a bit hard to create due to
> the dependencies of the libraries. So you won't be able to compile the
> whole project. Is it sufficient to send it  to you like this ?
>
> Despite of that i am wondering why linking works when building in debug
> mode.
>
> Jan
>
> Boris Kolpackov schrieb:
>   
>> Hi Jan,
>>
>> Jan Klimke <jan.klimke at hpi.uni-potsdam.de> writes:
>>
>>   
>>     
>>> i got a pretty strange problem when linking my classes which are using
>>> the generated code. When i link in Debug mode everything is working
>>> fine, but when i switch to release mode xsd related errors occur. An
>>> example for such an error can be found afterwards. It seems that some
>>> string related functions can not be found. does anybody have a hint for
>>> me solving this issue ?
>>>     
>>>       
>> The two errors you showed involve destructors. The interesting
>> thing is that the first (~ncname) is implicit (i.e., it is
>> generated by the C++ compiler). I also see __declspec which 
>> tells me DLLs are probably involved. Another interesting thing
>> is that ncname and id class templates don't have __declspec
>> specifiers so I am not sure why they appear in the symbols.
>>
>> Can you describe your setup in a bit more detail? Things like
>> where is the generated code residing (DLL vs executable) and
>> when do you get link errors (e.g., when linking the executable 
>> or DLL). Also, if you could provide a test project that reproduces
>> this problem then I could take a look and see if I can find
>> what's going on. Feel free to send it to me directly if you
>> would like to keep your code private.
>>
>> Boris
>>   
>>     
>
>