Resolving a symbol clash with libnsl

[Shawn Betts]

I have a program that links with /lib/libnsl.1 and at runtime loads a 3rd party shared library (with shl_open). libnsl has functions MD5Init, MD5Update, and MD5Final in it. The problem is this 3rd party lib does to. When I load it and call one of it's functions that in turn calls MD5Init, the libnsl MD5Init function is called instead of the 3rd party lib's version!

How can I prevent the wrong function from being called?

[ranganath ramachandra]

try shl_load'ing with BIND_FIRST ?

[rick jones]

If the third party library is not intending for those MD5* routines to be called directly by those using the library, it should be compiled to "hide" those symbols (not export them).

Similarly with libnsl.

My suggestion would be to get in touch with the third-party library supplier and have them make that change.

Also, see if there is a latest and greatest libnsl patch for your revision of UX (should have stated that... :) and if that hasn't hidden its versions, consider opening a call with the RC.

Do take _both_ paths. It would not be good to leave one or the other of them dangling to trap someone (perhaps even yourself :) at a later time.

Or I could be all wet, being a networking rather than languages guy :)