Hi all,

is there a way to find if a static lib is linked into my executable. For example I have say

liba.a
libb.a
libc.ko (dynamic)

I link as per normal in my makefile, it reports no errors. In my code I add
#include "liba.h"
#include "libb.h"
#include "libc.h"

everything is ok.

I call a function from lina

libafunc()

it's OK

However when I try to call any function from b it reports that the linbfunc() is missing. I think libb is linking from make output. I know it sees linb.h as if I declare a structure defined in it its OK. I know my libbfunc() func is spelt write, I've cut and pasted from the libb.h prototype declaration.

So it looks like libb is not linked even though it says it is from the make file?

Is there some command I can type to my executable to find out what static libs have been lined in? Thanks

man ldd

I'm afraid not - ldd will show you the dynamic dependencies. No information about the statically linked libraries ends up in the executable.

What's the actual error you get - could you post it here? Is it at link-time or run-time?

It sounds like it's at link-time. You can use nm to list the symbols in your libb.a file - make sure the symbol you need (i.e. the one the linker complains about) is defined there.



You've got a declaration, fine - but is it defined anywhere? Check the definition matches the declaration, and that the relevant object file's been linked into libb.a.

Hi

well the prototype is shown as application_start

so I do a test call
this give the following error

main.c.text+0xc): undefined reference to `application_start'
collect2: ld returned 1 exit status
make: *** [all] Error 1


when I nm the library I can't see a pure application_start (like I would in my own libs) however I can see

00000d20 T _Z22application_startP11data_ti

Which seems a little odd?

Anyway nm demangle works and shows

00000d20 T application_start(data_t*, int)

It looks like the library was compiled with a C++ compiler, which will produce the mangled symbol "_Z22application_startP11data_ti", and then you're compiling your program with a C compiler, which will look for the unmangled symbol "application_start".

There are several ways around this:

Probably the best way is to just compile everything, including your application, with a C++ compiler - it will always use name mangling, and you'll then be able to find your symbol. This may cause the reverse problem if liba.a is compiled with a C compiler, but just compile that as C++ instead. As a bonus, you'll get the extra type checking of C++.

You could also prevent libb.a from mangling its exported symbols by using extern "C" - the usual way to do this is like the following in the C++ header file:

John G

Thanks, yes it's a C++ lib, the programmer had absolutely assured me it was standard C. I'm not happy with them!

Perhaps a click on the "thanks" button might be appropriate then ...

It probably is written in standard C - it's just not compiled with a standard C compiler. Compiling C with a C++ compiler is generally not a bad idea - it's much stricter, and discards only a few features of C that are "generally" considered dangerous anyway.

You just need to remember not to use any C++ features and to use extern "C", of course but you can always check this by occasionally making sure it builds with a C compiler.