Hi,
Has anyone tried to use GCC 4.9 to build mozilla code?
I got the following error during compilation and linking using GCC 4.9. 4.8
worked without such a problem.
The error occurs during linking of libxul.so for C-C TB.
TB ： Excerpt from build log with GCC 4.9
[...]
/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
make[5]: *** [libxul.so] Error 1
[...]
Admittedly、I use GNU gold (/usr/bin/ld.new）and -gsplit-dwarf to compile
the object.
So your mileage may vary.
But anyway, GCC 4.8 did not produce anything like this.
GCC 4.9 may be tryingto optimize the generated code by making tacit
assumption about the
relative offset that fits in 32bit value or whatever.
It is possible that the latest big libxul.so may have invalidated such
optimization to use 32-bit offset since it probably surpasses 2GB size when
it is laid out in memory at runtime.
Anyway a head-up for the adoption of next generation of GCC.
I will investigate more using GNU gold git snapshot from sourceware.org and
tweaking
-mmemory option to GCC 4.9 as suggested by some blogs (and -fPIC maybe?)
TIA
_______________________________________________
dev-builds mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-builds
