From GridWiki
Revision as of 03:47, 5 October 2012 by Timcera (talk | contribs) (Reverted edits by LindaLopez (talk) to last revision by Raysonho)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Periodically, users post questions to the GE Users mailing list about problems with various dynamic libraries. A common problem is to have "undefinded symbols" in various programs. For example, when running a perl script:

/usr/bin/perl: symbol lookup error: /usr/lib/perl5/5.8.5/i386-linux-thread-multi/auto/DB_File/DB_File.so: undefined symbol: db_version


ImportError: /usr/lib/python2.3/lib-dynload/_bsddb.so: undefined symbol: db_create

This can be maddenly frustrating, since the main program (perl in this case) is installed correctly and has correct permissions. If you delve further, you find that the libraries are also present and have correct permissions. Running ldd also works. Clever admins will even check LD_LIBRARY_PATH, and find that it works as well...

After consuming a few gallons of coffee, and removing most of remaining hair that you may have, you may find that LD_LIBRARY_PATH, is in fact the culprit. In the settings.[c]sh file, LD_LIBRARY_PATH is modified to include the $SGE_ROOT/lib/$SGE_ARCH directory. Included therein is libdb-4.2.so. Since loading dynamic libraries from LD_LIBRARY_PATH is done "early," this will frequently override other copies of libdb that are installed. This frequently includes libraries in /usr/lib.

There are a few possible solutions:

  • Edit settings.[c]sh to not modify LD_LIBRARY_PATH.
  • Edit LD_LIBRARY_PATH so that the system directories are checked before the SGE lib/ directory
  • Upgrade to SGE 6.1 or above (settings.[c]sh no longer munges LD_LIBRARY_PATH).