Stupid Linking Question of a first time VC user

  • Thread starter Thread starter Jan Schukat
  • Start date Start date
J

Jan Schukat

Ok, I have used GNU C++ and Borland C++ for years, but now I'm forced to
switch to VC. Yet, I seem to be unable to use the standard C++ Library
outside of the Visual studio. As soon as I use makefiles the Linker
doesn't find countless symbols. The same code compiles fine when I
create a VC project. So what options do I have to set? Here is the
output I get from the linker.

Bibliothek 'en.lib' und Objekt 'en.exp' wird erstellt
libcp.lib(xwctomb.obj) : error LNK2001: Nichtaufgelöstes externes Symbol
_errno
libcp.lib(_tolower.obj) : error LNK2001: Nichtaufgelöstes externes
Symbol __pctype
libcp.lib(_toupper.obj) : error LNK2001: Nichtaufgelöstes externes
Symbol __pctype
libcp.lib(_tolower.obj) : error LNK2001: Nichtaufgelöstes externes
Symbol ___mb_cur_max
libcp.lib(_toupper.obj) : error LNK2001: Nichtaufgelöstes externes
Symbol ___mb_cur_max
en.exe : fatal error LNK1120: 3 unaufgelöste externe Verweise

link /nologo /INCREMENTAL /LIBPATH:lib /NODEFAULTLIB:libc.lib
/SUBSYSTEM:windows /out:en.exe main.obj window.obj user32.lib
advapi32.lib
 
Have you run the vcvars32 batch file so your paths are set up correctly?

Ronald Laeremans
Visual C++ team
 
Have you run the vcvars32 batch file so your paths are set up >
correctly?
Ronald Laeremans
Visual C++ team
Click to expand...

Yes, otherwise it wouldn't even compile with any source code. My problem
is, i doesn't link as soon as I'm trying to use anything from the C++
Standard library that isn't completely inline (numeric limits for
example). So using std::cin and all those stream classes leads to all
those symbols not being resolved. Yet, when I include <cstdio>, using
printf and the like works.

Is the anything else I have to take care of?

Jan
 
I just saw you had a nodefaultlib statement for libc. These references are
to symbols in libc. Why do you have the nodefaultlib in your link line?

Ronald
 
Because I had conflicting symbols the linker suggested that to me to
solve it...

Jan Schukat
 
No, that is almost never a correct solution. Generally you need to find out
what conflicts and remove it. Make sure everything links with the same
version of the CRT (multithreaded DLL is probably a sane choice).

Ronald
 
Ok, thank you, I'll try to find it out.

Jan
No, that is almost never a correct solution. Generally you need to find out
what conflicts and remove it. Make sure everything links with the same
version of the CRT (multithreaded DLL is probably a sane choice).

Ronald
Click to expand...
 
Jan Schukat wrote:

Foud my (of course stupid) mistake. When I first tried to compile with
std:: libs, I also chnaged the /ML to the /MD compiler option, and the
alredy compiled objects of course conflicted with the newly compiled
ones. Later I always uses /NODEFAULT, and thus the problems with the std::.

Thank you for bearing with me. I'll go on.

Jan
 
Back
Top