What does the no version information available error from linux dynamic linker mean

Question

In our product we ship some linux binaries that dynamically link to system libraries like  libpam    On some customer systems we get the following error on stderr when the program runs     authpam   lib libpam so 0  no version information available  required by authpam    The application runs fine and executes code from the dynamic library   So this is not a fatal error  it s really just a warning   I figure that this is error comes from the dynamic linker when the system installed library is missing something our executable expects   I don t know much about the internals of the dynamic linking process     and googling the topic doesn t help much      Anyone know what causes this error       how I can diagnose the cause       and how we could change our executables to avoid this problem   Update  The customer upgraded to the latest version of debian  testing  and the same error occurred  So it s not an out of date libpam library   I guess I d like to understand what the linker is complaining about   How can I investigate the underlying cause  etc

User · Answer

Have you seen this already  The cause seems to be a very old libpam on one of the sides  probably on that customer   Or the links for the version might be missing   http   www linux org docs ldp howto Program-Library-HOWTO shared-libraries html

User · Answer

Fwiw  I had this problem when running check nrpe on a system that had the zenoss monitoring system installed   To add to the confusion  it worked fine as root user but not as zenoss user   I found out that the zenoss user had an LD LIBRARY PATH that caused it to use zenoss libraries  which issue these warnings  Ie   root monitoring   echo  LD LIBRARY PATH  su - zenoss zenoss monitoring  root  echo  LD LIBRARY PATH  usr local zenoss python lib  usr local zenoss mysql lib  usr local zenoss zenoss lib  usr local zenoss common lib   zenoss monitoring  root   usr lib nagios plugins check nrpe -H 192 168 61 61 -p 6969 -c check mq  usr lib nagios plugins check nrpe   usr local zenoss common lib libcrypto so 0 9 8  no version information available  required by  usr lib libssl so 0 9 8        zenoss monitoring  root  LD LIBRARY PATH   usr lib nagios plugins check nrpe -H 192 168 61 61 -p 6969 -c check mq         So anyway  what I m trying to say  check your variables like LD LIBRARY PATH  LD PRELOAD etc as well

User · Answer

What this message from the glibc dynamic linker actually means is that the library mentioned   lib libpam so 0 in your case  doesn t have the VERDEF ELF section while the binary  authpam in your case  has some version definitions in VERNEED section for this library  presumably  libpam so 0   You can easily see it with readelf  just look at  gnu version d and  gnu version r sections  or lack thereof    So it s not a symbol version mismatch  because if the binary wanted to get some specific version via VERNEED and the library didn t provide it in its actual VERDEF  that would be a hard linker error and the binary wouldn t run at all  like this compared to this or that   It s that the binary wants some versions  but the library doesn t provide any information about its versions   What does it mean in practice  Usually  exactly what is seen in this example  mdash  nothing  things just work ignoring versioning  Could things break  Of course  yes  so the other answers are correct in the fact that one should use the same libraries at runtime as the ones the binary was linked to at build time   More information could be found in Ulrich Dreppers  ELF Symbol Versioning

User · Answer

How are you compiling your app  What compiler flags   In my experience  when targeting the vast realm of Linux systems out there  build your packages on the oldest version you are willing to support  and because more systems tend to be backwards compatible  your app will continue to work  Actually this is the whole reason for library versioning - ensuring backward compatibility

User · Answer

The  no version information available  means that the library version number is lower on the shared object   For example  if your major minor patch number is 7 15 5 on the machine where you build the binary  and the major minor patch number is 7 12 1 on the installation machine  ld will print the warning   You can fix this by compiling with a library  headers and shared objects  that matches the shared object version shipped with your target OS   E g   if you are going to install to RedHat 3 4 6-9 you don t want to compile on Debian 4 1 1-21   This is one of the reasons that most distributions ship for specific linux distro numbers   Otherwise  you can statically link   However  you don t want to do this with something like PAM  so you want to actually install a development environment that matches your client s production environment  or at least install and link against the correct library versions    Advice you get to rename the  so files  padding them with version numbers   stems from a time when shared object libraries did not use versioned symbols   So don t expect that playing with the  so n n n naming scheme is going to help  much - it might help if you system has been trashed    You last option will be compiling with a library with a different minor version number  using a custom linking script  http   www redhat com docs manuals enterprise RHEL-4-Manual gnu-linker scripts html  To do this  you ll need to write a custom script  and you ll need a custom installer that runs ld against your client s shared objects  using the custom script   This requires that your client have gcc or ld on their production system

[linux] What does the "no version information available" error from linux dynamic linker mean?

Examples related to linux

Examples related to linker