CODEWITHSUNDEEP
clinux
Don Shankin
Don Shankin

Reputation: 440

Can't resolve symbol in shared library, but symbol name is not given

I did a search for this, but didn't find any answers for this specific problem. I have an application that links in several shared objects. It is complaining about not being able to resolve a symbol, but it gives me an empty string for the symbol name that it's trying to resolve:

<path_to_application_name>: symbol '': can't resolve symbol in lib '<path_to_a_specific_shared_object>'

As I mentioned, this application links to several shared objects, but it called out one specifically, in which it's looking for the symbol. GDB doesn't give any additional information, at least to the ability that I know how to use it. Is there any way to tease more information out of this error message? I will be able to debug if I know what it's actually looking for.

Thanks in advance

Upvotes: 2

Views: 2932

Answers (1)

Don Shankin
Don Shankin

Reputation: 440

So I found the problem the other day. First, I will take the cowardly way to save face and note that I inherited the particular project from others, which is part of the reason that it took me longer than I'd like it to have taken.

First off, I was attempting to integrate a new version of an existing .so into the project, which basically just included a few extra API calls that we were after. Of course this just so happened to be the library that was called out in the error message. Apparently, the .so itself makes calls to functions that are defined in a third library, which itself is statically linked into the original application calling the .so. There already existed API calls in the shared object that were linked in this odd way, and they worked fine before I even my hands on this project. This is probably what threw me off; the additional calls are what seemed to break everything. However, the reason that it worked was because there was a second .so, which apparently also had definitions of the functions that were referenced in the first .so, and actually defined in the statically linked library. The new API calls did not share this arrangement. So... when I tried to add this new version of the first .so, those new API calls were never (incorrectly) defined in the second .so. Needless to say, I performed some surgery on this arrangement, and all is well now. Thanks to all for the help and suggestions.

Upvotes: 1

Related Questions