Weird problem with linker
Francisco M. Marzoa
I've a weir problem with BCC linker. This is the error it gives me:
[Linker Error] Unresolved external 'TTagList::GetCount()' referenced
from C:\DEVEL\SFCOMS\SAMPLEAPPS\RIDEL\RIDELDEMO\READALL.OBJ
Well, ReadAll.cpp is a form of an application that contains this:
...
if ( Tags->Count ) {
...
Now, Tags is an instance of TTagList, defined on TagList.cpp. In the
includes of ReadAll.cpp I've put:
...
#include "TagList.h"
...
But this does not make the matter, as It compiles fine, but it does not
link later.
TTagList has a property that's *public* declared as:
public:
...
__property int Count = {
read=GetCount
};
Method GetCount for TTagList is declared as:
protected:
int GetCount (void);
Note that the method is protected, but it should be cause I'm using the
property Count to access this value and it is public.
As I've said, both modules compiles well by separate, the trouble comes
when linking. By other side, I've used that TTagList object from a
component that I'm writting without this problems.
Any ideas?
Andrue Cope [TeamB]
Forgive me if I'm misinterpreted your post but it seems to me that
you're misunderstanding a basic principal of C/C++ development. I
apologise profusely if this is the case.
> Now, Tags is an instance of TTagList, defined on TagList.cpp. In the
> includes of ReadAll.cpp I've put:
>
> #include "TagList.h"
>
> But this does not make the matter, as It compiles fine, but it does
> not link later.
Why do you think there is a relationship between #include and linker
errors? It is possible for header files (and indeed any source code) to
specify files to be linked but this is unusual and not particularly
standard.
All that a header usually does is tell the compiler what the function
will look like. It's up to you to either provide the source for the
function or an OBJ or LIB file containing the compiled code for that
function.
> Method GetCount for TTagList is declared as:
>
> protected:
> int GetCount (void);
Again, this is just a function declaration. What the linker is
complaining about is that it can't find the function itself. You
mention 'TagList.Cpp' - I would assume this contains the code for
TTagList. Have you added this file to the project? If not then that
will be the cause of the problem.
In 'C/C++' all #include does is tell the compiler to start reading from
a different file. There is no explicit relationship between 'taglist.h'
and 'taglist.cpp'. It's only common sense, convention and modern IDEs
that lead programmers to name them that way. If 'taglist.cpp' isn't in
your project then it might as well not exist as far as the
compiler/linker are concerned.
--
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html
Francisco M. Marzoa
> Francisco M. Marzoa wrote:
>
> Forgive me if I'm misinterpreted your post but it seems to me that
> you're misunderstanding a basic principal of C/C++ development. I
> apologise profusely if this is the case.
>
>
>>Now, Tags is an instance of TTagList, defined on TagList.cpp. In the
>>includes of ReadAll.cpp I've put:
>>
>>#include "TagList.h"
>>
>>But this does not make the matter, as It compiles fine, but it does
>>not link later.
>
>
> Why do you think there is a relationship between #include and linker
> errors?
This is not the case, excuse me, my true problem is not C/C++, but my
english:
What I want to show with this is that at least the function is really
declared because the compiler do its work without errors. I think this
information is interesting to find the source of the problem and its
solution.
>>Method GetCount for TTagList is declared as:
>>
>>protected:
>> int GetCount (void);
>
>
> Again, this is just a function declaration. What the linker is
> complaining about is that it can't find the function itself. You
> mention 'TagList.Cpp' - I would assume this contains the code for
> TTagList. Have you added this file to the project? If not then that
> will be the cause of the problem.
I've try also adding TagList.cpp and TagList.h to the project, even when
they're in a directory that I've added to Include and Lib paths on
project options, I've tried also moving them from its location to the
Project's path where the file ReadAll.cpp resides with same problems.
> In 'C/C++' all #include does is tell the compiler to start reading from
> a different file. There is no explicit relationship between 'taglist.h'
> and 'taglist.cpp'. It's only common sense, convention and modern IDEs
> that lead programmers to name them that way. If 'taglist.cpp' isn't in
> your project then it might as well not exist as far as the
> compiler/linker are concerned.
They do really exists and the function is implemented. As I've told that
TTagList class are also used from another project (not an application,
but an VCL component) that I'm writting without these problems. This one
compiles and links fine.
I've been making some tests. One of them has been going to
Project/Export Makefile on BCB IDE.
In a first attempt to run Borland's make from a command line (aka
MS-DOS) window it gives me another error, something as "VCL.BPI not
found". So I've edited the file adding $(BCB)\lib\Release to LIBPATH and
this error pass. Then it gives me another error related to TagList, so
I've added on OBJFILES TagList.obj and then all compiles and links ok
creating a function .exe file. ¿?
Then, I've tried on the IDE Project/Edit option source and adding
TagList.obj to OBJFILES, but it doesn't solve the matter. I've also
added $(BCB)\lib\Release to
Project/Options/Directories|Conditionals/Library path even when I think
this is not required, but it didn't work neither.
¿?
Thanks a million by your answer, of course.
Andrue Cope [TeamB]
> > Why do you think there is a relationship between #include and linker
> > errors?
>
> This is not the case, excuse me, my true problem is not C/C++, but my
> english:
Okay, my bad then. It seem did an unusually basic question to ask so I
was unsure about it :
> I've try also adding TagList.cpp and TagList.h to the project, even
> when they're in a directory that I've added to Include and Lib paths
> on project options, I've tried also moving them from its location to
> the Project's path where the file ReadAll.cpp resides with same
> problems.
Hmmm. Can you post the declaration from the header and the CPP?
I've not personally ever encountered a situation where the linker
couldn't find something that was genuinely there to be found. I have
often failed to spot a subtle difference between declaration and
definition or a project option that changed the name to something the
linker wasn't expecting.
Someone else in .language.cpp asked the same question as you and
eventually found it was down to a declaration mismatch.
I've set follow-up to .language.cpp since that section has a lot more
traffic and so will increase the chances of getting a solution.