How to ignore LNK2005 and LNK1169?

Question

So, I have a Visual Studio 2010 project that uses external libraries, and to compile it without LNK2005, I had to juggle arround with the order of the libraries in the linker settings.

I got it for compilation in release mode, but for some reason I was not able to compile it without LNK errors when debugging.

Is there no way to ignore LNK2005 altogether and tell the linker to simply use everything it encounters first?

Thanks!

// edit: here are some of the errors that arose in the FEATURES. however, I already tried to solve it differently with each solution giving me different problems with the linkers. so I'm looking for a general solution to ignore LNK2005

Error 7 error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" ( ??0type_info@ @ AAE@ABV0 @@Z) already defined in Libcmtd.lib(typinfo.obj) ...\msvcprtd.lib(MSVCP100D.dll)

Error 8 error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" ( ??4type_info@ @ AAEAAV0@ABV0 @@Z) already defined in Libcmtd.lib(typinfo.obj) ...\msvcprtd.lib(MSVCP100D.dll)

Error 9 error LNK2005: _exit already defined in Libcmtd.lib(crt0dat.obj) ...\msvcprtd.lib(MSVCP100D.dll)

Error 10 error LNK2005: __invalid_parameter already defined in Libcmtd.lib(invarg.obj) ...\msvcprtd.lib(MSVCP100D.dll)

...

Error 37 error LNK1169: one or more multiply defined symbols found

Answer 1

You can try the linker-option / FORCE option (the output of the forced file on the General tab in the project properties). This will force the linker to create exe / dll even when such errors occur. But it remains for you to find out if this exe works at all or even correctly. In the end, I would not recommend this strategy.

Linker errors can sometimes be tedious to solve, but usually you only need to do this after migrating or creating a project. This may take some time - sometimes it took me more than a day, but it must be done correctly.

Answer 2

You absolutely must not ignore linker errors, ever! The component tells you that it is confused with a symbol that is defined in several places - where should it take the definition? Do you really want this to be arbitrary? How about when you change your code and the linker accidentally decides to take a different definition that might suddenly break your code?

Instead of struggling with a tool, fix your code so that it compiles and links without errors. This MSDN article contains information about fixing it, as well as links for more information.