Which version of the code are you using? It looks like you’re using an old version of the DOM. Check out the DOM trunk and work from that:
svn co https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/trunk colladadom
I’m fairly sure that the static lib works fine because RT uses the static lib and I just built RT yesterday. It’s possible that upgrading to the latest DOM won’t fix your problem because there’s something you’re doing wrong, but using an old version would have gotten you in trouble in other ways anyway.
I’ve tried by donwload new svn version.
Now i can compile, but (and i do not know why) beyond my exe file there is also a .lib files and it can’t start becouse it say me that he is unable to find the start point of xmltextreaderattributecount
Yes, we support VS 2008. We only provide 2005 project files and you have to use VS to convert them to 2008, which I assume you’ve done.
Try building the domTest project. Assuming it builds fine, run it on the command line with ‘domTest -all’. All tests should pass.
If you get to this point it’s likely you’re doing something wrong in your app. domTest can be used as an example of a working Collada app. Look at the project settings and see if there’s something different from what you’re doing.
It sounds like you might be linking against the DLL version of the DOM instead of the static lib. The static lib ends in ‘-s’, as in libcollada14dom20-s.lib (release) or libcollada14dom20-sd.lib (debug). If you want the DLL version, you need to define DOM_DYNAMIC in your project settings. This makes sure you get all the __declspec(dllimport) statements you need for working with a DLL on Windows.
You want libxml2_a.lib, which is the static libxml2 lib. libxml2.lib is for the dll.
Do you know where can i download compiled bins?
DOM 2.0 pre-built binary packages won’t be available until DOM 2.0 is published, which will be very soon.
Days. What’s the problem about building from source in the meantime? The problem you’re having with libxml2.lib isn’t something that having pre-built DOM binaries would fix for you.
It gives me an unhandled exception on new DAE() - (std::badalloc)
I do not think i’ve got the heap full…infact also using normal instance (DAE collada_dom;) i receive same exception.
But now it say me that it can’t start becouse application configuration is incorrect, whyle if i use only collada debug library it say me “Can’t find MSVCR90.dll”…
If i use original configuration in release mode it works, but i can’t debug application
I don’t think that’s the case. IIRC they build against the debug dll like all the other debug stuff, but I have debug info turned off.
When I would try to link a debug app against the release version of PCRE I would get link errors. That’s the only reason I provide a debug version of PCRE in the first place.
I don’t think that’s the case. IIRC they build against the debug dll like all the other debug stuff, but I have debug info turned off.
When I would try to link a debug app against the release version of PCRE I would get link errors. That’s the only reason I provide a debug version of PCRE in the first place.
Regardless I’ll take a look tomorrow.[/quote:36ncuzha]
Sorry, I asserted that too assuredly. But it is my theory nonetheless. Switching from the debug to the release pcre libraries was the only way I as able to execute my debug build (both of my application and COLLADA_RT).
I’m eager to hear back from you once you look into it. These bugs have got me stumped.