PROBLEM: (81960) (PATCH ID: OSF510-022)
********
When trying to spike a kernel, for instance with a line such as this:
spike -kernel vmunix.orig -o vmunix.tmphaha

the following error message is given:

? FATAL ERROR
? Assertion failed.
? ../../../../../../src/usr/ccs/bin/spike/rawrel.unix.cxx, line 2755
NO STACKTRACE  no executable specified
Floating exception (core dumped)


PROBLEM: (78237) (PATCH ID: OSF510-153)
********
This problem occurs if a program references the linker defined symbol
_fpdata and the linker does not use this symbol.  A case where this
might be seen is the case of a program in which no exception handling
is being used.
An executable with this problem would not get any errors linking, but
if you did the following command on the executable:

   nm -xv myprog.exe | grep fpdata

you would get the following output:

   _fpdata                | 0x00000000000000 | U | 0x00000000000000

Also, doing this:

   odump -jf myprog.exe | grep -i null

you would see a line such as the following (with a different address):

   0x120006f28     REFQUAD <null>

After the patch, you will not see the null using the odump command,
and using the nm command you will get something like this:

   _fpdata                | 0x00000000000000 | A | 0x00000000000008

If the linker makes use of the _fpdata symbol, then this problem does
not arise.


PROBLEM: (83306) (PATCH ID: OSF510-108)
********
Using the -A switch with the linker (ld) produces link errors such as:
ld:
Object file format error in: main: Unrecognized tag (0xf) in .comment section.


PROBLEM: (82808) (PATCH ID: OSF510-120)
********
  This patch modifies the linker's symbol resolution to enable it
  to recognize when a reference to a symbol defined in a shared
  library is replaced by a symbol defined in an object file or
  archive.  Previously, the linker failed to handle this replacement
  consistently when a symbol was defined by both a shared library
  and an object or archive that followed it on the linker command
  line.  This would frequently lead to failed links reporting "multiply
  defined symbol" errors.
  This patch also modifies the linker to cause it to rescan shared
  libraries before reporting unresolved symbols.  Symbols are sometimes
  added to the linker's list of unresolved symbols because the
  references to those symbols appear in object files or archives that
  are linked in after the shared libraries in which the symbols are defined.
  This final scan allows all symbol definitions to be recognized, and
  no symbols are misreported as being unresolved.

  In the following example, if the symbol "a" is defined in b.so and c.o
  and referenced in a.o, then without this patch, the linker behavior
  would be:
     
      cc a.o b.so c.o -rpath .
      ld:
      c.o: a: multiply defined

  With this patch, the linker will successfully perform the link using
  the definition of the symbol "a" from c.o.

  Using the following example for the second problem described, if the symbol
  "a" were defined in b.so and referenced from c.o, the linker would report
  an unresolved symbol error.

    ld -call_shared /usr/lib/cmplrs/cc/crt0.o a.o b.so -lc c.o
    ld:
    Unresolved:
    a
  
  With this patch, the linker will successfully perform the link.


PROBLEM: (77290, 78669, |) (PATCH ID: OSF510-102)
********
|PROBLEM:
Using the -f switch with the linker (ld) produces link errors such as:
ld:
/usr/.../libc.a(file.o):
      write_outbuf: Not enuf room in bfr f_outbuf? nbytes(1264) > left(0)
|PROBLEM:
Any switch that begins with -f and is not a legal switch to the linker
gets interpreted to mean -f.  For example '-funfun' is taken to mean -f.