Here's an interesting one... I've just been doing some work on adding PAM support into the "jabber" IM server and ran into an interesting problem. With Jabber, the authentication is itself done in a plug-in module called "jsm.so", which is loaded by the main process, "jabberd". This causes a problem with PAM, because many of the PAM modules make calls into "libpam.so", but *none* of them specifically link it in. Instead they assume that the main application (in this case "jabberd") has had "libpam" linked into it and that they will have access to its symbols that way. This means that although "jabberd" makes absolutely no PAM calls what so ever, I have to link "libpam" into it, in order to make it available to the PAM plug-in modules. Without "libpam" linked into "jabberd", "dlopen" in "libpam/pam_handlers.c" will return NULL and a subsequent call to "dlerror()" will return something like "pam_unix: pam_get_user: symbol not found". To solve this problem I can simply link "libpam" into "jabberd". However, in the situation where I had access to the source code for "jsm.so", but didn't have the source code to "jabberd" this wouldn't be possible. So, I believe that "libpam" should be linked into every modules that wants to make calls into it. I believe a similar problem would arise with Apache as it also does its authentication in a plug-in module. It would have really helped me track this problem if there had been a call to "dlerror()" if "dlopen()" fails, even if only in debug mode. James