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

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

Hi,

(2014/06/19 6:09), Cary Coutant wrote:
> > 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?
>
> I think the "requires dynamic reloc" message is probably not spurious
> or misleading, and probably does point to some problem in the build
> process. Without any object files to look at, the best I can tell you
> is that you'll get this message for an R_X86_64_PC32 relocation under
> one of the following conditions:

I was linking libxul.so dynamic library that is used by mozilla thunderbird.

> (1) You're linking with -shared, but did not compile with -fpic.
>
> (2) You're linking an executable, but the symbol is defined in a
> shared library, and you've disabled copy relocations (-z nocopyreloc).
>
> (There may be other possibilities, but they seem unlikely at the moment.)
>
> It does later print an undefined reference error message, so that
> should rule out the second condition.
>
> What's the complete set of linker flags? Can you at least provide a
> copy of MediaDecoderReader.o?

Here is the linker flags:
Jun 15 02:36:05 vm-debian-amd64 ishikawa: my version of non-stripped 
ld.gold called with: 
PWD=/REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build
arguments:
-plugin /usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so 
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper 
-plugin-opt=-fresolution=/COMM-CENTRAL/TMP-DIR/ccLP3J0H.res 
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread 
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s 
--sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu 
-shared -o libxul.so 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o -L../../../dist/bin 
-L../../../dist/lib -L../../../dist/bin -L../../../dist/lib 
-L../../../dist/bin -L../../../dist/lib -L../../../dist/bin 
-L../../../dist/lib -L/REF-OBJ-DIR/objdir-tb3/mozilla/dist/lib 
-L/usr/lib/gcc/x86_64-linux-gnu/4.9 
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib 
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. 
--gdb-index -z defs -h libxul.so -lpthread -z noexecstack -z text 
--build-id -rpath-link /REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin 
-rpath-link /usr/local/lib 
/REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build/tmpqJ5Xfx.list 
../../../xpcom/typelib/xpt/src/libxpt.a 
../../../intl/unicharutil/util/internal/libintl_unicharutil_util_internal.a 
-version-script symverscript ../../../dist/lib/libjs_static.a -lcrmf 
-lsmime3 -lssl3 -lnss3 -lnssutil3 -lXrender -lldap60 -lprldap60 -lldif60 
../../../dist/lib/libmozsqlite3.so -lasound -lnspr4 -lplc4 -lplds4 
../../../dist/lib/libmozalloc.so -ldbus-glib-1 -ldbus-1 -lgobject-2.0 
-lglib-2.0 -lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfontconfig 
-lfreetype -lgdk-x11-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo 
-lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lX11 -lXext -lpangoft2-1.0 
-lfontconfig -lfreetype -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 
-lglib-2.0 -lcairo -lXt -lgthread-2.0 -lfreetype -lfontconfig -lfreetype 
-ldl -lrt -lstdc++ -lm -lgcc_s -lpthread -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o

I see "-z" options: "-z defs -h libxul.so -lpthread -z noexecstack -z text"

I think object files are listed in
/REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build/tmpqJ5Xfx.list
using INPUT("... path to object file" );
syntax.

I will see what I can to produce the buggy
MediaDecoderReader.o in the previous version of the source.
(Mozilla uses hg for version control, and I am using its "patch queue" 
feature for local modification, and I am not at all sure how the latest 
"patch queue" can cope with going backward with the official tree 
version. Aha, I see, I would simply compile WITHOUT applying my local 
patches. Should be easy. I will hopefully post the object tonight (JST).

> > 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".
>
> When linking for the 32-bit ABI, gold does not print the warning about
> a dynamic relocation because (a) dynamic relocations in the text
> segment are allowed in 32-bit mode, and (b) a 32-bit pc-relative
> relocation can reach the entire address space.

Regarding (a), under 64-bit, I noticed the error message line:

/usr/bin/ld.new: error: read-only segment has dynamic relocations

'text' is probably read-only and so dynamic relocations are not allowed 
there under 64-bit.

"(b)" is what I thought was the difference under 64-bit pc-relative 
32-bit can jump only +/- 2GB, and
I was led to investigate if the library mapped in the address space 
could become so huge.

I will try to re-create the MediaDecoderReader.o

TIA

> -cary