Comment # 7 on bug 955832 from Michael Matz

It's noticable that all other relocs in .toc are either to local symbols,
or if they are to global syms, it's always with a positive addend and data
symbols (vtables), or to function symbols with a zero addend.  Only the
reference to 'rand' comes with a -1, i.e. negative addend.

Sure enough, boost contains this crap:

# 70 "/usr/include/boost/uuid/seed_rng.hpp" 3 4
...
    void sha1_random_digest_()
    {
...
            sha.process_bytes( (unsigned char const*)&std::rand, sizeof(
void(*)() ) );
...

So it wants to inspect the first couple bytes (here eight) of the std::rand
function to seed some rng.  Due to the implementation of process_bytes and
inlining happening it seems that one of the loops therein uses &rand-1 as
some boundary, compiling ws-relatedmultipart.cxx with -O0 makes that reloc
come out as 'rand + 0' and the link will succeed (but using -O0 disabled
FORTIFY_SOURCE).

Commenting out this line in /usr/include/boost/uuid/seed_rng.hpp also
makes this work.  Unfortunately a smaller self-contained testcase
doesn't trigger the problem in binutils, even though it also contains
an 'rand - 1' relocation, so that alone doesn't seem to be the problem.
The smaller testcase (which doesn't fail) is:

------------------------------------------------
#include <stdlib.h>
#include <stdio.h>

int main()
{
  int sum = 0;
  const char *p = (const char*)&rand;
  const char *end = p + sizeof (void (*) ());
  for (; p != end; ++p)
    sum += *p;
  printf ("%d\n", sum);
  return 0;
}
------------------------------------------------

Compiling this with -O2 (either with gcc or g++) produces a 'rand - 1'
relocation, but binutils happily links it nevertheless.

Possibly it requires something more to trigger the problem in binutils,
like a large .toc or so.