[ydl-gen] installed YDL 4.1 over 3.0.1; rpm and yum broken: undefined symbols?

[Bill Fink]

Hi Eric,

On Sun, 27 Aug 2006, Eric Dunbar wrote:

> Hello Bill:
> 
> Two questions regarding how you determined in what file the symbol was
> defined (for the sake of learning).
> 
> On 27/08/06, Bill Fink <billfink at mindspring.com> wrote:
> > Hi Mike,
> >
> > On Fri Aug 25 2006, Michael Evans wrote:
> >
> > > I just installed YDL 4.1 from CDs (sagitta release) to a Quicksilver
> > > (2002) dual 1GHz G4 tower which was happily running 3.0.1.  At
> > > installation I chose not to reformat drives; and to install selinux and
> > > firewall with ssh port open; to install everything as I had done with
> > > 3.0.1 long ago.  The install (more install.log | grep "error") did not
> > > report any problems, and display, X, smp, networking, sound, etc appear
> > > fine.  I have /etc/yum.conf pointing to 4.1 repositories at
> > > ydl.osuosl.org, but I can't get yum or rpm to run out of the box.
> > >
> > > Here are the error messages:
> > >
> > > [root at zero ~]# yum update
> > > There was a problem importing one of the Python modules
> > > required to run yum. The error leading to this problem was:
> > >
> > >    /lib/libssl.so.5: undefined symbol: krb5_cc_get_principal
> > >
> > > Please install a package which provides this module, or
> > > verify that the module is installed correctly.
> > >
> > > It's possible that the above module doesn't match the
> > > current version of Python, which is:
> > > 2.4.2 (#1, Nov 10 2005, 16:51:21)
> > > [GCC 3.4.4 20050721 (Yellow Dog 3.4.4-2.ydl.2)]
> > >
> > > If you cannot solve this problem yourself, please send this
> > > message to <yum at lists.linux.duke.edu>.
> > >
> > > [root at zero ~]#
> > >
> > > (Should I redirect this request there?)
> >
> > The krb5_cc_get_principal symbol is defined in the krb5-libs package:
> 
> How did you know/determine that that symbol is defined in the
> krb5-libs package? Did you know that krb5-related symbols would be
> defined in the krb5-libs package because of package naming
> conventions?

Since the symbol krb5_cc_get_principal is related to Kerberos, I checked
out the various Kerberos libraries in /usr/lib until I found:

> > gwiz% nm /usr/lib/libkrb5.a | grep krb5_cc_get_principal
> >          U krb5_cc_get_principal
> > 00000138 T krb5_cc_get_principal
> >          U krb5_cc_get_principal
> >          U krb5_cc_get_principal
> >          U krb5_cc_get_principal
> > nm: ser_eblk.o: no symbols
> >          U krb5_cc_get_principal

I then used the:

> > gwiz% rpm -qf /usr/lib/libkrb5.so.3.2
> > krb5-libs-1.3.4-6

to determine that it was the krb5-libs package that was needed.
This was partly from experience.  But you could also use a brute
force approach such as:

gwiz% foreach file ( /usr/lib/lib*.a )
foreach? nm $file |& grep -v 'no symbols' | grep -w krb5_cc_get_principal
foreach? if ($status == 0) then
foreach? echo $file
foreach? endif
foreach? end
         U krb5_cc_get_principal
         U krb5_cc_get_principal
/usr/lib/libgssapi_krb5.a
         U krb5_cc_get_principal
00000138 T krb5_cc_get_principal
         U krb5_cc_get_principal
         U krb5_cc_get_principal
         U krb5_cc_get_principal
         U krb5_cc_get_principal
/usr/lib/libkrb5.a
         U krb5_cc_get_principal
         U krb5_cc_get_principal
/usr/lib/libsmbclient.a
         U krb5_cc_get_principal
/usr/lib/libssl.a

The 'T' symbol is thus defined in /usr/lib/libkrb5.a.

The above was using tcsh syntax, so bash users would have to use
a similar approach but obviously with different syntax.

If the libraries had symbols stripped, which many do, then you might
try using "strings - $file" instead, and then a little detective work.

> How did you get to finding libkrb5.a? Again, is this a naming
> convention of packages (e.g. all symbols are in files name
> libPACKAGENAME.a in /usr/lib/?)

See above.  The package name can be a clue and a help.

gwiz% rpm -qa \*krb\*
krb5-libs-1.3.4-6
krb5-devel-1.3.4-6

The devel packages are generally only needed for building the packages
from source, so in this case the krb5-libs package is the one of primary
interest, since it is what is necessary for running programs that access
the shared libraries.  Then you can do:

gwiz% rpm -ql krb5-libs | grep lib
/usr/lib/libdes425.so.3
/usr/lib/libdes425.so.3.0
/usr/lib/libgssapi_krb5.so.2
/usr/lib/libgssapi_krb5.so.2.2
/usr/lib/libgssrpc.so.3
/usr/lib/libgssrpc.so.3.0
/usr/lib/libk5crypto.so.3
/usr/lib/libk5crypto.so.3.0
/usr/lib/libkadm5clnt.so.5
/usr/lib/libkadm5clnt.so.5.1
/usr/lib/libkadm5srv.so.5
/usr/lib/libkadm5srv.so.5.1
/usr/lib/libkdb5.so.4
/usr/lib/libkdb5.so.4.0
/usr/lib/libkrb4.so.2
/usr/lib/libkrb4.so.2.0
/usr/lib/libkrb5.so.3
/usr/lib/libkrb5.so.3.2

to find out what all the Kerberos shared libraries are.

> > I had to use the .a library rather than the .so shared library since
> > the .so libraries have been stripped of the symbols.  The 'T' record
> > defines the symbol and the 'U' records are undefined references to the
> > symbol (which get resolved by the loader).
> >
> > The programs such as yum actually use the shared libraries, so to find
> > which package contains libkrb5:
> >
> > gwiz% rpm -qf /usr/lib/libkrb5.so.3.2
> > krb5-libs-1.3.4-6
> 
> Or, 'yum provides /usr/lib/libkrb5.so.3.2' ;-)

Yup, that would work too, and is a good suggestion.  Of course, you have
to have a working rpm and/or yum to do any of this.

						-Bill