Hi Donn,
Thanks for your response. Due to the separation of responsibilities it is very important to have no compile time dependency. Introducing the argument "-rpath ...." at link time is not a general enough solution. Do you feel that placing the Kerberos libraries is a system standard location with fix this error? BTW - I did not mention that the program still seems to run fine. Thanks, jonw -----Original Message----- From: Donn Cave [mailto:[EMAIL PROTECTED]] Sent: Friday, January 18, 2002 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Unresolved symbol _et_list for OSF4.0f (dynamic lib) Not really, but you might try linking the application - the one that calls dlopen() - with "-rpath /kerberos/tru64_new/lib". I've done that on Digital UNIX 4.0 to solve a run time loading problem with Kerberos libraries in a non-standard directory. I don't recall the error. My problem was that the dlopen() was called from another shared library (a Python module), and the normal library load path rules didn't work by extension in this case, perhaps for security reasons. (Since then I have seen the light, Kerberos libraries are static.) Donn Cave, [EMAIL PROTECTED]
