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

  • Thread starter =?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=
  • 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::blush:fstream 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
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::blush:perator
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,
 
C

Carl Daniel [VC++ MVP]

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::blush:fstream 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
 
?

=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=

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.

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,
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top