Library with undefined symbols fails on one machine, but works fine with another?

ta0kira · 01-24-2012, 09:17 PM

Quote:

Originally Posted by R00ts

First thing I did was run ldd on the library that has the undefined symbols.

Code:

$ ldd lib/tcs/drivers/i400/TCStcl.so 
    linux-vdso.so.1 =>  (0x00007fff4bab8000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f3d751a3000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f3d74f1f000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3d74d09000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f3d74953000)
    /lib64/ld-linux-x86-64.so.2 (0x000000392fc00000)

I ran ldd on the same library on the build machine, and received similar results. Next I used nm to find the symbol list in the file name, and sure enough the _ZTV4Line symbol was undefined (along with many other undefined symbols).

Code:

$ nm lib/tcs/drivers/i400/TCStcl.so 
.....
                 U _ZTV12Serializable
                 U _ZTV24TAO_Abstract_ServantBase
                 U _ZTV4Line
                 U _ZTV5Point
                 U _ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3
.....

First of all, undefined symbols in the symbol table of a shared library mean one of three things:

The program (or library) linking to the shared library in question defines those symbols.
A library the shared library in question is linked to defines those symbols.
Those symbols remain undefined when the dynamic linker strings everything together, giving you an error.

"Undefined" is only bad in the third case, which often happens if you take a library or program compiled on one machine and try to run it on another because the symbols exported by the libraries on the new machine might differ. The benefit of dynamic linking is that these symbols are resolved once during linking for verification, but then they're resolved again at run-time. This allows you to rebuild a library (e.g. upgrade it) without having to rebuild all of the things that depend on it.
Kevin Barry

R00ts · 01-25-2012, 11:57 AM

Yeah, I've been reading a helpful document on shared libraries to fill my knowledge gaps (http://www.akkadia.org/drepper/dsohowto.pdf).

I think I made a major breakthrough this morning. What I did was to remove the line in the Tcl script that loads the Commontcl.so library where all these missing symbols are located. I replaced that by going into the C++ code and calling dlopen instead:

Code:

  void* retval = dlopen("lib/common/drivers/Commontcl.so", RTLD_NOW | RTLD_GLOBAL);
  if (retval == NULL) {
    std::cerr << "Failed to open Commontcl.so. dlerror: " << std::endl;
    std::cerr << dlerror() << std::endl;
  }

Lo and behold, now there are no unresolved symbols! So naturally my guess is that somehow the default settings for how Tcl loads shared library files changed. So I'm looking into that at the moment.

R00ts · 01-26-2012, 12:03 PM

Well I fixed the problem (in an acceptable manner). I uninstalled Tcl that came on my Fedora 16 system (1.8.5.11) and installed Tcl 8.6b1 from source and then I had no problems with undefined symbols. So it may just be that that particular Tcl version/package is buggy. Well that only took me two weeks to find out.

Thanks for your help here everyone.