What /else/ causes this?

MFC Toolbox Library.lib(SimpleFileIO.obj) : error LNK2005: _wcsnlen already defined in libcmtd.lib(wcslen_s.obj)
fatal error LNK1169: one or more multiply defined symbols found

This is driving me nuts. Normally, one would get this if the various projects that are a part of their solution do not agree on which CRT to use (single threaded, multi-threaded, release or debug). However, I have been over this thing about 500 times now, and they all agree.

Background: this is a VS 2010 project just converted from VS 2008.

MFC Toolbox Library.l开发者_如何学Cib is set to compile as a static library, using /MTd, as is the target .exe I am trying to compile in this solution. Further, the solution that this is being converted from (VS 2008) already compiles & links properly!!! So it's not like that there is a disagreement between the two .vcproj's - or at least there wasn't before the conversion.

Furthermore, the MFC Toolbox Library is used by about 25 other projects in another solution - and in that solution (Master Build English) it compiles & links against those other projects without complaint in both debug and release targets.

I have just spent the last hour going over every single project property for this target project (Cimex Header Viewer) vs. several different target exe projects in Master Build English solution - and I cannot find a difference. They appear to be identical, excepting that they're different names.

I've tried doing a clean & build all. I'm simply out of ideas.

Does anyone have a thought on what else I might investigate???

I think I'm ready to start chewing glass. :(

You might check to make sure that the CRT libs are linked in the correct order

Reference: http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652

Whenever I encounter this problem and I have no clear clue, I link with the /VERBOSE option (see http://msdn.microsoft.com/en-us/library/wdsk6as6%28v=vs.80%29.aspx for details). The output of this option can be huge, but you will see which object file causes which other object file from which library to be included in the linking process.

A typical example where I used this is the following:

I wanted to completely overrule the memory allocation functions of C and C++ in a statically-linked application (dynamically-linked is much harder). I started by writing my own implementations of malloc and free and then linked this object file before linking in the C/C++ libraries.

Of course, the linker complained that some symbols (like malloc_nh or something like that) was multiply defined. Using the /VERBOSE option I could find out that there were object files that used other functions that appeared in the same object file in which Microsoft defined their malloc and free functions. I only had to add these to my 'overruling' implementation and relink.

Perhaps one project links to MFC statically and the other uses it as a DLL?

Sorry to waste everyone's time. Your answers were all the sorts of things I'd been looking at, though I haven't really used the /verbose option and would consider it in the future.

However, this one boils down to the fact that the CRT that is supplied with VS 2010 defines the function wcsnlen() whereas the CRT in 2008 does not. So I had supplied a wcsnlen() inline implementation in one of the .h files in my MFC Toolbox Library, which apparently was never referred to in any of my projects that are in the larger (53 projects) solution "Master Build English". So although the master built & linked correctly, it did so only because that function was never called by anything in those 53 sub-projects!

But this other solution (Cimex Header Viewer) did manage to invoke something in the Simple File IO portion or MFC Toolbox, which called wcsnlen, which caused the compiler to create a definition for it in SimpleFileIO.obj which later conflicts with the 2010 CRT & hence the error message.

Sigh... that was a pain to figure out because I was looking at project settings thinking that this had to be the culprit (since I was converting the project from 2008->2010). But the problem was really that there was a conflict of defined symbols, because MS suddenly supplied a defn for this function in their newer CRT.

Again - sorry to waste anyone's time. Hopefully someone else will find this Q&A of use. ;)