libmap.conf to the rescue!
Tonight I found myself tripped up by the dreaded "shared object not found" message on my FreeBSD server 'sonar'. See, I upgraded from 6.3-REL to 7.0-REL recently and in doing so, broke probably every port that had been installed prior. In this instance, my nagios plugin(s) were not working.
Here's the deal, whenever FreeBSD releases a new version they bump the library version numbers as a matter of course. So there may be little to no fundamental difference between libcrypto.so.4 libcrypto.so.5. Or maybe there is. That's why this is risky... but what have I got to lose?Cut to the chase... if ldd /path/to/binary reveals one or more libraries that aren't found, it can be time for entries in /etc/libmap.conf (instead of the safer/slower choice of rebuilding the port providing said binary).
By using `locate libssl.so` and variants I was able to see that the libraries were in fact available, only the versions had been incremented. Here are the libmap.conf entries I created.
Now my program is fixed.
root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonar/libexec/ld-elf.so.1: Shared object "libssl.so.4" not found, required by "check_smtp"
/usr/local/libexec/nagios/check_smtp: libssl.so.4 => not found (0x0) libcrypto.so.4 => not found (0x0) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x40746000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x40852000) libc.so.6 => not found (0x0) libc.so.7 => /lib/libc.so.7 (0x40956000)
libssl.so.4 libssl.so.5libcrypto.so.4 libcrypto.so.5libc.so.6 libc.so.7
root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonarSMTP OK - 0.072 sec. response time|time=0.071886s;;;0.000000
