Spurious misguided message from GNU gold for missing symbol under 64-bit?

["ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>]

Hi list,

Can GNU Gold that is compiled and used under 64-bit
produce a spurious misguided error message instead of simply reporting that
a symbol is undefined and missing?

A case in point:

While trying to compile and link mozilla thunderbird under Debian
GNU/Linux using GCC 4.9, I encountered an error at the linking stage.
I tried first 64-bit version.

- 64-bit GNU gold complained ".../MediaDecoderReader.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv' which may 
overflow at runtime; recompile with -fPIC"

Here is the excerpt from the log:

 CI comment: /REF-OBJ-DIR/objdir-tb3 is my MOZ_OBJ,
             /REF-COMM-CENTRAL/comm-central is my MOZ_SRC tree.

/usr/bin/ld.new: error: 
/REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build/../../../content/media/MediaDecoderReader.o: 
requires dynamic R_X86_64_PC32 reloc against 
'_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv' which may 
overflow at runtime; recompile with -fPIC
/usr/bin/ld.new: error: read-only segment has dynamic relocations
/REF-COMM-CENTRAL/comm-central/mozilla/content/media/MediaData.h:86: 
error: undefined reference to 
'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
/REF-COMM-CENTRAL/comm-central/mozilla/content/media/SharedBuffer.h:68: 
error: undefined reference to 
'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
collect2: error: ld returned 1 exit status
/REF-COMM-CENTRAL/comm-central/mozilla/config/rules.mk:882: recipe for 
target 'libxul.so' failed


I was side-tracked with the "requires dynamic R_X86_64_PC32 reloc
against ..." message. I knew that linking the library with debug
symbols using traditional ld would run out of 32-bit memory space, and
was wondering if there were offset values which would not fit into
32-bit space holder.
Then it was suggested that it could be due to
name space issues. (Well, there is "undefined reference to
'mozilla::AudioQueueMemoryFunctor::MallocSizeof(void const*)'")

After scratching my head many times, I tried the
compilation and linking under 32-bit Debian GNU/Linux. Then I found
that GNU gold there complained SIMPLY  that the symbol in question is
"undefined".

- 32-bit GNU gold complained "undefined reference" only

33:33.36 /usr/bin/ld.gold: warning: hidden symbol 'pixman_add_triangles' 
in 
/new-hd1/extra/ishikawa/TB-3HG/objdir-tb3/mozilla/toolkit/library/build/../../../gfx/cairo/libpixman/src/pixman-trap.o 
is referenced by DSO 
/usr/lib/gcc/i586-linux-gnu/4.9/../../../i386-linux-gnu/libcairo.so
33:33.36 
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/content/media/MediaData.h:86: 
error: undefined reference to 
'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
33:33.36 
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/content/media/SharedBuffer.h:68: 
error: undefined reference to 
'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
33:33.36 collect2: error: ld returned 1 exit status
33:33.36 
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/config/rules.mk:882: 
recipe for target 'libxul.so' failed
33:33.36 make[5]: *** [libxul.so] Error 1

So then I was finally convinced that this is a source file issue, and
the incorrectly referenced symbol in a false namespace during
compiling is not defined at link stage. Indeed, the recent changes (in
last two months) to MediaData.h (and possibly other files as well)
referred to in the error message seem to have cured the compilation and 
linking issue. mozilla thunderbird and firefox compiles fine with GCC 
4.9 after source tree refresh a couple of days ago.

GNU gold version I used was fetched from git repository at
sourceware.org and compiled under 32-bit and 64-bit.

ld --version
GNU gold (GNU Binutils 2.24.51.20140611) 1.11
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later 
version.
This program has absolutely no warranty.

So my question again:

Can GNU gold that is compiled and used under 64-bit linux
produce a spurious misguided error message instead of simply reporting 
that a symbol is undefined and missing?
In my case, the spurious misguided error message was
"... requires dynamic R_X86_64_PC32 reloc against 
'_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv' which may 
overflow at runtime; recompile with -fPIC"

Of course, there is a chance that 64-bit GCC 4.9 was producing
something incorrect that triggered the error message from GNU gold
under 64-bit Debian GNU/linux.

But if instead of producing this "requires dynamic R_X86_64_PC32 reloc
against ..." message, GNU gold produces "undefined" error message ONLY 
under 64-bit environment, it will reduce user confusion.

The object files involved during linking and the linked library is
huge. (libxul.so measures more than 350 MiB.)  So I can't easily send
the objects, and after refreshing the source files the day before, I
am not inclined to go back and produce the old objects *if* I can help
it :-)

TIA