Converting Project to Use msvcprt.lib instead of msvcirt.lib

I am attempting to convert a project to use msvcprt.lib
rather than msvcirt.lib.

When I run nmake on the .mak file I am getting an
error 'unable to open msvcirt.lib'.   I have removed
all references to msvcirt.lib in the .mak file.

The error is actually occuring at the linking stage, so it looks
like the reference is inside an embedded library.

As far as I know I have successfully rebuilt all libraries used
by the application with msvcprt.lib in place of msvcirt.lib.

I am probably picking up the reference to msvcirt.lib
through an include file, which includes an include file, which
....    Anyway you get the idea.

Can I force nmake or the compiler to give me a dump of the all the include files used at the compiliation stage

Is there anyway I can force the linker to give me more detail
as to where it is picking up the reference to msvcirt.lib.

/Ross

Answer this question

Converting Project to Use msvcprt.lib instead of msvcirt.lib

compass
I used the "link /dump /directive" to trace down one reference
to msvcirt.lib, and I then subsequently found one reference to
strstrea.h in one of the source files for the library in question.

Based upon the URL above, strstrea.h will result in the use of the old i/o libraries including I believe msvcirt.lib.

What is the appropriate substitution in Visual C++ 2005 for strstrea.h in order to avoid the use of the old i/o libraries

/Ross
Phil_88
Thank you for the two replies.

The application that is being linked compiled successfully, and
it being linked to four other application specific libraries and six microsoft libraries and of course one object file for the application itself.

None of the 10 libraries in the command line is msvcirt.lib.

I have rebuilt (I think) the four application specific libraries without msvcirt.lib. However, of course, I may be wrong on this point, and this is what I am trying to find out.

The linker is searching the library list to resolve external calls from the object files when it fails while trying to open msvcirt.lib.

How does the linker develop its list of libraries to search for external calls and what would cause it to attempt to open MSVCIRT.LIB.

If I can understand how the search list of libraries is developed then maybe I can trace back to the reference to msvcirt.lib.

/Ross
Zeonz
Ross,

In addition to /verbose, you may also search for headers listed on this topic
http://msdn.microsoft.com/library/default.asp url=/library/en-us/vccore98/html/_core_make_the_old_iostream_library_the_default.asp
and remove them.
Also you can edit a copy of these headers and add pragma message("including old header"). Then in Build log you see this message while building files that includes these headers.
Thanks,
Nikola
VC++ Team
cholev
Ross: try linking with the /verbose switch: the output generated should show you why the linker feels it is necessary to pull in msvcirt.lib
masterlegolas3
Hello,

I have exactly the same problem. 3rd party dll-s using msvcirt.lib. Did you ever get around this. Please e-mail me to dinoablakovic@REMOVEhotmail.com
Yannick De Koninck
Ross: when resolving external references the linker will only search those libraries that are specified on the command-line and those that are specified via linker directives that appear in source code: like the one shown below:

#pragma comment(lib, "msvcprt")

So even though you are not explicitly linking against msvcirt.lib it could be that you are still including a header (or source file) that include such a #pragma for msvcirt.lib.

You can see if a static library xxx.lib contains such a directive by running:

link /dump /directives xxx.lib

If it does then you should see something like the following:

/defaultlib:kernel32.lib
Tony1979
Ross: the Visual C++ 2005 equivalent for strstrea.h is strstream.
Converting Project to Use msvcprt.lib instead of msvcirt.lib

Answer this question