link error + COLLADA

Started by
11 comments, last by Limitz 17 years, 7 months ago
Hey guys, I got a problem that i never encountered before, maybe you can help me deal with this one. I just got the Collada DOM lib to use in my game engine. It uses libxml2, iconv and zlib. When i link against these libraries however (using MS VS 2003 compiler + codeblocks) i get a number of errors, since some of the libs is linking against LIBC.LIB and the default lib is MSVCRT.lib. MSVCRT.lib(MSVCR71.dll) : error LNK2005: _strncmp already defined in LIBC.lib(strncmp.obj) is one of them, you get the drift. What should i do??? I would like to get everything compiled with /MD if possible. Thanks in advance + Greetings, Eddy - Limitz
Advertisement
I had the same problem with new/delete using MFC headers, etc.

Go into your project properties -> linker properties..
There are 2 fields you are worried about. Ignore specific library and Additional Dependencies (thats what they are called in VS2005). Basically you want to ignore the libraries that are giving you trouble (both of them). Then link them later by putting them in Additional Dependencies. This will ensure they get linked in the correct order.

Hope that helps.
-------Harmotion - Free 1v1 top-down shooter!Double Jump StudiosBlog
Hey,

Great, that seems to work. I had to find the right compiler option for it, since i work with CodeBlocks, but i used Visual Studio to do what you suggested, and saw that the commandline for that ignore should be: /NODEFAULTLIB:msvcrt.lib,libc.lib

I compiles, at last :)

however it takes a staggering 50 seconds to compile (is this normal???) this is the source i compile... it is minimal.
EDIT: correction, it takes 50 seconds to link
EDIT2: hmmm, probably is just the shear number of libs in needs to compile against. never mind

#define VERSION 2#define USE_LIBXMLPLUGIN 0// System includes#include <stdio.h>#include <cstdlib>#include <iostream>// Collada API includes#include "dae.h"#include "dom/domCOLLADA.h"#include "dom/domConstants.h"#include "dom/domFx_include_common.h"#if USE_LIBXMLPLUGIN#include "modules/daeLIBXMLPlugin.h"#include "modules/daeLIBXMLResolver.h"#endifusing namespace std;int main(){  DAE *input = new DAE;  return 0;}


Anyway, thanks a lot for the hint.
Don't statically link.
Quote:Original post by Anonymous Poster
Don't statically link.


This post is not helpfull at all. If you don't plan to use more than 4 words and don't give any context or argumentation for your flawed statement, please don't post at all.
The fact that statically linking is the source of the problem, doesn't mean that "not statically linking" is a solution.
4 words is all that is necessary for such a noobish question.
Quote:Original post by Anonymous Poster
4 words is all that is necessary for such a noobish question.


Is this answer really useful ?
Quote:Original post by Anonymous Poster
Quote:Original post by Anonymous Poster
4 words is all that is necessary for such a noobish question.


Is this answer really useful ?


No.

If the first AP plans to stay dumb for the rest of his life, that's his problem. He dones't have to bother us with his bitchy attitude. That would be helpful.

Limitz, your problem is indeed due to static linking. It seems that the COLLADA library you are using has been compiled using different settings than your code. To correct the problem, you have 2 solutions:
* either find the correct seetings (maybe they are documented somewhere - such a problem should have been noticed by someone else before, and the reaquired change in the configuration may be already documented somewhere).
* or, if you can't, I'm affraid you'll have to resort to dynamic linking.
Of course, there is a simpler solution if you have the source code of the conflicting library: just recompile it using the exact same project options that your project is currently using.

Regards,
When linking with lots of static .lib files, I've found VS2005's "Use Library Dependency Inputs" to be extremely useful, cutting the link time from minutes down to seconds. As far as I can tell, it just adds all the original .obj files (as used when creating the .libs) onto the linker command line, so the same could be fairly simple through other IDEs. But that option wasn't in VS2003's IDE, so I don't know if the corresponding compiler version supports it.
Quote:Original post by Emmanuel Deloget
Quote:Original post by Anonymous Poster
Quote:Original post by Anonymous Poster
4 words is all that is necessary for such a noobish question.


Is this answer really useful ?


No.

If the first AP plans to stay dumb for the rest of his life, that's his problem. He dones't have to bother us with his bitchy attitude. That would be helpful.

Limitz, your problem is indeed due to static linking. It seems that the COLLADA library you are using has been compiled using different settings than your code. To correct the problem, you have 2 solutions:
* either find the correct seetings (maybe they are documented somewhere - such a problem should have been noticed by someone else before, and the reaquired change in the configuration may be already documented somewhere).
* or, if you can't, I'm affraid you'll have to resort to dynamic linking.
Of course, there is a simpler solution if you have the source code of the conflicting library: just recompile it using the exact same project options that your project is currently using.

Regards,


Do you mean the problem is that one of the libs uses LIBC and the other uses the MVSCRT? Or what settings are you talking about?
I did recompile Collada lib from scratch (before i even posted), so i think the problem is in either libxml2, iconv or zlib. I will try to recompile these as well. Otherwise i will make my own 'wrapper dll' for the whole, that should speed it up too.

Thanks for the reply.

This topic is closed to new replies.

Advertisement