PROBLEM:  (ULC-60, USG-04340, 50807) (Patch ID: OSF415-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: OSF415-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: OSF415-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.