Home > Archive > VC STL > April 2005 > Re: Linking libs using STL gives LNK2005 (multiple definition of s
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Linking libs using STL gives LNK2005 (multiple definition of s
|
|
| mr_incredible 2005-04-11, 8:59 am |
| Thanks for replying.
Here are my settings:
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
rpcrt4.lib titusmt.lib tituscppmt.lib tlsftcti.lib /nologo /subsystem:console
/incremental:yes /pdb:"Debug/test_CallDirector.pdb" /debug /machine:I386
/nodefaultlib:"MSVCRTD" /out:"Debug/test_CallDirector.exe" /pdbtype:sept
I also ran dumpbin for each object file:
Dump of file CallDirector.OBJ
RAW DATA #1
00000000: 2D 64 65 66 61 75 6C 74 6C 69 62 3A 6C 69 62 63 -defaultlib:libc
00000010: 70 6D 74 64 20 2D 64 65 66 61 75 6C 74 6C 69 62 pmtd -defaultlib
00000020: 3A 4C 49 42 43 4D 54 44 20 2D 64 65 66 61 75 6C :LIBCMTD -defaul
00000030: 74 6C 69 62 3A 4F 4C 44 4E 41 4D 45 53 20 2D 65 tlib:OLDNAMES -e
00000040: 64 69 74 61 6E 64 63 6F 6E 74 69 6E 75 65 20 ditandcontinue
Dump of file test_CallDirector.OBJ
RAW DATA #1
00000000: 2D 64 65 66 61 75 6C 74 6C 69 62 3A 6C 69 62 63 -defaultlib:libc
00000010: 70 6D 74 64 20 2D 64 65 66 61 75 6C 74 6C 69 62 pmtd -defaultlib
00000020: 3A 4C 49 42 43 4D 54 44 20 2D 64 65 66 61 75 6C :LIBCMTD -defaul
00000030: 74 6C 69 62 3A 4F 4C 44 4E 41 4D 45 53 20 2D 65 tlib:OLDNAMES -e
00000040: 64 69 74 61 6E 64 63 6F 6E 74 69 6E 75 65 20 ditandcontinue
"Carl Daniel [VC++ MVP]" wrote:
> mr_incredible wrote:
>
> Check your compiler "code generation" settings. You probably have a mixture
> of static and DLL runtime libraries selected (checked everything that goes
> into the link).
>
> -cd
>
>
>
| |
| mr_incredible 2005-04-11, 4:04 pm |
| Thanks.
So here's how it got "fixed". I changed the one of my "offending" lib files
to /MDd and left the rest at /MTd and all of a sudden the link errors
dissapear. This does not mesh well with the documentation or any posts I have
ever read. They all say that the code generation runtime libraries should use
the SAME setting, not DIFFERENT settings. In this case, a mixture of settings
"solved" the error.
Am I missing something here or is the documnetation simply wrong?
Thanks all for taking the time to respond.
"Pete Becker" wrote:
> mr_incredible wrote:
>
> Another way to resolve link conflicts is to do a verbose link:
> Project|Settings, Link, Category: Custimize, and select "Print progress
> messages." Then rebuild the project. That will give you a list of all
> the libraries that were linked, and which names were resolved where.
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
>
| |
| mr_incredible 2005-04-29, 9:02 pm |
| So I finally figured out what happened - thought I'd post it here in case you
are ever as careless as I am sometimes...
;-)
So what it turned out to be was the dreaded (#include "stdafx.h") line that
VC 6.x inserts aoutomatically into your code if you use the "New Class ..."
command. I thought I had found all these nasty little insertions, but alas
had missed a couple of them in some header files in a couple of the libraries
I was linking to. As long as you are not using precompiled headers (and don't
need this #include), make sure it is not there and everything works as
advertised.
So the "bug" was on my end, but it was caused by code I didn't ask for or
need that was inserted into my code. I HATE IT when that happens. Oh well,
add it to the HUNDREDS of hours I have wasted over the last twenty years
coding using MS tools that insist on doing things for me I didn't ask for and
I guess it's not all that bad?...
"mr_incredible" wrote:
[color=darkred]
> Thanks.
>
> So here's how it got "fixed". I changed the one of my "offending" lib files
> to /MDd and left the rest at /MTd and all of a sudden the link errors
> dissapear. This does not mesh well with the documentation or any posts I have
> ever read. They all say that the code generation runtime libraries should use
> the SAME setting, not DIFFERENT settings. In this case, a mixture of settings
> "solved" the error.
>
> Am I missing something here or is the documnetation simply wrong?
>
> Thanks all for taking the time to respond.
>
>
> "Pete Becker" wrote:
>
|
|
|
|
|