0

I am trying to diagnose linker/runtime errors using setenv LD_BIND_NOW TRUE. When I run the executable with this option enabled, I get the error 

   lib/libmkl_intel_thread.so: error: symbol lookup error: undefined symbol: DftiFreeDescriptor (fatal)

However, if I then remove the LD_BIND_NOW environmental variable, the program executes just fine (until termination, whereupon it reports a memory corruption--though that might be unrelated).

So I am a bit confused: How does the program execute when it has a symbol lookup error? I thought it would have to terminate as the program is written in C++, not Java. (See here for reference.)

Also, does this error imply that my rpath is set incorrectly, or has the MKL so been built improperly? Is there a fix that can be achieved in bounded time?

Community
  • 1
  • 1
user14717
  • 4,757
  • 2
  • 44
  • 68

1 Answers1

1

Firstly, I thought you needed LD_BIND_NOW=1 (as opposed to TRUE, though that may be a synonym).

Secondly, although your application would not have linked had there been an unresolved symbol, is it possible you've done some form of shared library update so that one of the libraries used now uses a library in turn with an unresolved symbol? Or that it's using a different library to that with which it was linked?

abligh
  • 24,573
  • 4
  • 47
  • 84
  • `LD_BIND_NOW=1` is a syntax error on RHEL; it is the proper syntax on other distros. How would I determine if I've done a shared library update that causes one library to use another with an unresolved symbol? – user14717 Jan 18 '14 at 17:23
  • Try `objdump -T` on the executable (or calling library) and the called library and see if the executable does indeed reference a symbol that the library doesn't provide. – abligh Jan 18 '14 at 17:44
  • Looks like it doesn't. `objdump -T foo.exe | grep "DftiFreeDescriptor"` and `objdump -T --demangle foo.exe | grep "DftiFreeDescriptor"` comes up dry. – user14717 Jan 18 '14 at 18:01