PROBLEM:	(QAR 49301)		(Patch ID: OSF415-400174)
********
This patch fixes a problem where use of "ld -r ..." will change symbol
preemption behavior.

Without this patch, some global relocations can be converted to locals as an
optimization.  These locals cannot be preempted.

An undocumented linker option has been added in the patched linker to
prevent this conversion. This new switch is "ld -no_local_conversion ..."

PROBLEM:      (QAR 53151) 		(Patch ID: OSF415-400375)
********
At link-time the linker issues an ASSERT statement from within the module
relocate.c.  This will only be observed for very large applications that
build a final image based on previously linked  'ld -r' object files.
The error produces output messages in the following form:

assertion failed: EX at ../../../../../../src/usr/ccs/bin/ld/relocate.c line
2471

PROBLEM:    (QAR 55440) 		(Patch ID: OSF415-400375)
********
Hidden/Export Symbol wildcard problem:

A regression was introduced into the linker when -hidden symbol processing
was scaled up to use a hash table.  The wildcard capability with the
"exported_symbol" option was completely lost.  This fix makes wildcards
functional for hidden/export symbols.

An example of wildcard usage that was no longer functional is:

  ld -o libf.so -shared -all -hidden  -exported_symbol 'X500*'  file.o -lc

Any symbol beginning with X500 should be "GLOBAL" not "LOCAL".  To check if
a symbol is global use the following odump command on the library that is
produced by  the linker:

  odump -Dt libf.so

Shows the symbol being GLOBAL or LOCAL

PROBLEM:    (QAR  54224)		(Patch ID: OSF415-400375)
********
The linker was improperly rounding -T values to 64K increments even when
linking OMAGIC files, which do not have the same rounding requirements.
It turns out that the check being made in the ld.c was already being
done in layout, so all we really need to do is to remove the bogus check
in ld.c

PROBLEM:   (QAR 55693) 			(Patch ID: OSF415-400375)
********
The linker fails to link a c++ program issuing an "ld_munmap error" message.

PROBLEM:  (QAR 57068)               (Patch ID: OSF415-405212)
********
This patch fixes a problem where the linker might crash when printing out
lengthy error diagnostics.

PROBLEM:  (QAR 60767)    (Patch ID: OSF415-405266)
********
This patch is a fix for a linker bug that could cause valid conflict symbols
to not be recorded in the linked executable's conflict section.

The following conditions are necessary to reproduce the problem fixed by this
patch.

  - The application is linked -call_shared.

  - The application is large enough to require more than one Global Offset
    Table (GOT) in the executable.  Multiple GOTs occur when the number of
    referenced external symbols in the application exceeds 8190.

  - The user adds a symbol to their application which has the same name as a
    symbol in one of the shared libraries used by the application.

    For example, if a user linked their own malloc routine into an application,
    the libc malloc routine may be used instead.

    If you think you're experiencing this problem, one way to quickly verify
    it is to set the _RLD_ARGS environment variable to "-force checksum".
    Setting this will force the loader to resolve all symbols and ensure that
    the proper symbols are used.

    Another option to determine if you're experiencing this problem is to dump
    the conflict symbol table from the linked executable.  This is performed
    with "odump -Dc application_name".  If you've added a symbol to your
    application and the symbol also exists in one of the shared libraries used
    by the application, then the symbol should be listed in the conflict
    symbol table.  If it isn't, this patch may be required.