libcrypto.so.1.0.0: (required - What does the “no version information available” error from linux dynamic linker mean?
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_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 — 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".
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?
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.