Board index » cppbuilder » unresolved symbol lfind

unresolved symbol lfind


2006-04-05 03:16:43 PM
cppbuilder63
Folks,
I'm moving from Delphi to C++, trying to set up my very first pure C++
project in Borland Developer Studio 2006.
I have a simpel form, simpel button. The button on-click handler makes a
very simpel call to the LibTiff library.
In the same project group, I've successfully included a 'static library'
project that is LibTiff. I've marked dependency (the simple form project
depends on the LibTiff project), and include the LibTiff.lib file in the
simple form project.
After some fiddling and some LibTiff configuration, all seems to go well.
The LibTiff project builds fine, the LibTiff.lib file is generated. But when
compiling the simple form project, I get a linker error
[Linker Error] Error: Unresolved external '__lfind' referenced from
path\LIBTIFF.LIB|tif_dirinfo
This tif_dirinfo does have a line...
#include <stdlib.h>
I'm thinking lfind is defined in stdlib.h. The actual call to lfind is a
call to lfind, not _lfind or anything...
I'm very new to this kind of thing. Been enjoying Delphi's straightforward
simplicity for many years. I'm sure I'm making a very stupid mistake
somewhere... But I'm clueless. Please help. If this is not the right
newsgroup to ask, please point me to another.
Thank you.
--
Joris
 
 

Re:unresolved symbol lfind

I am not on the machine with BDS 2006 right now so this is from memory but I
think the function prototype for lfind is in search.h. Try including
search.h
The _lfind name is the public name for lfind. The compiler creates object
files and they contain public names for the linker to work with. Those
names are formed both from the item's name in the source code and from the
type of calling convention used, for example __cdecl which is normal C,
__stdcall which is used by most Windows functions, C++ which encodes the
calling argument list into the name and __fastcall which is used with VCL
classes. A name of '_lsearch' for the source code name 'lsearch' is how the
public name for a normal C function is formed.
. Ed
Quote
Joris Van Damme wrote in message
news:44336e5f$ XXXX@XXXXX.COM ...
Folks,

I'm moving from Delphi to C++, trying to set up my very first pure C++
project in Borland Developer Studio 2006.

I have a simpel form, simpel button. The button on-click handler makes a
very simpel call to the LibTiff library.

In the same project group, I've successfully included a 'static library'
project that is LibTiff. I've marked dependency (the simple form project
depends on the LibTiff project), and include the LibTiff.lib file in the
simple form project.

After some fiddling and some LibTiff configuration, all seems to go well.
The LibTiff project builds fine, the LibTiff.lib file is generated. But
when
compiling the simple form project, I get a linker error

[Linker Error] Error: Unresolved external '__lfind' referenced from
path\LIBTIFF.LIB|tif_dirinfo

This tif_dirinfo does have a line...

#include <stdlib.h>

I'm thinking lfind is defined in stdlib.h. The actual call to lfind is a
call to lfind, not _lfind or anything...

I'm very new to this kind of thing. Been enjoying Delphi's straightforward
simplicity for many years. I'm sure I'm making a very stupid mistake
somewhere... But I'm clueless. Please help. If this is not the right
newsgroup to ask, please point me to another.
 

Re:unresolved symbol lfind

Ed,
Thanks for your help.
Ed Mulroy [TeamB] wrote:
Quote
I am not on the machine with BDS 2006 right now so this is from
memory but I think the function prototype for lfind is in search.h.
Try including search.h
Including <search.h>in tif_dirinfo.c does not make any difference.
Quote
The _lfind name is the public name for lfind. The compiler creates
object files and they contain public names for the linker to work
with. Those names are formed both from the item's name in the source
code and from the type of calling convention used, for example
__cdecl which is normal C, __stdcall which is used by most Windows
functions, C++ which encodes the calling argument list into the name
and __fastcall which is used with VCL classes. A name of '_lsearch'
for the source code name 'lsearch' is how the public name for a
normal C function is formed.
I realize that. But I was a bit surprised to find 2 underscores before
'lfind' in the linker error, not 1. Does that seem normal, or may it be
related to my trouble?
Note also that I do not get any warning or error when compiling tif_dirinfo
itself. If it would not be able to find this 'lfind' inside the included
stdlib.h, would I not get at least a warning about an undefined symbol,
'call to function 'lfind' with no prototype' or similar? The reported linker
error only pops up when compiling the simple form project, the one that
includes the .lib, not the one that builds the .lib.
Some more general questions related to this trouble come to my mind...
- How is one supposed to know wether lfind is in stdlib.h or in search.h?
Most of the time, when hitting F1, help is useles as in 'topic not found'.
If I go ahead and search for the keyword inside the help interface, I
consistently seem to get Microsoft Visual C++ help, which is ironic at
best...
- Is my general setup, with two projects, the dependency, and the inclusion
of the '.lib' file, the normal recommended way compile and *static* link in
a library?
Best regards,
Joris
 

{smallsort}

Re:unresolved symbol lfind

Joris Van Damme wrote:
Quote
I have a simpel form, simpel button. The button on-click handler makes a
very simpel call to the LibTiff library.

In the same project group, I've successfully included a 'static library'
project that is LibTiff. I've marked dependency (the simple form project
depends on the LibTiff project), and include the LibTiff.lib file in the
simple form project.
I would guess that the LibTiff requires a runtime library that your
C++ GUI project doesn't need. So the IDE doesn't automatically include
it in the link.
This might happen if the 2 projects are compiled using different
settings.
You might try adding the bit of tif_dirinfo code that calls lfind into
your project so the project knows to include that sub-library. You
don't need to give the code the same name, or ever execute it, just so
it's there to cause linking.
 

Re:unresolved symbol lfind

The function lfind is prototyped in search.h
------------------
Quote
grep "lfind" *.h
File search.h:
void * _RTLENTRY _EXPFUNC lfind(const void * __key, const void * __base
using std::lfind;
------------------
If it cannot be found during a compile, search.h was included and you are
using C++ of the current flavor then then do one of these:
- in the source file after the includes add this line
using std::lfind;
- substitute std::lfind for lfind
Quote
... 2 underscores before 'lfind' in the linker error, not 1...
With a single underscore the link phase should not find it. The symbol
"_lfind" is provided in the compiler-supplied runtime libraries.
The error implies that the symbol used in the source code is "_lfind" and
not "lfind". As the function lfind is not part of standard C or C++, it is
viewed as a compiler-supplied language extension and a normal thing many do
for such things is to add a leading underscore to the name. A workaround
might be to provide a function something like this:
-------------
extern "C"
inline void *_lfind(const void *_key, const void *_base)
{
return lfind(_key, _base);
}
-------------
or a macro something like this:
-------------
#define _lfind(a, b) lfind((a), (b))
-------------
Note that both of the above are examples written here and are not tested.
. Ed
Quote
Joris Van Damme wrote in message
news: XXXX@XXXXX.COM ...

Including <search.h>in tif_dirinfo.c does not make any difference.

>The _lfind name is the public name for lfind. ...

I realize that. But I was a bit surprised to find 2 underscores before
'lfind' in the linker error, not 1. Does that seem normal, or may it be
related to my trouble?

Note also that I do not get any warning or error when compiling
tif_dirinfo
itself. If it would not be able to find this 'lfind' inside the included
stdlib.h, would I not get at least a warning about an undefined symbol,
'call to function 'lfind' with no prototype' or similar? The reported
linker
error only pops up when compiling the simple form project, the one that
includes the .lib, not the one that builds the .lib.

Some more general questions related to this trouble come to my mind...

- How is one supposed to know wether lfind is in stdlib.h or in search.h?
Most of the time, when hitting F1, help is useles as in 'topic not found'.
If I go ahead and search for the keyword inside the help interface, I
consistently seem to get Microsoft Visual C++ help, which is ironic at
best...

- Is my general setup, with two projects, the dependency, and the
inclusion
of the '.lib' file, the normal recommended way compile and *static* link
in
a library?
 

Re:unresolved symbol lfind

Ed,
Ed Mulroy wrote:
Quote
The function lfind is prototyped in search.h

------------------
>grep "lfind" *.h
File search.h:
void * _RTLENTRY _EXPFUNC lfind(const void * __key, const void *
__base using std::lfind;

------------------
Yes, I found that too.
I also find out in the meantime that <search.h>is indirectly included in
the tif_dirinfo.c file.
Quote
If it cannot be found during a compile, search.h was included and you
are using C++ of the current flavor then then do one of these:
- I think it *can* be found during the compile.
- search.h is included indirectly, or so it seems (and I've tried including
it directly to make sure)
- I'm not using C++, LibTiff is a C library.
Quote
- in the source file after the includes add this line
using std::lfind;
- substitute std::lfind for lfind
Neither can be compiled (probably due to the fact that LibTiff is a C
library, tif_dirinfo is a .c file, not .cpp.
Quote
>... 2 underscores before 'lfind' in the linker error, not 1...

With a single underscore the link phase should not find it. The
symbol "_lfind" is provided in the compiler-supplied runtime
libraries.

The error implies that the symbol used in the source code is "_lfind"
and not "lfind".
No, in the source code, lfind is used, not _lfind.
I think the double underscore in the linker error on the simpel form
project, is significant and very related to the core of the problem,
somehow.
Quote
As the function lfind is not part of standard C or
C++, it is viewed as a compiler-supplied language extension and a
normal thing many do for such things is to add a leading underscore
to the name. A workaround might be to provide a function something
like this: -------------
extern "C"
inline void *_lfind(const void *_key, const void *_base)
{
return lfind(_key, _base);
}
-------------
or a macro something like this:
-------------
#define _lfind(a, b) lfind((a), (b))
-------------
I'm not sure, and I'm a newbie in all this, but I think none of the above
quote applies since because the source code lfind is used, not _lfind. Is
that correct?
I've tried every possible variation of your suggestions... None of which
works. Do any of my above comments ring a bell?
Thanks for your help and patience, Ed.
Joris
 

Re:unresolved symbol lfind

Bob,
Bob Gonder wrote:
Quote
I would guess that the LibTiff requires a runtime library that your
C++ GUI project doesn't need. So the IDE doesn't automatically include
it in the link.
I think you are on to something...
Does this also explain the double underscore in the linker error, where no
underscore is present in the source code from which the .lib is successfully
build?
Quote
You might try adding the bit of tif_dirinfo code that calls lfind into
your project so the project knows to include that sub-library. You
don't need to give the code the same name, or ever execute it, just so
it's there to cause linking.
Tried that... Makes no difference.
Thanks for you help, Bob.
Joris
 

Re:unresolved symbol lfind

Folks,
I found the problem. There was a line...
#define lfind _lfind
...in one of the config files, thus I was thinking I saw 'lfind' in the
source, where it actually said '_lfind' after preprocessing. Thus, the
double underscore, and the inability of the linker to find _lfind.
Problem solved. Thanks all for your help.
Joris
 

Re:unresolved symbol lfind

Open a command window and make the project directory the default.
Give these commands and look at the results:
copy con doit.cmd
@echo %1
@tdump -m %1 | grep lfind^Z
for %a in (*.obj) do doit %a
Where ^Z means hold down the control key and press Z
If in those results you see "__lfind" (2 leading undercores) then,
substituting for "filename" the base name of the object file in which it was
found and an extension of .c or .cpp as appropiate for ".ext" do this:
cpp32 -W filename.ext | grep "lfind"
That should tell where the source code "_lfind" and public name "__lfind"
came from.
. Ed
Quote
Joris Van Damme wrote in message
news:44354c23$ XXXX@XXXXX.COM ...

Ed Mulroy wrote:
>The function lfind is prototyped in search.h
>
>------------------
>>grep "lfind" *.h
>File search.h:
>void * _RTLENTRY _EXPFUNC lfind(const void * __key, const void *
>__base using std::lfind;
>
>------------------

Yes, I found that too.

I also find out in the meantime that <search.h>is indirectly included in
the tif_dirinfo.c file.

>If it cannot be found during a compile, search.h was included and you
>are using C++ of the current flavor then then do one of these:

- I think it *can* be found during the compile.
- search.h is included indirectly, or so it seems (and I've tried
including
it directly to make sure)
- I'm not using C++, LibTiff is a C library.

>- in the source file after the includes add this line
>using std::lfind;
>- substitute std::lfind for lfind

Neither can be compiled (probably due to the fact that LibTiff is a C
library, tif_dirinfo is a .c file, not .cpp.

>>... 2 underscores before 'lfind' in the linker error, not 1...
>
>With a single underscore the link phase should not find it. The
>symbol "_lfind" is provided in the compiler-supplied runtime
>libraries.
>
>The error implies that the symbol used in the source code is "_lfind"
>and not "lfind".

No, in the source code, lfind is used, not _lfind.

I think the double underscore in the linker error on the simpel form
project, is significant and very related to the core of the problem,
somehow.

>As the function lfind is not part of standard C or
>C++, it is viewed as a compiler-supplied language extension and a
>normal thing many do for such things is to add a leading underscore
>to the name. A workaround might be to provide a function something
>like this: -------------
>extern "C"
>inline void *_lfind(const void *_key, const void *_base)
>{
>return lfind(_key, _base);
>}
>-------------
>or a macro something like this:
>-------------
>#define _lfind(a, b) lfind((a), (b))
>-------------

I'm not sure, and I'm a newbie in all this, but I think none of the above
quote applies since because the source code lfind is used, not _lfind. Is
that correct?

I've tried every possible variation of your suggestions... None of which
works. Do any of my above comments ring a bell?


Thanks for your help and patience, Ed.


Joris


 

Re:unresolved symbol lfind

Ed,
Ed Mulroy wrote:
Quote
Open a command window and make the project directory the default.
I've solved the problem already, see last message in this thread.
Some neat tricks in your last message, though, I'll try 'm and learn.
Thank you for your help!
Joris