Rolling Resource

I have downloaded and installed GnuPG, but whenever I try to retrieve a public key from a keyserver, it logs the error
gpgkeys_hkp: error while loading shared libraries: libcurl.so.3: cannot open shared object file: No such file or directory

This is despite the fact that libcurl.so.3 is on my system
$ find / -name libcurl.so* 2>/dev/null
/usr/local/lib/libcurl.so
/usr/local/lib/libcurl.so.3
/usr/local/lib/libcurl.so.3.0.0
/usr/local/phplibs/lib/libcurl.so
/usr/local/phplibs/lib/libcurl.so.3
/usr/local/phplibs/lib/libcurl.so.3.0.0
/usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs/libcurl.so.4.0.0
/usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs/libcurl.so.4
/usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs/libcurl.so
/usr/mylocal/lib/libcurl.so.4.0.0
/usr/mylocal/lib/libcurl.so.4
/usr/mylocal/lib/libcurl.so
/ftp/usr/lib/libcurl.so
/ftp/usr/lib/libcurl.so.1
/ftp/usr/lib/libcurl.so.1.1.0
/ftp/usr/lib/libcurl.so.2

In fact it appears twice, once in /usr/local/lib and again in /usr/local/phplibs/lib.  So what is going on?  It would appear that while my system can locate the file in order to build it into the executable, it cannot locate the library at run time (when I run gpg); no errors were logged when I configured and made GnuPG. There is a useful article (here) by David Wheeler which explains how libraries work. It explains the difference between soname, realname and linker name and how the various links are created as part of the build process. It goes on to explain that when you install a new version of a library, you install it in one of a few special directories and then run the program ldconfig(8) in order to update the file /etc/ld.so.cache. These special directories are defined in /etc/ld.so.conf
When we look at ld.so.conf, it has two lines

[mylogin][~]$ cat /etc/ld.so.conf
/usr/local/lib
/lib

so the system should find the link in /usr/local/lib. (/lib is actually a symbolic link to /ftp/usr/lib) However, when I checked the cache, the file is missing

[mylogin][~]$ ldconfig -p | grep libcurl
libcurl.so.2 (libc6) => /lib/libcurl.so.2
libcurl.so.1 (libc6) => /lib/libcurl.so.1
libcurl.so (libc6) => /lib/libcurl.so

It appears that the script which installed php did not run the ldconfig utility to update the cache. This was resolved by running ldconfig manually.

[mylogin][~]$ ldconfig -v

My system has library files for libcurl in
/usr/local/lib
/usr/local/phplibs/lib
/ftp/usr/lib
and the version I built myself in /usr/home/mylogin/apps/bld/curl-7.16.0/lib/.libs and /usr/mylocal/lib

so the cache now has the following entries
[mylogin][~/apps/dl]$ ldconfig -p | grep libcurl
libcurl.so.4 (libc6) => /usr/mylocal/lib/libcurl.so.4
libcurl.so.3.0.0 (libc6) => /usr/local/lib/libcurl.so.3.0.0
libcurl.so.3 (libc6) => /usr/local/lib/libcurl.so.3
libcurl.so.2 (libc6) => /lib/libcurl.so.2
libcurl.so.1 (libc6) => /lib/libcurl.so.1
libcurl.so (libc6) => /lib/libcurl.so
libcurl.so (libc6) => /usr/mylocal/lib/libcurl.so
libcurl.so (libc6) => /usr/local/lib/libcurl.so

Note that the files from phplibs are not included directly (the libraries in /usr/local/bin are actually symlinks to phplibs) and that there are entries for /lib (which is itself a symlink to /ftp/usr/lib). I also edited /etc/ld.so.conf to include the directroy /usr/mylocal/lib.