Using objdump to see a called function

I'm having this problem where I'm trying to link to a 3rd party library and I'm getting "undefined reference" to a function that is supposed to be in the library. I'm trying to use objdump to see exactly what the object file making the call thinks the function looks like (with all its parameters, qualifiers, etc) and then compare that against an objdump of the library object and *hope* to figure out what makes them different. Unfortunately, so far my objdumps on my object file just give the name of the function, but none of its other properties.

Quote:

---

Originally Posted by Angus

I'm having this problem where I'm trying to link to a 3rd party library and I'm getting "undefined reference" to a function that is supposed to be in the library. I'm trying to use objdump to see exactly what the object file making the call thinks the function looks like (with all its parameters, qualifiers, etc) and then compare that against an objdump of the library object and *hope* to figure out what makes them different. Unfortunately, so far my objdumps on my object file just give the name of the function, but none of its other properties.

---

If the objdump is giving you a bare name, then the function is not a C++ function. For C++ functions, objdump will either report the mangled name (which would be obvious), or if you pass the -C option, it will demangle the name. In either case, it would not look like a bare name.

So, it looks like this library is exporting functions with C linkage. You will need to prototype them appropriately with extern "C". If the include files which come with the library don't already do this (and it seems like they don't), you'll have to do it yourself:

Code:

---

extern "C"
{
#include <whatever.h>
}

---

If you are not using C++ at all, then I'm not sure what's happening. I'd need to see the output from objdump, and the code you are using to try to call the function.

EDIT: objdump is not capable of telling you the parameter types or other properties of a function, because the object file format does not support that. It can do it in the case of C++ because this data is mangled directly into the name, but if this is a C library, what you see is what you get.

Actually, the extern "C" is there, and the function was compiled as a C function.

So object files don't record the header signature for C functions, such that if the object file had a function call with the right name, but the wrong, say, set of parameters, the call would be linked anyway?

Actually, the problem turned out to be that strip was called on the 3rd party library. I'm assuming this is the wrong thing to do w/static libraries. Clearly it was key to the failure of the linker, because now it works, and so does the executable.

Thanks

Quote:

---

Originally Posted by Angus

So object files don't record the header signature for C functions, such that if the object file had a function call with the right name, but the wrong, say, set of parameters, the call would be linked anyway?

---

Exactly. This is why name mangling was invented in the first place -- the object format does not naturally carry this information, so it's embedded into the name itself.

Quote:

---

Actually, the problem turned out to be that strip was called on the 3rd party library. I'm assuming this is the wrong thing to do w/static libraries. Clearly it was key to the failure of the linker, because now it works, and so does the executable.

---

Stripping a library pretty much ruins it. You strip linked binaries, not object files or libraries.