Problem building COLLADA-DOM

Hello.
I am truing to build a project using Collada DAE and DOM
But I am getting tons of linker errors

[ul]libxml2_a.lib(nanohttp.obj) : error LNK2019: unresolved external symbol __imp__WSAGetLastError@0 referenced in function _socket_errno
libxml2_a.lib(nanohttp.obj) : error LNK2019: unresolved external symbol __imp__WSACleanup@0 referenced in function _xmlNanoHTTPCleanup
libxml2_a.lib(nanoftp.obj) : error LNK2001: unresolved external symbol __imp__WSACleanup@0
libxml2_a.lib(nanohttp.obj) : error LNK2019: unresolved external symbol __imp__listen@8 referenced in function _xmlNanoFTPGetConnection
libxml2_a.lib(nanoftp.obj) : error LNK2019: unresolved external symbol __imp__bind@12 referenced in function _xmlNanoFTPGetConnection
libxml2_a.lib(nanoftp.obj) : error LNK2019: unresolved external symbol __imp__getsockname@12 referenced in function _xmlNanoFTPGetConnection

….

Build log was saved at
dgExport - 28 error(s), 1 warning(s)[/ul]
I tried all of the run time libraries and I get maybe more of then
These are with the: Multi-threaded DLL (/MD)

I also check in google to see if other people have the same problems, and it look like plenty do, but not answerer except to link with eth correct libraries.
How do the people that are using collada are solving this problem.

I really suggest to the Collada committee that the build process should be simplified
Setting the project required too many steps. And many of then required lot of guessing and trial and error.

For the C runtime, you should be using the multithreaded debug DLL for debug builds and multithreaded DLL for release builds. This is explained in the programming guide that comes with the DOM documentation.

As for the other libraries, here’s what I link against in a release build of my Collada loader: libcollada_dae.lib libcollada_dom.lib libcollada_STLDatabase.lib libcollada_LIBXMLPlugin.lib libcollada_stdErrPlugin.lib libxml2_a.lib zlib.lib iconv_a.lib wsock32.lib. I think your errors were from missing wsock32.lib.

I really suggest to the Collada committee that the build process should be simplified. Setting the project required too many steps. And many of then required lot of guessing and trial and error.
Working with projects in Visual C++ is always clunky and error-prone in my experience.

I believe I did read the programmer API and set the paths, and the libraries dependecies as it is instructed (I think), but I do not remember it saying that it needed wsock32.lib, At least not in the docs that came with download 1.4.1
Anyway by the name of the missing functions it seems that makes sense, I will try tonight. Thanks

It makes you wonder why a XML library that should be only concerned with text manipulation in a local machine requires a network library?

I would say that beauty is in eye of the beholder.
It would help if the project came with all of the tools it needs to be build, and with a working project file, and let the more advanced users go out and find better versions of the dependencies if they want better XML files.

It makes you wonder why a XML library that should be only concerned with text manipulation in a local machine requires a network library?
The xml allows you to store references to external documents that can be on another machine in the network or at some URL, etc. The dom will go and load in those referenced documents automatically. So it actually does have to deal with networking issues. This is made as transparent as possible so that you don’t have to deal with it if you’re just using local files, but yeah, you still need a networking library to link against.

It would help if the project came with all of the tools it needs to be build, and with a working project file, and let the more advanced users go out and find better versions of the dependencies if they want better XML files.
The conditioners provided with the dom are good examples of building executables that use the dom.

How do the people that are using collada are solving this problem.

Indeed, it is always a hassle of projects that leave the developer messing for hours or days to get the project to work for their platform.

To solve this, I autogenerated projectfiles for both LibXML and COLLADA_DOM myself, and configured LibXML to NOT use HTTP. Indeed, no support for cross-references accross the internet. If someone asks for this feature, I might enable it again, but by default its turned off for my case.

Using autogenerated projectfiles has the added benefit of supporting ALL versions of MSVC. It compiles,links and runs out-of-the-box in my open source Bullet Library, and it includes a recent copy of both LibXML and COLLADA_DOM.

Autogeneration is currently done using Jam+msvcgen, and I store the autogenerated projectfiles in the distribution, so people don’t have to hassle with jam. I am migrating towards CMake, it can autogenerate Apple XCode projectfiles, next to msvc projectfiles etc. If you download Bullet source code, you can find the msvc projectfiles for libxml and colladadom in the msvc folder, and LibXML/COLLADA_DOM in the Extras folder.

Erwin
http://bullet.sourceforge.net