[PATCH] ld arm config update for FreeBSD

[PATCH] ld arm config update for FreeBSD

[Andreas Tobler]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

Hello all,

this patch updates the arm*-*-freebsd* target for ld.

On one side I open the triple to allow more than only arm-*-freebsd and
on the other side I add with this patch the big endian target for
arm*b-*-freebsd*.

Ok for trunk?

Thanks,
Andreas

2014-06-17  Andreas Tobler  <andreast@fgznet.ch>

	* configure.tgt (arm*-*-freebsd*): Update targ_extra_emuls.
	(arm*b-*-freebsd*): Add target.
	* emulparams/armelfb_fbsd.sh: Added.
	* emulparams/armelf_fbsd.sh: Updated.
	* Makefile.am (ALL_EMULATION_SOURCES): Add earmelfb_fbsd.c.
	* Makefile.in: Regenerate.


[-- Attachment #2: arm_ld_fbsd.diff --]
[-- Type: text/plain, Size: 3667 bytes --]

diff --git a/ld/Makefile.am b/ld/Makefile.am
index a22006c..c537fa7 100644
--- a/ld/Makefile.am
+++ b/ld/Makefile.am
@@ -167,6 +167,7 @@ ALL_EMULATION_SOURCES = \
 	earmelf_nbsd.c \
 	earmelf_vxworks.c \
 	earmelfb.c \
+	earmelfb_fbsd.c \
 	earmelfb_linux.c \
 	earmelfb_linux_eabi.c \
 	earmelfb_nacl.c \
@@ -732,6 +733,11 @@ earmelfb.c: $(srcdir)/emulparams/armelfb.sh $(srcdir)/emulparams/armelf.sh \
   $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
   $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
 
+earmelfb_fbsd.c: $(srcdir)/emulparams/armelfb_fbsd.sh \
+  $(srcdir)/emulparams/armelf_fbsd.sh \
+  $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
+  $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
+
 earmelfb_linux.c: $(srcdir)/emulparams/armelfb_linux.sh \
   $(srcdir)/emulparams/armelf_linux.sh \
   $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
diff --git a/ld/Makefile.in b/ld/Makefile.in
index 1c43066..370a5a5 100644
--- a/ld/Makefile.in
+++ b/ld/Makefile.in
@@ -474,6 +474,7 @@ ALL_EMULATION_SOURCES = \
 	earmelf_nbsd.c \
 	earmelf_vxworks.c \
 	earmelfb.c \
+	earmelfb_fbsd.c \
 	earmelfb_linux.c \
 	earmelfb_linux_eabi.c \
 	earmelfb_nacl.c \
@@ -1065,6 +1066,7 @@ distclean-compile:
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelf_nbsd.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelf_vxworks.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb.Po@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_fbsd.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_linux.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_linux_eabi.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_nacl.Po@am__quote@
@@ -2170,6 +2172,11 @@ earmelfb.c: $(srcdir)/emulparams/armelfb.sh $(srcdir)/emulparams/armelf.sh \
   $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
   $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
 
+earmelfb_fbsd.c: $(srcdir)/emulparams/armelfb_fbsd.sh \
+  $(srcdir)/emulparams/armelf_fbsd.sh \
+  $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
+  $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
+
 earmelfb_linux.c: $(srcdir)/emulparams/armelfb_linux.sh \
   $(srcdir)/emulparams/armelf_linux.sh \
   $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
diff --git a/ld/configure.tgt b/ld/configure.tgt
index 0eb743d..a230207 100644
--- a/ld/configure.tgt
+++ b/ld/configure.tgt
@@ -81,9 +81,11 @@ arm-*-pe)		targ_emul=armpe ; targ_extra_ofiles="deffilep.o pe-dll.o" ;;
 arm-*-aout | armel-*-aout) targ_emul=armaoutl ;;
 armeb-*-aout)		targ_emul=armaoutb ;;
 arm-*-coff)		targ_emul=armcoff ;;
-arm-*-freebsd* | arm-*-kfreebsd*-gnu)
+arm*b-*-freebsd*)	targ_emul=armelfb_fbsd
+			targ_extra_emuls="armelf_fbsd armelf" ;;
+arm*-*-freebsd* | arm-*-kfreebsd*-gnu)
 	       		targ_emul=armelf_fbsd
-			targ_extra_emuls="armelf" ;;
+			targ_extra_emuls="armelfb_fbsd armelf" ;;
 armeb-*-netbsdelf*)	targ_emul=armelfb_nbsd;
 			targ_extra_emuls="armelf_nbsd armelf armnbsd" ;;
 arm-*-netbsdelf*)	targ_emul=armelf_nbsd;
diff --git a/ld/emulparams/armelf_fbsd.sh b/ld/emulparams/armelf_fbsd.sh
index ee9520d..5b3ccc6 100644
--- a/ld/emulparams/armelf_fbsd.sh
+++ b/ld/emulparams/armelf_fbsd.sh
@@ -1,3 +1,8 @@
 . ${srcdir}/emulparams/armelf.sh
 . ${srcdir}/emulparams/elf_fbsd.sh
 TARGET2_TYPE=got-rel
+MAXPAGESIZE="CONSTANT (MAXPAGESIZE)"
+GENERATE_PIE_SCRIPT=yes
+
+unset STACK_ADDR
+unset EMBEDDED
diff --git a/ld/emulparams/armelfb_fbsd.sh b/ld/emulparams/armelfb_fbsd.sh
new file mode 100644
index 0000000..a28b476
--- /dev/null
+++ b/ld/emulparams/armelfb_fbsd.sh
@@ -0,0 +1,2 @@
+. ${srcdir}/emulparams/armelf_fbsd.sh
+OUTPUT_FORMAT="elf32-bigarm"

Re: [PATCH] ld arm config update for FreeBSD

[Richard Earnshaw]

On 17/06/14 21:33, Andreas Tobler wrote:
> Hello all,
> 
> this patch updates the arm*-*-freebsd* target for ld.
> 
> On one side I open the triple to allow more than only arm-*-freebsd and
> on the other side I add with this patch the big endian target for
> arm*b-*-freebsd*.
> 
> Ok for trunk?
> 

OK.

R.

> Thanks,
> Andreas
> 
> 2014-06-17  Andreas Tobler  <andreast@fgznet.ch>
> 
> 	* configure.tgt (arm*-*-freebsd*): Update targ_extra_emuls.
> 	(arm*b-*-freebsd*): Add target.
> 	* emulparams/armelfb_fbsd.sh: Added.
> 	* emulparams/armelf_fbsd.sh: Updated.
> 	* Makefile.am (ALL_EMULATION_SOURCES): Add earmelfb_fbsd.c.
> 	* Makefile.in: Regenerate.
> 
> 
> arm_ld_fbsd.diff
> 
> 
> diff --git a/ld/Makefile.am b/ld/Makefile.am
> index a22006c..c537fa7 100644
> --- a/ld/Makefile.am
> +++ b/ld/Makefile.am
> @@ -167,6 +167,7 @@ ALL_EMULATION_SOURCES = \
>  	earmelf_nbsd.c \
>  	earmelf_vxworks.c \
>  	earmelfb.c \
> +	earmelfb_fbsd.c \
>  	earmelfb_linux.c \
>  	earmelfb_linux_eabi.c \
>  	earmelfb_nacl.c \
> @@ -732,6 +733,11 @@ earmelfb.c: $(srcdir)/emulparams/armelfb.sh $(srcdir)/emulparams/armelf.sh \
>    $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
>    $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
>  
> +earmelfb_fbsd.c: $(srcdir)/emulparams/armelfb_fbsd.sh \
> +  $(srcdir)/emulparams/armelf_fbsd.sh \
> +  $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
> +  $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
> +
>  earmelfb_linux.c: $(srcdir)/emulparams/armelfb_linux.sh \
>    $(srcdir)/emulparams/armelf_linux.sh \
>    $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
> diff --git a/ld/Makefile.in b/ld/Makefile.in
> index 1c43066..370a5a5 100644
> --- a/ld/Makefile.in
> +++ b/ld/Makefile.in
> @@ -474,6 +474,7 @@ ALL_EMULATION_SOURCES = \
>  	earmelf_nbsd.c \
>  	earmelf_vxworks.c \
>  	earmelfb.c \
> +	earmelfb_fbsd.c \
>  	earmelfb_linux.c \
>  	earmelfb_linux_eabi.c \
>  	earmelfb_nacl.c \
> @@ -1065,6 +1066,7 @@ distclean-compile:
>  @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelf_nbsd.Po@am__quote@
>  @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelf_vxworks.Po@am__quote@
>  @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb.Po@am__quote@
> +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_fbsd.Po@am__quote@
>  @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_linux.Po@am__quote@
>  @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_linux_eabi.Po@am__quote@
>  @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_nacl.Po@am__quote@
> @@ -2170,6 +2172,11 @@ earmelfb.c: $(srcdir)/emulparams/armelfb.sh $(srcdir)/emulparams/armelf.sh \
>    $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
>    $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
>  
> +earmelfb_fbsd.c: $(srcdir)/emulparams/armelfb_fbsd.sh \
> +  $(srcdir)/emulparams/armelf_fbsd.sh \
> +  $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
> +  $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
> +
>  earmelfb_linux.c: $(srcdir)/emulparams/armelfb_linux.sh \
>    $(srcdir)/emulparams/armelf_linux.sh \
>    $(ELF_DEPS) $(srcdir)/emultempl/armelf.em \
> diff --git a/ld/configure.tgt b/ld/configure.tgt
> index 0eb743d..a230207 100644
> --- a/ld/configure.tgt
> +++ b/ld/configure.tgt
> @@ -81,9 +81,11 @@ arm-*-pe)		targ_emul=armpe ; targ_extra_ofiles="deffilep.o pe-dll.o" ;;
>  arm-*-aout | armel-*-aout) targ_emul=armaoutl ;;
>  armeb-*-aout)		targ_emul=armaoutb ;;
>  arm-*-coff)		targ_emul=armcoff ;;
> -arm-*-freebsd* | arm-*-kfreebsd*-gnu)
> +arm*b-*-freebsd*)	targ_emul=armelfb_fbsd
> +			targ_extra_emuls="armelf_fbsd armelf" ;;
> +arm*-*-freebsd* | arm-*-kfreebsd*-gnu)
>  	       		targ_emul=armelf_fbsd
> -			targ_extra_emuls="armelf" ;;
> +			targ_extra_emuls="armelfb_fbsd armelf" ;;
>  armeb-*-netbsdelf*)	targ_emul=armelfb_nbsd;
>  			targ_extra_emuls="armelf_nbsd armelf armnbsd" ;;
>  arm-*-netbsdelf*)	targ_emul=armelf_nbsd;
> diff --git a/ld/emulparams/armelf_fbsd.sh b/ld/emulparams/armelf_fbsd.sh
> index ee9520d..5b3ccc6 100644
> --- a/ld/emulparams/armelf_fbsd.sh
> +++ b/ld/emulparams/armelf_fbsd.sh
> @@ -1,3 +1,8 @@
>  . ${srcdir}/emulparams/armelf.sh
>  . ${srcdir}/emulparams/elf_fbsd.sh
>  TARGET2_TYPE=got-rel
> +MAXPAGESIZE="CONSTANT (MAXPAGESIZE)"
> +GENERATE_PIE_SCRIPT=yes
> +
> +unset STACK_ADDR
> +unset EMBEDDED
> diff --git a/ld/emulparams/armelfb_fbsd.sh b/ld/emulparams/armelfb_fbsd.sh
> new file mode 100644
> index 0000000..a28b476
> --- /dev/null
> +++ b/ld/emulparams/armelfb_fbsd.sh
> @@ -0,0 +1,2 @@
> +. ${srcdir}/emulparams/armelf_fbsd.sh
> +OUTPUT_FORMAT="elf32-bigarm"
> 

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

[ISHIKAWA,chiaki]

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

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

[ISHIKAWA,chiaki]

(Sorry I must have followed up to an existing e-mail instead of creating 
a completely new e-mail.
If this e-mail appears as a sibling of an already existing thread, that 
is why.)

The relevant entry in bugzilla.mozilla.org about this compilation issue
is https://bugzilla.mozilla.org/show_bug.cgi?id=1025639

Bug 1025639 - GCC 4.9 build 
issue.:toolkit/library/build/../../../content/media/MediaDecoderReader.o: requires 
dynamic R_X86_64_PC32 reloc against 
'_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv' which may 
overflow at runtime; recompile with -fPIC

TIA

Re: [PATCH] ld arm config update for FreeBSD

[Andreas Tobler]

On 18.06.14 12:17, Richard Earnshaw wrote:
> On 17/06/14 21:33, Andreas Tobler wrote:
>> Hello all,
>>
>> this patch updates the arm*-*-freebsd* target for ld.
>>
>> On one side I open the triple to allow more than only arm-*-freebsd and
>> on the other side I add with this patch the big endian target for
>> arm*b-*-freebsd*.
>>
>> Ok for trunk?
>>
> 
> OK.


Thank you for the quick review.

Committed:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=1804dbce5a7c0298a98dcedde14ab4d432fad754

Andreas

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

[Cary Coutant]

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

(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?

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

-cary

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

[ISHIKAWA,chiaki]

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