Hi all, Im trying to build Collada from svn in DEBUG DLL (in windows of course).
It seems that the dae project refers to libxml2 with the static library by default: libxml2_a.lib. I get the linking errors below due to that.
If I change to libxml2.lib (using the dynamic library for libxml2) it works fine.
Comments on that? Its fine for me to use the dll version of libxml2, but I guess the svn should build out of the box, right?
1>------ Build started: Project: dae, Configuration: Debug DLL Win32 ------
1>Linking…
1>LINK : …/…/bin/vc8_1.4_debug/libcolladadom13.dll not found or not built by the last incremental link; performing full link
1> Creating library …/…/lib/vc8_1.4_dll_debug/libcolladadom13.lib and object …/…/lib/vc8_1.4_dll_debug/libcolladadom13.exp
1>libxml2_a.lib(encoding.obj) : error LNK2019: unresolved external symbol _libiconv referenced in function _xmlIconvWrapper
1>libxml2_a.lib(encoding.obj) : error LNK2019: unresolved external symbol _libiconv_close referenced in function _xmlCharEncCloseFunc
1>libxml2_a.lib(encoding.obj) : error LNK2019: unresolved external symbol _libiconv_open referenced in function _xmlFindCharEncodingHandler
1>…/…/bin/vc8_1.4_debug/libcolladadom13.dll : fatal error LNK1120: 3 unresolved externals
Im using Collada together with OpenSceneGraph, and with the current svn version of Collada I get the linking errors below when linking the reader for collada in osg.
After some investigation it turns out that the method needed are not exported in the library interface for dynamic loading:
DLLSPEC daeIDRef(daeString id);
In daeidref.h:
ResolveState getState() const;
Which seems to be missing (on purpose?) DLLSPEC
DLLSPEC ResolveState getState() const;
Same for:
daeElementRef getElement() const;
and daeIDRef &operator=( const daeIDRef& other);
Now is this a bug, or is it a documented feature?
They are accessable when building a static library, but not a dynamic, why?
Are they considered internal?
One of them has a comment:
* @note This will be removed when daeURI starts managing its state internally.
Now is that in effect now? or?
1>------ Build started: Project: Plugins dae, Configuration: Release Win32 ------
1>Linking…
1>daeRMaterials.obj : error LNK2019: unresolved external symbol "public: class daeSmartRef<class daeElement> __thiscall daeIDRef::getElement(void)const " (?getElement@daeIDRef@@QBE?AV?$daeSmartRef@VdaeElement@@@@XZ) referenced in function “class daeElement * __cdecl osgdae::getElementFromIDRef(class daeIDRef &)” (?getElementFromIDRef@osgdae@@YAPAVdaeElement@@AAVdaeIDRef@@@Z)
1>daeRMaterials.obj : error LNK2019: unresolved external symbol "public: enum daeIDRef::ResolveState __thiscall daeIDRef::getState(void)const " (?getState@daeIDRef@@QBE?AW4ResolveState@1@XZ) referenced in function “class daeElement * __cdecl osgdae::getElementFromIDRef(class daeIDRef &)” (?getElementFromIDRef@osgdae@@YAPAVdaeElement@@AAVdaeIDRef@@@Z)
1>daeWMaterials.obj : error LNK2019: unresolved external symbol “public: class daeIDRef & __thiscall daeIDRef::operator=(class daeIDRef const &)” (??4daeIDRef@@QAEAAV0@ABV0@@Z) referenced in function “public: void __thiscall domFx_surface_init_from_common_complexType::setValue(class daeIDRef const &)” (?setValue@domFx_surface_init_from_common_complexType@@QAEXABVdaeIDRef@@@Z)
1
I was missing some declspec attributes for the Windows DLL build. I added them in rev 177, so it should be fixed now. Thanks for reporting the problem.