7

My solution built yesterday. Today after changing nothing but .hpp and .cpp files it doesn't.

The full error text from Visual Studio 2013 (Using the November 2013 CTP):

Error   1   error LNK2005: __xi_a already defined in MSVCRT.lib(cinitexe.obj)   C:\Users\drtwox\dev\repos\game\trunk\engine\game\LIBCMT.lib(crt0init.obj)   game
Error   2   error LNK2005: __xi_z already defined in MSVCRT.lib(cinitexe.obj)   C:\Users\drtwox\dev\repos\game\trunk\engine\game\LIBCMT.lib(crt0init.obj)   game
Error   3   error LNK2005: __xc_a already defined in MSVCRT.lib(cinitexe.obj)   C:\Users\drtwox\dev\repos\game\trunk\engine\game\LIBCMT.lib(crt0init.obj)   game
Error   4   error LNK2005: __xc_z already defined in MSVCRT.lib(cinitexe.obj)   C:\Users\drtwox\dev\repos\game\trunk\engine\game\LIBCMT.lib(crt0init.obj)   game
Error   7   error LNK1169: one or more multiply defined symbols found   C:\Users\drtwox\dev\repos\game\trunk\engine\build\x64\Test\game.exe 1   1   game

About as useful as a poke in the eye...

This answer to this similar question says:

You are mixing code that was compiled with /MD (use DLL version of CRT) with code that was compiled with /MT (use static CRT library). That cannot work, all source code files must be compiled with the same setting. Given that you use libraries that were pre-compiled with /MD, almost always the correct setting, you must compile your own code with this setting as well.

I have checked (and rechecked) that all projects in the solution are still using the same runtime library; Multi-threaded DLL for Release and Multi-threaded Debug DLL for Debug. I've done a full solution rebuild just to be sure.

The Subversion log shows the 'external' directory that contains all 3rd party libraries had not been modified since 2013-12-04; one month ago. I checked their configurations and rebuilt them anyway.

The Subversion log also shows that only existing .hpp and .cpp files have been modified since yesterday. No new libraries have been added, no new external headers #included and no project configurations have changed. There are over 200 lines of changed and new code in 7 files.

What could be the problem?

Update: The log from the compiler: http://pastebin.com/aHJ5Xi2V

Solution: The problem was not incorrect /MT /MD compiler flags, it was the GLEW library and a missing #define GLEW_STATIC. I changed the GLEW project settings to use /Zl (Omit Default Library Name) as documented here: http://msdn.microsoft.com/en-us/library/f1tbxcxh.aspx.

Community
  • 1
  • 1
x-x
  • 7,287
  • 9
  • 51
  • 78
  • "...after changing nothing but .hpp and .cpp files..." I'm *positive* I'm not the only one remotely interested in what those changes *are*. Visual C++ allows, via `#pragma comment`, link commands to be amended to a project *while compiling source*. It is entirely conceivable one of the seemingly unrelated changes you're dismissing introduced one such directive by way of a previously non-encountered header. – WhozCraig Jan 04 '14 at 08:46
  • @WhozCraig, no use of #pragma anywhere in the entire solution. No new external headers were #included. I'll mention as much in the question. – x-x Jan 04 '14 at 08:52
  • 1
    There is zero-doubt both runtimes *are* being linked. Without project configuration changes the only other conceivable reasons are incorrect pragma comments (not yours, someone else's) or a hidesouly dirty build, and you say you've already accounted for that. – WhozCraig Jan 04 '14 at 08:55
  • @WhozCraig, I haven't added any new #includes, but I have moved around some #includes. I have a vague memory of GLEW (one of the #included headers) causing problems before... you've given me something to investigate! – x-x Jan 04 '14 at 09:14
  • 1
    The release builds of GLEW are configured to link to `libcmt.lib` as a default lib - at least the MSVC 10 project in the GLEW source distribution is set up that way. I don't know why that wouldn't have been a problem before, but the workings of linkers can be somewhat mysterious and the order that they process object file inputs and when they happen to come across references can influence how they find external names. – Michael Burr Jan 04 '14 at 11:37
  • You are using a custom build of the CRT, required by the game engine. You must build your program with /MT to keep it happy. – Hans Passant Jan 05 '14 at 00:46
  • @HansPassant, The game engine does not use a custom CRT; I know this because the engine is my project! I can assure you that LIBCMT.lib does not exist in that directory: http://imgur.com/ADGuV29 – x-x Jan 05 '14 at 00:58
  • Anonymous downvoter: If you're going to downvote, please provide a reason why. – x-x Jan 05 '14 at 02:26

1 Answers1

4

Something is causing both runtimes to be linked in.

First try cleaning (manually) all .obj and .lib files that your project creates and rebuild it.

If that doesn't help, set the linker's /VERBOSE flag ("Linker | General | Show Progress" = "Display all progress messages (/VERBOSE)" in the IDE).

Then look at the output; in the IDE it'll be in the build output directory in a file called <project-name>.log.

You'll see where each library is searched and what object file is causing the library to be searched.

Update:

The log output shows that LIBCMT.lib is being searched due to a DEFAULTLIB directive in one or more of the object files being processed (which may be an object file from a library).

However, it's not clear to me form the log output which input(s) is responsible - I think it's glew32s.lib (the glew.obj object in it).

See this SO answer for a way to find which .obj/.lib files have a DEFAULTLIB directive.

You might get away with setting the /NODEFAULTLIB:libcmt.lib option in the project properties ("Ignore Specific Default Libraries").

Community
  • 1
  • 1
Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • The log is 3562 lines long! What precisely am I looking for? I've uploaded it here http://pastebin.com/aHJ5Xi2V – x-x Jan 04 '14 at 09:11
  • Thank you for the help. It **was** GLEW causing the problem. – x-x Jan 05 '14 at 01:11