fatal error LNK1104: cannot open file 'LIBC.lib' RRS feed

  • Question

  • I'm trying to compile a C source code project with Visual Studio 2005.  I'm linking in 2 libraries that were built using Visual Studio 2003.  When I build my project, I get 1 error:
    fatal error LNK1104: cannot open file 'LIBC.lib'

    I know libc.lib is not included with Visual Studio 2005.  How can I overcome this problem?

    Tuesday, December 13, 2005 7:28 PM


All replies

  • You might still have one of your older libs that weren't rebuilt.

    Take a look at that deals with a similar issue.

      Ayman Shoukry
      VC++ Team
    Tuesday, December 13, 2005 7:36 PM
  • The problem is that I can't rebuild the older lib.  I don't have the source code for it, all I have is the .lib file.  I have my C file which is a driver for the .lib.

    Tuesday, December 13, 2005 8:06 PM
  • The official way of doing that is actually to try to contact the lib owners and ask for a rebuild.

    That is because even if you succeed in linking, you might be mixing CRT models which is not a supported scenario.

    I am not sure if that would work or not, try adding /nodefaultlib:libc.lib to your linker command.

      Ayman Shoukry
      VC++ Team
    Tuesday, December 13, 2005 8:13 PM
  • That is going to be next to impossible.  This is a 3rd party library that was bought many moons ago.  I said the library was created with Visual Studio 2003 but that was not correct.  I'm not sure what version of VC++ was used to create the library.  We were able to link the library with our driver as of Visual Studio 2003.  If I specify the linker command you suggested, I get other unresolved symbols.

    Mike Anderson
    Tuesday, December 13, 2005 8:53 PM
  • I am not sure what is the best solution in this case. The lib folks are on these forums as well so they might be able to add more details.

      Ayman Shoukry
      VC++ Team
    Tuesday, December 13, 2005 8:57 PM
  • This is a little bit disturbing.  How could Microsoft release Visual C++ 2005 that cannot use libraries generated from previous versions of the compiler?  Microsoft cannot expect everyone to go back and regenerate the libraries.  Is noone else running into this problem?

    Wednesday, December 14, 2005 3:44 PM
  • I have the same problem. I was testing the new 2005 Visual Studio, and this error with 'LIBC.lib' comes at the end...
    Very sad, I can't use Visual Studio 2005 that seems cool by the way.
    Saturday, December 31, 2005 1:53 PM
  • move your old code that calls the old libs into a DLL, compile it w/ VS2003 and start your new code in a new module, compile it w/VS2005...
    Saturday, December 31, 2005 5:57 PM
  • Hello thanks for your anwser,

    I will try to get the library sources and compile it in my EXE project, because I have the delivery constraint that there is only one .exe file.

    I will also try to make a static library.

    I was trying to migrate totally on Visual 2005, it is still impossible, and for developers that only got Visual 2005, it seem hard...

    Are you planning to have any improvment on this subject, in a patch or something ? I always says that Microsoft is very good for retrocompatibility features so I am thinking that this is an issue for you, isn't it ?

    Wish you a happy new year !

    Monday, January 2, 2006 8:46 PM
  • It is possible!!

    The functions, clib.lib exports are already there, so all you need to do is "fool" the compiler. It only needs a library with the name "libc.lib"

    So here is what I did: I made a static lib with a single function in it

    int donothing() { return 28; }


    I compiled it in release mode, called it clib.lib and copied it to the lib folder of visual c 8. Everything was A-OK! (there was a warning though but it's a small price to pay considering the benefits)

    Goog luck to all :)

    Thursday, January 12, 2006 3:03 PM
  • I downloaded and installed the Visual C++ 2003 Toolkit and it included libc.lib.  Then I followed the instructions for including the Platform SDK found at and of course changing the path to the toolkit paths.  It worked great except for tons of linker warnings about not finding libc.pdb
    Monday, February 27, 2006 11:59 AM
  • I'm dealing with exactly the same issue.  My program links with six libraries, three of which appear to have been built with VC5.  (And for these, "-defaultlib:LIBC" shows up when I run "strings foo.lib | grep LIBC".) 

    I have the source code for one of these libraries.  I rebuilt it, and it went from being 572KB to just over 204MB.  (huoh!) 

    I don't have the source for at least one of the other libraries.  It looks like I'm going to have to either rewrite my app to replace that library -- or keep using VS 2003, which works great. 

    But VS 2003 is becoming hard to find.  For the record, I have tested my app with the Intel compiler, and it works extremely well.  So maybe the long term option is to switch to VS just as an IDE, and use ICL to do all the work. 


    Thursday, March 16, 2006 3:09 AM
  • Have you tried Sheng Jiang solution mentioned in this thread?

    Ayman Shoukry
    VC++ Team
    Thursday, March 16, 2006 3:13 PM
  • Following the idea of Borislav (no need of libc), in the project properties, add "LIBC.lib" to  Linker/Input/Ignore Specific Library.
    Wednesday, March 21, 2007 2:51 PM
  • This approach worked flawlessly for me.  And a lot simpler than creating a dummy library.

    Same situation, working with some 2003 era libs an no access to source.
    Monday, April 2, 2007 6:29 PM

    Here is an easier solution I found on another thread:


    Project Property -> Configuation Properties -> Linker -> Input -> Ignore Specific Library

    Ignore the LIBC.LIB

    I think it could fix your problems.




    • Proposed as answer by roscoe_x Wednesday, January 2, 2013 7:08 AM
    Wednesday, May 9, 2007 7:11 PM

    I met the same problem when I moved my project from VC 7 to VC 8 (2005). It worked when I followed Bumz's idea: add "LIBC.lib" to  Linker/Input/Ignore Specific Library.
    Monday, November 26, 2007 3:45 PM
  • I've had similar problems with some old libraries but ended up with:


    error LNK2019: unresolved external symbol _errno ...


    My solution for this was:

    - Project Property -> Configuation Properties -> Linker -> Input -> Ignore Specific Library: LIBC.LIB 

      (the same as /NODEFAULTLIB:"LIBC.LIB")

    - addition of file libc_errno.c to the project with these two lines:


    extern int * _errno();

    int errno() { return (*_errno()); };


    The problem is that the original static singlethreaded CRT library libc.lib has defined a true function errno() but the multithreaded one defines it as a macro errno. The symbol _errno ( the '_' comes from name mangling) is then missing when linking some old libs originally compiled for libc.lib with e.g. lbcmt.lib.


    The redefinition of the function errno() is using the same definition as is used in the multithreaded library for the macro errno(see e.g stdlib.h). It also promises correct runtime behavior but there might be another hidden issues ... 

    The lines could be included also somewhere in an existing file before includes to not conflict with the macro errno.


    Well, this is just a workaround (or fake?) and whenever possible use the original source code and recompile it with a recent compiler.





    Saturday, February 2, 2008 5:30 PM
  • When I use vs2010, I met the same problem,

    My solution is :

     LINK  -> input -> Ignore Specific Default Libraries : libc.lib


    For my code didn't use the lbc.lib

    Saturday, November 19, 2011 5:48 PM
  • I tried this.  It worked, but the DLL I'm building does not work on windows XP machines.  I suppose there is some library that is distributed with Win 7 but not in xp?  Any ideas about that?

    I also tried copying LIBC.lib from my VC 6 libraries to my VS 2010 Libraries.  When I did that, I got the error defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library.  What does that mean?  How do I know what the default libraries are and how can I change them?

    Tuesday, March 13, 2012 9:46 PM