More information could be found in Ulrich Dreppers "ELF Symbol Versioning".įwiw, I had this problem when running check_nrpe on a system that had the zenoss monitoring system installed. 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. What does it mean in practice? Usually, exactly what is seen in this example - nothing, things just work ignoring versioning.
It's that the binary wants some versions, but the library doesn't provide any information about its versions. 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). gnu.version_r sections (or lack thereof). You can easily see it with readelf, just look at. 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). This requires that your client have gcc or ld on their production system. 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. You last option will be compiling with a library with a different minor version number, using a custom linking script:
so.n.n.n naming scheme is going to help (much - it might help if you system has been trashed.) so files (padding them with version numbers,) stems from a time when shared object libraries did not use versioned symbols.
#Updd Console Keygen install#
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.)Īdvice you get to rename the. This is one of the reasons that most distributions ship for specific linux distro numbers. 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. You can fix this by compiling with a library (headers and shared objects) that matches the shared object version shipped with your target OS. For example, if your number is 7.15.5 on the machine where you build the binary, and the number is 7.12.1 on the installation machine, ld will print the warning. The "no version information available" means that the library version number is lower on the shared object. I guess I'd like to understand what the linker is complaining about? How can I investigate the underlying cause, etc? So it's not an out of date libpam library. Update: The customer upgraded to the latest version of debian "testing" and the same error occurred. and how we could change our executables to avoid this problem? and googling the topic doesn't help much. I don't know much about the internals of the dynamic linking process. I figure that this is error comes from the dynamic linker when the system installed library is missing something our executable expects. So this is not a fatal error, it's really just a warning.
#Updd Console Keygen code#
The application runs fine and executes code from the dynamic library. authpam: /lib/libpam.so.0: no version information available (required by authpam)
On some customer systems we get the following error on stderr when the program runs. In our product we ship some linux binaries that dynamically link to system libraries like "libpam".