Link errors building rather simple application which uses C++ IOfacilities

[Ney André de Mello Zunino]

Hello.

I am having trouble building a simple project that uses one of the
Standard C++ Library's IO facilities. The following is a stripped-down
version that illustrates the problem:

[beginning of sample program]
#include <fstream>

int main(int argc, char* argv[])
{
std::ofstream saida("saida.txt");
}
[end of sample program]

This is the makefile I am using to build it:

[beginning of makefile]
proj = teste
libspadrao = kernel32.lib msvcrt.lib msvcprt.lib

opcomp = /c /EHs /G7 /WL /MT
oplink = /incremental:no /subsystem:windows /release /nodefaultlib
/verbose:lib

$(proj).exe: $(proj).obj
link $(oplink) $(libspadrao) $(proj).obj

$(proj).obj: $(proj).cpp
cl $(opcomp) $(proj).cpp
[end of makefile]

And finally, this is the undesirable output I get from the linker. I
tried using dumpbin in order to find where the missing symbols are
defined, but to no avail.

[beginning of relevant linker output]
quadrado.obj : error LNK2019: unresolved external symbol "long const
std::_BADOFF" (?_BADOFF@std@@3JB) referenced in function "protected:
virtual class std::fpos<int> __thiscall std::basic_streambuf<char,struct
std::char_traits<char> >::seekoff(long,int,int)"
(?seekoff@?$basic_streambuf@DU?$char_traits@D@std@ @@std@@MAE
?AV?$fpos@H@2@JHH@Z)

quadrado.obj : error LNK2019: unresolved external symbol "__int64
std::_Fpz" (?_Fpz@std@@3_JA) referenced in function "public: __thiscall
std::fpos<int>::fpos<int>(long)" (??0?$fpos@H@std@@QAE@J@Z)

quadrado.obj : error LNK2019: unresolved external symbol "public: static
class std::locale::id std::ctype<char>::id"
(?id@?$ctype@D@std@@2V0locale@2@A) referenced in function "class
std::ctype<char> const & __cdecl std::use_facet<class std::ctype<char>

(class std::locale const &)" (??$use_facet@V?$ctype@D@std@@@std@@Y

AABV?$ctype@D@0@ABVlocale@0@@Z)

quadrado.obj : error LNK2019: unresolved external symbol "private:
static int std::locale::id::_Id_cnt" (?_Id_cnt@id@locale@std@@0HA)
referenced in function "public: __thiscall std::locale::id::operator
unsigned int(void)" (??Bid@locale@std@@QAEIXZ)

quadrado.exe : fatal error LNK1120: 4 unresolved externals
[end of relevant linker output]

What is missing in my build setting? Shouldn't msvcprt.lib include the
C++'s IO-related symbols which are said to be missing?

Thank you,

--
Ney André de Mello Zunino

[Carl Daniel [VC++ MVP]]

Ney André de Mello Zunino wrote:

Hello.

I am having trouble building a simple project that uses one of the
Standard C++ Library's IO facilities. The following is a stripped-down
version that illustrates the problem:

[beginning of sample program]
#include <fstream>

int main(int argc, char* argv[])
{
std::ofstream saida("saida.txt");
}
[end of sample program]

This is the makefile I am using to build it:

[beginning of makefile]
proj = teste
libspadrao = kernel32.lib msvcrt.lib msvcprt.lib

opcomp = /c /EHs /G7 /WL /MT
oplink = /incremental:no /subsystem:windows /release /nodefaultlib
/verbose:lib

$(proj).exe: $(proj).obj
link $(oplink) $(libspadrao) $(proj).obj

$(proj).obj: $(proj).cpp
cl $(opcomp) $(proj).cpp
[end of makefile]

And finally, this is the undesirable output I get from the linker. I
tried using dumpbin in order to find where the missing symbols are
defined, but to no avail.

The problem is that you're compiling for the static multi-threaded library
then linking with the DLL library. Either change /MT to /MD on the compiler
options, or replace msvcrt.lib with libcmt.lib and msvcprt.lib with
libcpmt.lib.

-cd

[Ney André de Mello Zunino]

Carl Daniel [VC++ MVP] wrote:

The problem is that you're compiling for the static multi-threaded library
then linking with the DLL library. Either change /MT to /MD on the compiler
options, or replace msvcrt.lib with libcmt.lib and msvcprt.lib with
libcpmt.lib.

Thank you very much for your response. Switching to /MD did the trick.

FWIW, I noticed that the executable sizes decreased after this change,
which seems to be pretty natural, since code that is already in the DLL
need not be linked any longer. Strangely enough though, that was the
case to all of my programs but one. I wonder why. I would have expected
that *everyone of them* would get smaller.

Regards,

--
Ney André de Mello Zunino