HP run-time linker problems

[Paresh Borkar]

Problem Description:

We have a 32-bit application, which dlopens a shared library. This shared library depends on a third party library, LDAP SDK 4.1 version (libldapssl41.sl). Also, this main application is statically linked with libsslc.a (a thrid party RSA SSL library). When we tried to run this application, it crashed in 'memcpy' called from 'SHA1_Update' function, in turn called from an ldap function.

We know that, this libldapssl41.sl is a self contained library. However using gdb, we have observed that this 'SHA1_Update' from the executable (i.e. from the libssl.a linked in to the executable) was getting called, from a function in libldapssl41.sl. This should not happen as libldapssl41.sl is self-contained library. The problem seems to be related to
symbol scoping conflict between the main application and this dependent ldapssl41 library.

We have tried following options:

When building the main application, we hide this symbol. This helped us bypass the symbol conflict, but our application crashes in another function viz., ldap_simple_bind_s, which belongs to libldapssl41.sl. This time, the call stack does not display the name of the final function being called. The disassembly of this last function shows it to be "$$dyncall_external".

We also tried to hide all symbols from our static library(libsslc.a) while building our application. But the linker gives warning saying that 'some symbols can not be hidden as they are not used in the application'. However in dependent library there are symbols with the same names as these. We can not change names of these symbols etc., as both of them are third party libraries.

It appears that when a library is dlopened with RTLD_LOCAL flag, all its dependent libraries are loaded at a global scope.

Any help on this would be greatly appreciated.

Additional Patches Info:

Installed patch [PHSS_23440 ld(1) and linker tools cumulative patch] which supports loading a module using 32-bit dlopen call in local scope, which is required for our application.

[Kevin O'Donovan]

It sounds like you know more about this than I do, but wouldn't I be correct in saying that the call to the function in the .sl should be 'bound' to where it is in the .sl file at build time? Does it builds without any unresolved symbols?

Maybe the easiest way to get around this would be to rename your SHA1_update function in either the library or the executable, so you don't have a name conflict?

[Steven Gillard_2]

Hmmm thats a nasty. I'm sure its not *supposed* to work that way, so if I've understood it correctly you may have hit a bug in dynamic loader.

Here's a few things that I would try in the same situation:

- double check that the SHA1_Update function actually appears in libldapssl41.sl (use nm to dump the symbol table), just to make sure you don't have a buggy libldapssl41.sl.

- install the latest ld patch. I've got PHSS_24303 on my system which I think is the latest but check for updates. There are loads of fixes listed in this patch (in fact I think I remember PHSS_23440 being marked bad?)

- try immediate binding as a workaround (chatr -B immediate ). This causes all symbol names to be resolved on startup. I'm not sure whether this will have an impact on a library you open yourself with dlopen(). You might want to try using RTLD_NOW in the dlopen call.

- log a call with HP. Their languages expert centre is best equipped to deal with this type of issue (you have to go through the response centre to get to them). They may want an example, so be prepared to get asked for a test case. I hope you have a support contract! :)

Good luck!

Cheers,
Steve