LINK 2005 error

Started by
7 comments, last by rohini chandra 17 years, 11 months ago
Hi , I am getting the following LINK 2005 error when I tried to build my project in vc++7.1. I am doing the build process in win32release mode. I have searched google on this but whatever I found was related to standard dll's and lib's. Here in my case it is not a standard lib.It is generated by a different project in another workspace. ---------------------------------------------------------------------------­-------------------------------------------------------- ghjkl.lib(ghjkl.dll) : error LNK2005: "public: int __thiscall OSF_Task<class OSF_Thread_Mutex,class OSF_Condition_Thread_Mutex>::getq(class OSF_Message_Block * &,class OSF_Time_Value *)" (?getq@?$OSF_Task@VOSF_Thread_Mutex@@VOSF_Condition_Thread_Mutex@@@@QAEHAAP­AVOSF_Message_Block@@PAVOSF_Time_Value@@@Z) already defined in abc.obj ---------------------------------------------------------------------------­---------------------------------------------------------- The function getq(class OSF_Message_Block * &,class OSF_Time_Value *) is not defined in abc.cpp but it is declared and defined in another header file asd.h. I am putting the relevant code below. ***asd.h ---------------------------------------------------------------------------­------------------------------------------------------- class ghj{ typedef STL_Message_Queue<OSF_Recursive_Thread_Mutex, OSF_Manual_Event> MessageQueue; int getq(OSF_Message_Block*& mb, OSF_Time_Value* tv=0) { return mq_->dequeue_head(mb,tv); } private: MessageQueue* mq_; } ---------------------------------------------------------------------------­---------------------------------------------------------- Any help is appreciated. Thanks in advance Best Regards, Rohini Chandra
Advertisement
Rohini,

The "already defined" link error occurs whenever the linker tries to resolve a symbol and finds that it is defined in two different places.

In your case, you're defining the function (different from declaring it) in a header file. This header file is then being included in the compilation of more then 1 .cpp file. Thus, when the compiler links the first object file (.o) with the second object file, its finding a re-definition of the symbol.

The solution is to declare your function in a header file, and then define it in a .cpp file.

Also, you should make sure to include:

#pragma once

At the beginning of all of your header files. This helps to prevent multiple includes, and reduces the likelyhood of encountering errors such as you've discovered.

Cheers!
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
Chronicles of Elyria (An In-development MMORPG)
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints
That's strange... IIRC if a function is defined inside a class definition it is treated as inline and so can be in a header file (C++ compilers are supposed to be able to handle this). Try declaring the function inline anyway and see if that helps.
The problem is likely the missing '#pragma once' guard at the top, as you're correct, being a member function it should just treat it as inline...so perhaps the entire class is being multiply defined.
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
Chronicles of Elyria (An In-development MMORPG)
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints
Hi Jeromy,
Thanks for the advice.
I have used #pragma once but it did not solve my problem.


Here is some more information which can help you analyse my problem.There are two .h files where the function is declared and defined one is abc.h and the other efg.h
=========================================================================================================================

abc.h
==================
typedef OSF_Task<OSF_MT_SYNCH> Task;

class Task: public OSF_Event_Handler
{
public:
int getq(OSF_Message_Block*& mb, OSF_Time_Value* tv=0)
{
return mq_->dequeue_head(mb,tv);
}
}
=========abc.h

efg.h
========
template <OSF_SYNCH_DECL>
class OSF_Task : public OSF_Task_Base
{
Public:
int getq (OSF_Message_Block *&mb, OSF_Time_Value *timeout = 0);
}


template <OSF_SYNCH_DECL>
OSF_INLINE int
OSF_Task<OSF_SYNCH_USE>::getq (OSF_Message_Block *&mb, OSF_Time_Value *tv)
{
return this->msg_queue_->dequeue_head (mb, tv);
}
=========efg.h

efg.h is included in abc.h

class OSF_Task_Base,class Task inherit from OSF_Event_Handler

# define OSF_MT_SYNCH OSF_Thread_Mutex, OSF_Condition_Thread_Mutex

# define OSF_SYNCH_DECL class _OSF_SYNCH

# define OSF_SYNCH_USE _OSF_SYNCH


=========================================================================================================================

Please help me resolve this problem.
Thanks once again.
Rohini Chandra
Rohini,

Something I noticed which might be causing the compiler some confusion...you're defining a typedef and a class with the same name.
// This creates a symbol called "Task" which is a data typetypedef OSF_Task<OSF_MT_SYNCH> Task;// This creates a symbol called "Task" which is also a data typeclass Task : public OSF_Event_Handler{   //...}

Make sure those are not given the same name, and then we'll move on from there.
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
Chronicles of Elyria (An In-development MMORPG)
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints
Hi Jeromy,
I am very sorry for misguiding you.
There is if else condition which I did not provide in my previous reply.

abc.h
==================
#ifdef USE_OWN_TASK

class Task: public OSF_Event_Handler
{
public:
int getq(OSF_Message_Block*& mb, OSF_Time_Value* tv=0)
{
return mq_->dequeue_head(mb,tv);
}
}
#else
typedef OSF_Task<OSF_MT_SYNCH> Task;
#endif
=========abc.h

Please help me resolve this problem.


Is it possible that USE_OWN_TASK is defined in one compilation unit, but not in another?
Hi,
some more information which may provide some insight into my problem.

The project jkl in which I was getting the LNK2005 error uses a lib generated by another project xyz.
Till now I have been using the lib generated by the xyz project after some modifications to get it compiled in vc++7.1.

Now I have tried the lib previously generated by project xyz in vc++ 6.0.
Now I am able to build project jkl but with the the following errors which seem related to the link error I got before.

I feel these warnings are possibly getting converted into Link errors.

I would like anyone to help me in this regard.
This problem is holding me down for quite some time.

-------------------------------------------------------------------------------
abc.obj : warning LNK4049: locally defined symbol ?getq@?$OSF_Task@VOSF_Thread_Mutex@@VOSF_Condition_Thread_Mutex@@@@QAEHPAVOSF_Message_Block@@PAVOSF_Time_Value@@@Z (public: int __thiscall OSF_Task<class OSF_Thread_Mutex,class OSF_Condition_Thread_Mutex>::getq(class OSF_Message_Block *,class OSF_Time_Value *)) imported

efg.obj : warning LNK4217: locally defined symbol ?getq@?$OSF_Task@VOSF_Thread_Mutex@@VOSF_Condition_Thread_Mutex@@@@QAEHPAVOSF_Message_Block@@PAVOSF_Time_Value@@@Z (public: int __thiscall OSF_Task<class OSF_Thread_Mutex,class OSF_Condition_Thread_Mutex>::getq(class OSF_Message_Block *,class OSF_Time_Value *)) imported in function "public: virtual void * __thiscall std::length_error::`scalar deleting destructor'(unsigned int)" (??_Glength_error@std@@UAEPAXI@Z)
--------------------------------------------------------------------------------
Any help is highly appreciated.
Thanks in advance.

This topic is closed to new replies.

Advertisement