none
error LNK2005 RRS feed

  • Question

  • I have a Dll which "Not Using ATL and MFC". Can anyone have a clue from where these link errors are coming.

     

    SynPaintPhpControlBar.obj : error LNK2005: "long __cdecl ATL::AtlMultiply(int *,int,int)" (??$AtlMultiply@H@ATL@@YAJPAHHH@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "long __cdecl ATL::AtlMultiply(unsigned int *,unsigned int,unsigned int)" (??$AtlMultiply@I@ATL@@YAJPAIII@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "long __cdecl ATL::AtlMultiply(long *,long,long)" (??$AtlMultiply@J@ATL@@YAJPAJJJ@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "long __cdecl ATL::AtlMultiply(unsigned long *,unsigned long,unsigned long)" (??$AtlMultiply@K@ATL@@YAJPAKKK@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "void * __cdecl ATL::AtlCoTaskMemCAlloc(unsigned long,unsigned long)" (?AtlCoTaskMemCAlloc@ATL@@YAPAXKK@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "void * __cdecl ATL::AtlCoTaskMemRecalloc(void *,unsigned long,unsigned long)" (?AtlCoTaskMemRecalloc@ATL@@YAPAXPAXKK@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "bool __cdecl ATL::_ATL_SAFE_ALLOCA_IMPL::_AtlVerifyStackAvailable(unsigned long)" (?_AtlVerifyStackAvailable@_ATL_SAFE_ALLOCA_IMPL@ATL@@YA_NK@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "void * __stdcall InterlockedExchangePointer(void * *,void *)" (?InterlockedExchangePointer@@YGPAXPAPAXPAX@Z) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "unsigned int __stdcall ATL::_AtlGetThreadACPFake(void)" (?_AtlGetThreadACPFake@ATL@@YGIXZ) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "unsigned int __stdcall ATL::_AtlGetThreadACPReal(void)" (?_AtlGetThreadACPReal@ATL@@YGIXZ) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "unsigned int __stdcall ATL::_AtlGetThreadACPThunk(void)" (?_AtlGetThreadACPThunk@ATL@@YGIXZ) already defined in SynPaintPhp.obj
    SynPaintPhpControlBar.obj : error LNK2005: "unsigned int __stdcall ATL::_AtlGetConversionACP(void)" (?_AtlGetConversionACP@ATL@@YGIXZ) already defined in SynPaintPhp.obj

     

    SynPaintDoc.obj : error LNK2005: _atan2l already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _ceill already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _cosl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _coshl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _expl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _fabsl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _floorl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _fmodl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _frexpl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _ldexpl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _logl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _log10l already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _modfl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _powl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _sinl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _sinhl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _sqrtl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _tanl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _tanhl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: __chgsignl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: __copysignl already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _frexpf already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _fabsf already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _ldexpf already defined in stdafx.obj
    SynPaintDoc.obj : error LNK2005: _acosf already defined in stdafx.obj

    Tuesday, April 8, 2008 4:17 PM

Answers

  • Something seems completely wrong in your setup.

     

    The ATL symbols certainly shouldn't be defined as symbols in non-COMDAT sections or COMDAT-sections without duplicate removal semantics. This suggests some preprocessor transformation suppresses inline here (e.g. you have a /Dinline= on the compiler command line).

     

    The C symbols are even more mysterious. I can't think of any case where a extern "C" function would be implemented inline.

     

    Anyway, can you show us your compiler settings (it's best to get the from buildlog.htm as these are as close as it gets).

     

    Secondly, you should try to preprocess you stdafx.cpp (temporily select preprocess in the compiler options -- this will cause no .obj file to be generated and linking will likely fail with a fatal error, that's to be expected) and search in the generated .i file for some of these function definitions.

     

    Just show us one _definition_ and the corresponding original header file (you can identify that from the closest preceding #line directive)

     

    Also, which version of the toolchain are you using?

    -hg

     

    Tuesday, April 8, 2008 8:50 PM
  • You can use the compiler switches /E, /P, /EP to generate a view of the your translation unit (~= .cpp + include files) after preprocessing. That is what you can use to detect macro problems.

     

    For instance, if you had some shared header.h which is included from your stdafx.h with something like this

     

    inline void foo() {}

     

    This is perfectly fine. Every object file referencing that function should get a copy of the function in a specially marked section that allows the linker to select any of them without issueing an error.

     

    Now if for whatever reason a macro definition for inline would be active that would expand to nothing the compiler would actually see

     

    void foo() {}

     

    This causes the function to be emitted in every object file without the duplicate removal semantics. Hence an error LNK2005.

     

    You cannot really tell from the source code. That's why you should preprocessing.

     

    To enable the preprocessing in the IDE, select the property pages for stdafx.cpp and under C++ -> Preprocessor select "Generate Preprocessed File" : "With Line Numbers"). You also look up compiler switch in MSDN Library index (just type in there with the preceding slash)

     

    When you rebuild you will get a stdafx.i file with how things would look like after preprocessing. You can then match the preprocessed output to the original headers (the #line directives will help you to do so) and then figure out what has happened to the functions in question.

     

    Note that preprocessing means that the compiler will not proceed after preprocessing. No object file will be generated, and the linker will fail with a fatal error. There preprocessing is usally only useful for diagnosing problems. You should reset the setting after you've figured out the problem.

     

    -hg

     

    Tuesday, April 8, 2008 10:43 PM

All replies

  • It would appear as though despite telling your project to not use ATL, you are including ATL header files in at least one of your project's translation units.

     

    Try changing your project settings to 'Dynamic Link to ATL' under Configuration Properties->General->Use of ATL.

    Tuesday, April 8, 2008 4:31 PM
  •  

    'Dynamic Link to ATL' under Configuration Properties->General->Use of ATL.

     

    i did this but still the same link errors are there.

    Tuesday, April 8, 2008 7:57 PM
  • Something seems completely wrong in your setup.

     

    The ATL symbols certainly shouldn't be defined as symbols in non-COMDAT sections or COMDAT-sections without duplicate removal semantics. This suggests some preprocessor transformation suppresses inline here (e.g. you have a /Dinline= on the compiler command line).

     

    The C symbols are even more mysterious. I can't think of any case where a extern "C" function would be implemented inline.

     

    Anyway, can you show us your compiler settings (it's best to get the from buildlog.htm as these are as close as it gets).

     

    Secondly, you should try to preprocess you stdafx.cpp (temporily select preprocess in the compiler options -- this will cause no .obj file to be generated and linking will likely fail with a fatal error, that's to be expected) and search in the generated .i file for some of these function definitions.

     

    Just show us one _definition_ and the corresponding original header file (you can identify that from the closest preceding #line directive)

     

    Also, which version of the toolchain are you using?

    -hg

     

    Tuesday, April 8, 2008 8:50 PM
  •  

    The ATL symbols are gone now. i turned off one include which was including atlbase.h. How ever the C symbols are still there.

     

    Here are my compiler settings from buildlog.htm

     

    /Od /I "c:\xampp\PHPSrc\php-5.2.5\Zend" /I "c:\xampp\PHPSrc\php-5.2.5\ext" /I "c:\xampp\PHPSrc\php-5.2.5\regex" /I "c:\xampp\PHPSrc\php-5.2.5\main" /I "c:\xampp\PHPSrc\php-5.2.5" /I "c:\xampp\PHPSrc\php-5.2.5\TSRM" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_USRDLL" /D "SYNPAINTDLL_EXPORTS" /D "_SYNPAINTPHPDLL_" /D "_PARSER_NOT_USE_MFC_" /D "_WINDLL" /D "_MBCS" /GF /FD /EHsc /MTd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c /Zi /TP ..\..\..\PARSER\guixtpar.cpp

     

    I am using VS2005 with FRamework 2.0

     

    Secondly what you  mean by this :

    search in the generated .i file for some of these function definitions.

    Just show us one _definition_ and the corresponding original header file (you can identify that from the closest preceding #line directive)

    Tuesday, April 8, 2008 10:29 PM
  • You can use the compiler switches /E, /P, /EP to generate a view of the your translation unit (~= .cpp + include files) after preprocessing. That is what you can use to detect macro problems.

     

    For instance, if you had some shared header.h which is included from your stdafx.h with something like this

     

    inline void foo() {}

     

    This is perfectly fine. Every object file referencing that function should get a copy of the function in a specially marked section that allows the linker to select any of them without issueing an error.

     

    Now if for whatever reason a macro definition for inline would be active that would expand to nothing the compiler would actually see

     

    void foo() {}

     

    This causes the function to be emitted in every object file without the duplicate removal semantics. Hence an error LNK2005.

     

    You cannot really tell from the source code. That's why you should preprocessing.

     

    To enable the preprocessing in the IDE, select the property pages for stdafx.cpp and under C++ -> Preprocessor select "Generate Preprocessed File" : "With Line Numbers"). You also look up compiler switch in MSDN Library index (just type in there with the preceding slash)

     

    When you rebuild you will get a stdafx.i file with how things would look like after preprocessing. You can then match the preprocessed output to the original headers (the #line directives will help you to do so) and then figure out what has happened to the functions in question.

     

    Note that preprocessing means that the compiler will not proceed after preprocessing. No object file will be generated, and the linker will fail with a fatal error. There preprocessing is usally only useful for diagnosing problems. You should reset the setting after you've figured out the problem.

     

    -hg

     

    Tuesday, April 8, 2008 10:43 PM
  •  

    Holger

     

    Thanks for your detailed answer. I will look at Generate Preprocessed File if some time in the future I stuck into horrible link errors like this. The problem is solved now. It was a simple problem like File C was including File B and File A. That file B was also including File A. I just made file C to include File B and all the link errors are gone.

     

    Thanks all

    Wednesday, April 9, 2008 5:53 PM