how to resolve unresolved symbols

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

how to resolve unresolved symbols

Burlen Loring
Hi all,

I have some questions on how to resolve some undefined symbols. I am not
understanding the basic process by which these get defined/resolved, so
I hope I can get some info on how this would happen.

I am trying load a .so external to the code base which it was created
for use with. These are "plugin" objects that are opened using that code
bases plugin manager which internally does its work with dlopen. I have
loaded the plugin within the application it was built for use with and
everything works. When I run my test harness, which uses the
application's plugin manager to open the plugins, I see a dlopen failure
to resolve some symbols. Here is the message.

tycho:~$./PluginManagerTest
Error opening plugin file:
/home/burlen/X/src/plugins/databases/../../lib/libbow.so: undefined
symbol: vtk_zlib_inflateInit_
Invalid plugin: Error opening plugin file for plugin
/home/burlen/ext2/visit/visit1.10.0/src/plugins/databases/libIBOWDatabase.so.
The system error message was
'/home/burlen/X/src/plugins/databases/../../lib/libbow.so: undefined
symbol: vtk_zlib_inflateInit_'.

I would expect this sort of thing because the loader could not find the
right library that the .so referred to in its search path, but when I
use ldd to examine the .so I am not seeing anything like that. The
library these symbols are actually in is not even listed! Here is what I
get.

tycho:~$ldd -r /home/burlen/X/src/lib/libbow.so
        linux-gate.so.1 =>  (0xb7f50000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7e40000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e1b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e0f000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cc0000)
        /lib/ld-linux.so.2 (0xb7f51000)
undefined symbol: _Z10VisItFstatiP6stat64      
(/home/burlen/X/src/lib/libbow.so)
undefined symbol: vtk_zlib_inflateInit_ (/home/burlen/X/src/lib/libbow.so)
undefined symbol: vtk_zlib_inflate      (/home/burlen/X/src/lib/libbow.so)
undefined symbol: vtk_zlib_inflateEnd   (/home/burlen/X/src/lib/libbow.so)
undefined symbol: vtk_zlib_deflateInit_ (/home/burlen/X/src/lib/libbow.so)
undefined symbol: vtk_zlib_deflate      (/home/burlen/X/src/lib/libbow.so)
undefined symbol: vtk_zlib_deflateEnd   (/home/burlen/X/src/lib/libbow.so)

It works in the original app so I know its just a matter of my not
understanding how the loading process works in this case.  I am confused
about how those undefined symbols would get resolved? How can the loader
resolve them with out a path to a specifc .so file? How could the files
be linked successfully with those undefined symbols?

Thanks in advance
Burlen

Reply | Threaded
Open this post in threaded view
|

Re: how to resolve unresolved symbols

Daniel Jacobowitz-2
On Wed, Oct 15, 2008 at 10:33:39AM -0400, Burlen Loring wrote:
> I would expect this sort of thing because the loader could not find the  
> right library that the .so referred to in its search path, but when I use
> ldd to examine the .so I am not seeing anything like that. The library
> these symbols are actually in is not even listed! Here is what I get.

This is a bug in the plugin.  You can fix it by linking the plugin to
whatever libraries provide those symbols, or you can work around it by
linking the test framework to those applications - the executable that
normally loads the plugin is getting those libraries loaded some other
way.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: how to resolve unresolved symbols

Brian Dessent
In reply to this post by Burlen Loring
Burlen Loring wrote:

> How can the loader
> resolve them with out a path to a specifc .so file?

What probably happened was that whatever lib provides those symbols
happened to be already loaded when the application dlopened the plugin,
so the fact that the plugin is missing one or more NEEDED tags didn't
matter.  Maybe the app itself links to that lib, or maybe it was a
plugin that was dlopened prior to libbow.so.  Or perhaps those symbols
are actually defined in the executable.  Whatever sequence of events
cause the symbols to be defined in the real app isn't being replicated
in your standalone app, and that's why it fails.

Using ldd on the plugin doesn't accurately reflect the same
circumstances as when it's dynamically loaded.  With ldd you're asking
the loader to start from scratch whereas with dlopen you have an
established dynamic symbol table reflecting everything that's happened
prior to the call to dlopen.

> How could the files
> be linked successfully with those undefined symbols?

The ELF linker lets you shoot yourself in the foot if you want to.  You
can use -Wl,--no-undefined to change the default.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: how to resolve unresolved symbols

Burlen Loring
Brian Dessent wrote:

> Burlen Loring wrote:
>
>  
>> How can the loader
>> resolve them with out a path to a specifc .so file?
>>    
>
> What probably happened was that whatever lib provides those symbols
> happened to be already loaded when the application dlopened the plugin,
> so the fact that the plugin is missing one or more NEEDED tags didn't
> matter.  Maybe the app itself links to that lib, or maybe it was a
> plugin that was dlopened prior to libbow.so.  Or perhaps those symbols
> are actually defined in the executable.  Whatever sequence of events
> cause the symbols to be defined in the real app isn't being replicated
> in your standalone app, and that's why it fails.
>
> Using ldd on the plugin doesn't accurately reflect the same
> circumstances as when it's dynamically loaded.  With ldd you're asking
> the loader to start from scratch whereas with dlopen you have an
> established dynamic symbol table reflecting everything that's happened
> prior to the call to dlopen.
>
>  
>> How could the files
>> be linked successfully with those undefined symbols?
>>    
>
> The ELF linker lets you shoot yourself in the foot if you want to.  You
> can use -Wl,--no-undefined to change the default.
>
> Brian
>  
Great explanation, very helpful, Thanks,
Burlen