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

  • Thread starter Thread starter =?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=
  • Start date Start date
?

=?ISO-8859-1?Q?Ney_Andr=E9_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 said:
(class std::locale const &)" (??$use_facet@V?$ctype@D@std@@@std@@Y
Click to expand...
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 said:
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.
Click to expand...

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
 
Carl said:
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.
Click to expand...

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,
 
Back
Top