PROBLEM:  (ULC-60, USG-04340, 50807)	(Patch ID: OSF410-400152)
********
This patch fixes a problem that may cause /sbin/loader to fail to resolve 
duplicate symbols in dlopen'ed shared libraries.  Duplicate symbols only exist 
in large multi-GOT objects. The application's dlopen call may get a 
segmentation violation and there may be no traceback information.

Application developers may consider linking their application against the 
multi-GOT shared libraries as a test for this problem.  Statically loading the 
libraries should work.

More information on multi-Got objects can be obtained from the odump man page 
and the Assembly Language Programmer's Guide.

PROBLEM:  (QAR 58033)               (Patch ID: OSF410-405211)
********
Programs linked -call_shared and linked with libc.a may fail to load.  The
loader will be in an infinite loop with no visible output. One way to determine 
if the loader is hanging as a result of the problem fixed by this patch is to 
set the _RLD_ARGS environment variable to "-debug symbol -log logfile" and see 
if the logfile shows an endless loop with entries of the following style:

   358:main: /sbin/loader: resolve_symbol: found strong symbol for
   _foo -- _foo(89307)
   358:main: /sbin/loader: resolve_symbol:  resolving _foo from libtemp.so,
   with hash value 0x5d029d6

When this problem occurs, the name of the symbol in the above log entries will 
not change.

There is no easy way to duplicate this problem.  It involves a combination of 
executables with multiple GOT entries and weak symbols.

PROBLEM:  (QAR 56896 SPR HPAQA259P) (Patch ID: OSF410-405211)
********
This fix allows the loader to report the name of unresolved symbols from
libraries which are opened with dlopen() calls.  Previously when this situation 
occurred, the loader would report the following error:

   % ./a.out
     Unable to load shared library file:
     dlopen: Unresolved symbols
     Error 0

The new loader behavior is to report the symbol name and the library name, as 
follows:

   % ./a.out
     Unable to load shared library file:
     Unresolved symbol in ./hw.so: foo
     Error 0

This problem can be reproduced by having a program use dlopen() to open a
library with unresolved symbols in it.