Symbol Lookup Error Undefined Symbol, But All Symbols Seem to Be Present

Symbol lookup error undefined symbol, but all symbols seem to be present

nm -D shows that the symbol auth_class_names is defined

No: it shows that auth_class_names is undefined in libcharon.so.

libstrongswan provides the auth_class symbol, but libcharon doesn't reference it.

Wrong again: libcharon.so does reference the symbol.

ldd /usr/lib/libstrongswan.so

That's not what you want. You want ldd /usr/lib/libcharon.so.

Your problem is most likely that neigher libcharon.so, nor the main executable were linked against libstrongswan.so, so when you dynamically load libcharon.so, libstrongswan.so is nowhere to be found; hence the loading fails with undefined symbol.

There are several possible solutions, ordered from more correct to more hacky:

1. Link libcharon.so against libstrongswan.so. Loading libcharon.so will load all of its dependencies (which will now include libstrongswan.so, and the symbol will be found).

2. Link charon binary against libstrongswan.so.

3. Dynamically load libstrongswan.so before you load libcharon.so.
4. LD_PRELOAD=libstrongswan.so

How to fix symbol lookup error: undefined symbol errors in a cluster environment

After two dozens of comments to understand the situation, it was found that the libhdf5.so.7 was actually a symlink (with several levels of indirection) to a file that was not shared between the queued processes and the interactive processes. This means even though the symlink itself lies on a shared filesystem, the contents of the file do not and as a result the process was seeing different versions of the library.

For future reference: other than checking LD_LIBRARY_PATH, it's always a good idea to check a library with nm -D to see if the symbols actually exist. In this case it was found that they do exist in interactive mode but not when run in the queue. A quick md5sum revealed that the files were actually different.

Related Topics