0

I have a Visual Studio 2010 C++ project that links statically to tinyxmlSTL 2.5.5 (tinyxmlSTL.lib) and zlib 1.2.7. (zlibstat.lib). There are 4 builds in total covering both x86 and x64 as well as Debug and Release.

All combinations produce working builds except for Release x64 which gets a bunch of errors like this:

MSVCRT.lib(MSVCR100.dll) : error LNK2005: free already defined in LIBCMT.lib(free.obj)

...and a single warning:

LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library

If I add /NODEFAULTLIB:MSVCRT to linker options for the application then I get this:

zlibstat.lib(ioapi.obj) : error LNK2001: unresolved external symbol __imp__ftelli64
zlibstat.lib(ioapi.obj) : error LNK2001: unresolved external symbol __imp__fseeki64

Basically, all the projects (app and two libs) are set to use Multi-threaded (/MT) option in Release builds and yet x86 builds just fine while x64 suffers from above issues.

Any help or idea is highly appreciated.

wpfwannabe
  • 14,587
  • 16
  • 78
  • 129
  • 1
    The linker errors leave no doubt, your assumption that /MT is selected consistently is wrong. – Hans Passant Aug 25 '12 at 13:29
  • Yes, I understand that now but it leaves me wondering where is the problem. Editing the question and attaching screenshots of project settings probably serves no purpose. One thing that springs to mind is that ever since the `zlib` project was added x64 build stops building. So `zlib` is probably the culprit but Runime Library is definitely set to /MT. – wpfwannabe Aug 25 '12 at 13:34
  • @wpfwannabe - I've updated my answer to include instructions for building zlib with `/MT`. – Fraser Aug 25 '12 at 14:04

3 Answers3

2

You need to double check your settings for x64. One of the projects is using the /MD flag rather than /MT.

As per the MSVC docs, The MSVCRT.lib is invoked by using /MD.


EDIT :

As per your comments, it sounds like zlib is the likely culprit.

zlib has both a static and dll version, but both of these use the /MD flag by default, so unless you changed that while building zlib - that's your issue.

To build zlib using /MT:

  1. If you've not already done so, install CMake

  2. Download and extract zlib to e.g. C:\devel. The download links are about halfway down the homepage. Currently this provides zlib version 1.2.7.

  3. To work around this CMake bug, add

    if(CMAKE_SIZEOF_VOID_P EQUAL 8 AND MSVC)
      set_target_properties(zlibstatic PROPERTIES STATIC_LIBRARY_FLAGS "/machine:x64")
    endif()
    

    to the end of C:\devel\zlib-1.2.7\CMakeLists.txt

  4. In a VS10 command prompt, cd C:\devel\zlib-1.2.7

  5. cmake -H. -Bbuild -G"Visual Studio 10 Win64"

This gets you a VS sloution C:\devel\zlib-1.2.7\build\zlib.sln which you can open. Change the settings for the "zlibstatic" target to /MT and /MTd for Release and Debug respectively.

Building each will yield zlibstatic.lib in a subdirectory of build; either "Release" or "Debug".

Fraser
  • 74,704
  • 20
  • 238
  • 215
  • Thanks! I can't try your solution at this time but it probably gives *exactly* what I already have now. Please bear in mind that the archive `zlib-1.2.7.tar.bz2` downloaded from the zlib site already includes SLN for VS 2010. There is no need for going down the cmake route. Additionally, I did have to change to /MT just as you described but this yields happiness in x86 build only. I will try your proposed solution as soon as I can but I expect nothing to change. – wpfwannabe Aug 25 '12 at 15:01
  • Great! After your edited answer things finally started moving in the right direction. I got rid of the issues and life is good again. I wish I could do without `cmake` though. – wpfwannabe Aug 26 '12 at 14:27
1

In the project properties for ALL projects, check that they all use the same runtime type: either DLL or static

This can be found under Project Properties -> C/C++ -> Code Generation -> Runtime Library. Make sure you have the Release x64 build selected.

The particular value isn't very important (in terms of compile errors) but they should all be the same

Andrew Brock
  • 1,374
  • 8
  • 13
1

I know you say that all your libs are linking with /MT but that error suggests that one of them isn't. Re-check that the correct libs are being linked with the x64 Release build.

snowdude
  • 3,854
  • 1
  • 18
  • 27