PROBLEM:  (QAR 49301)	(Patch ID: OSF410-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: OSF410-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: OSF410-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: OSF410-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: OSF410-400375)
********
The linker fails to link a c^^ program issuing an "ld_munmap error" message.

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

PROBLEM:  (QAR 60767)    (Patch ID: OSF410-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.