This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


(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 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 called with: PWD=/REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build
-plugin /usr/lib/gcc/x86_64-linux-gnu/4.9/ -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 /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 -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/ -lasound -lnspr4 -lplc4 -lplds4 ../../../dist/lib/ -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 -lpthread -z noexecstack -z text"

I think object files are listed in
using INPUT("... path to object file" );

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

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/ 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]