Why "symbol lookup error", "undefined symbol" when the symbol exists

Question

This was originally a PySide2 bug , but after a bit of debugging following this SO answer , I think it might be a general c++ problem, regardless what the application and the undefined symbol really is.

When I run /home/me/.local/lib/python3.8/site-packages/PySide2/designer and close it, it crashes with

/home/me/.local/lib/python3.8/site-packages/PySide2/designer:
  symbol lookup error: /home/me/.local/lib/python3.8/site-packages/PySide2/designer:
  undefined symbol: _ZdlPvm, version Qt_5

But this should not have happened. First, the system libstdc++ is indeed loaded:

$ LD_DEBUG=libs pyside2-designer 2>&1 |grep libstdc++
   1926528: find library=libstdc++.so.6 [0]; searching
   1926528:   trying file=/home/me/.local/lib/python3.8/site-packages/shiboken2/libstdc++.so.6
   1926528:   trying file=/usr/lib/libstdc++.so.6
   1926528: calling init: /usr/lib/libstdc++.so.6
   1926533: find library=libstdc++.so.6 [0]; searching
   1926533:   trying file=/usr/lib/libstdc++.so.6
   1926533: calling init: /usr/lib/libstdc++.so.6
   1926528: calling fini: /usr/lib/libstdc++.so.6 [0]

Second, the symbol "_ZdlPvm" is indeed defined in /usr/lib/libstdc++.so.6 :

$ nm -D /usr/lib/libstdc++.so.6 |grep _ZdlPvm
00000000000a1ca0 T _ZdlPvm
00000000000a3c30 T _ZdlPvmSt11align_val_t

unless these two facts do not guarantee that the symbol _ZdlPvm is found and used, then I wonder how it can be guaranteed and how dynamic loading really works.

Thanks in advance.

Answer 1

The full error message is

{...}/lib/python3.6/site-packages/PySide2/designer: relocation error: 
     {...}/lib/python3.6/site-packages/PySide2/designer: symbol 
     _ZdlPvm version Qt_5 not defined in file libQt5Core.so.5 with
      link time reference

Your package is linked against its own local copy of Qt libraries, however you are not using those (you have not added relevant directories to your LD_LIBRARY_PATH ). Let's see:

$ nm -D {...}/lib/python3.6/site-packages/PySide2/Qt/lib/libQt5Core.so.5 | grep _ZdlPvm
00000000003b95e0 T _ZdlPvm

$ nm -D /usr/lib64/libQt5Core.so.5 | grep _ZdlPvm
                 U _ZdlPvm

Why does it care where _ZdlPvm is defined? Well, because there's more to the symbol than just the name. There is also symbol version. See this little version Qt_5 part of the message?

$ nm --with-symbol-versions -D /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libstdc++.so.6 | grep _ZdlPvm
00000000000d0060 T _ZdlPvm@@CXXABI_1.3.9
00000000000d1ed0 T _ZdlPvmSt11align_val_t@@CXXABI_1.3.11

$ nm --with-symbol-versions -D {...}/lib/python3.6/site-packages/PySide2/Qt/lib/libQt5Core.so.5 | grep _ZdlPvm
00000000003b95e0 T _ZdlPvm@@Qt_5

So the symbol your local libQt5Core.so.5 defines is actually different from what libstdc++.so.6 defines.

I tried to add the local copy of Qt to LD_LIBRARY_PATH , but the result was that it was not able to find Kerberos libraries. My system does not use Kerberos so they are not present. If you use a standard Linux distro like Ubuntu, you may have better luck.

To summarize, there is a bug in the package. If it needs to use its own copy of Qt, it should have come up with a way to actually use it out of the box, without the user having to jump through hoops. It is not a problem of C++ or any other language. It is a manifestation of a much more general problem, known as "DLL Hell".