3

I'm trying to use a library where one of the classes has a constructor like so:

public:
AreaNodeIndex(size_t cacheSize);

I'm trying to instantiate an object of this class in my program like so:

size_t const cacheSize = 50000;
AreaNodeIndex areaNodeIndex(cacheSize);

The linker gives me the following error:

main.o: In function `main':
make: Leaving directory `/home/Dev/_quicktest_build'
main.cpp:(.text+0x212): undefined reference to  
osmscout::AreaNodeIndex::AreaNodeIndex(unsigned int)

I think I have the necessary includes and I'm linking to the library with the compiler. For example, if I try to instantiate the object without any arguments on purpose I get this error:

../quicktest/main.cpp: In function ‘int main()’:
../quicktest/main.cpp:36: error: no matching function for call to ‘osmscout::AreaNodeIndex::AreaNodeIndex()’
/usr/local/include/osmscout/AreaNodeIndex.h:75: note: candidates are: osmscout::AreaNodeIndex::AreaNodeIndex(size_t)
/usr/local/include/osmscout/AreaNodeIndex.h:33: note:     osmscout::AreaNodeIndex::AreaNodeIndex(const osmscout::AreaNodeIndex&)

So I can see the correct prototype (though here it says size_t and before it said unsigned int)...

I can use other parts of the library fine. Here are the actual source files for the class in question:

http://libosmscout.git.sourceforge.net/git/gitweb.cgi?p=libosmscout/libosmscout;a=blob;f=libosmscout/include/osmscout/AreaNodeIndex.h

http://libosmscout.git.sourceforge.net/git/gitweb.cgi?p=libosmscout/libosmscout;a=blob;f=libosmscout/src/osmscout/AreaNodeIndex.cpp

I'm pretty lost as to why this is happening. I feel like I've missed something obvious.

*In response to the replies: The library gets size_t from "sys/types.h", so I don't think we're using different versions. The library was compiled on my system with the same compiler (g++, linux). Changing the 'const' specifier location has no effect.

I am linking to the library. As I mentioned, I can use other classes from the library without issue. Here's the linking command:

g++ -Wl,-O1 -Wl,-rpath,/home/QtSDK/Desktop/Qt/473/gcc/lib -o quicktest main.o -L/home/QtSDK/Desktop/Qt/473/gcc/lib -losmscout -lpthread

The library name is 'osmscout'.

kfl

kfl
  • 43
  • 4
  • 1
    Is it a dynamic library or a static one? Are you using gcc on linux, as it seems? – rodrigo Sep 26 '11 at 08:36
  • Can you post also the output of this command: `objdump -t libosmscout | c++filt | grep AreaNodeIndex`? – rodrigo Sep 27 '11 at 08:27
  • I'm the author of the library. Please contact me to solve the problem. This could possibly a problem with symbol import/export macros in the library, because of wrong compiler options for compiling your code. –  Oct 22 '11 at 20:48

5 Answers5

2

Possible cause of the problem in your case could be because of mixing of different size_t as mentioned by @rodrigo. For consistency maybe you can include <cstddef> where you are using size_t unless your project declares it own typedef for size_t. Please refer the link below.

Please refer Does "std::size_t" make sense in C++?

Hope this helps!

Community
  • 1
  • 1
another.anon.coward
  • 11,087
  • 1
  • 32
  • 38
  • It is a standard type, but its equivalence is _implementation defined_, as long as it is unsigned. So the compiler has freedom to change it in different environments or with different compiler options. Not that it is wise to do that... – rodrigo Sep 26 '11 at 10:26
  • @rodrigo: But don't you think it will be consistent with the same compiler if `std::size_t` from `` is used across the source files? – another.anon.coward Sep 26 '11 at 10:29
  • Of course. But what if the library is compiled with a different compiler version? Or with a different multilib mode? Or maybe it has a library that defines its own `size_t` as it sees fit (it has been seen)? – rodrigo Sep 26 '11 at 10:47
  • @rodrigo: Yes you are right about that! If that is the case, then it might get quite messy – another.anon.coward Sep 26 '11 at 10:50
1

The problem may be that the actual size_t typedef depends on several compiler options. Even in a full 32-bit machine, it can be unsigned int or unsigned long depending on the mood of the developers.

So, if the library is compiled with typedef unsigned long size_t; and your program is with typedef unsigned int size_t; you have a problem. You can check it with objdump -t library | c++filt | grep AreaNodeIndex or something like that.

rodrigo
  • 94,151
  • 12
  • 143
  • 190
  • 1
    I'd be surprised if this were the problem. `size_t` is defined in the system includes, and should be the same everywhere. Unless he's trying to link a 32-bit library with a file compiled in 64-bit mode, but in that case, I'd expect a lot more errors. – James Kanze Sep 26 '11 at 10:59
0

You don't show us the most important part: the command line used to edit. You're probably not specifying the library to be linked in (options -l and -L, or you can specify the library as you would any other file).

As for the linker specifying unsigned int, and the compiler size_t, that's just an artifact of the way the errors are displayed: the compiler will display the name of the typedef if that's what was used when declaring the function. The linker doesn't have this information, so displays the name of the actual type.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
-1

It looks like you're not linking with the library correctly.

Frederik Slijkerman
  • 6,471
  • 28
  • 39
-1

can you try

const size_t cacheSize = 50000;

instead?

[edit] Well, I'd guess that if that declaration is giving you an unsigned long than there is some compiler option that's being overlooked, and that size_t is defined as a typedef over an unsigned long, in your compiler, and not a type that would match up with what the library see's.

C.J.
  • 15,637
  • 9
  • 61
  • 77