On (2014年06月11日 18:07), Mike Hommey wrote: > On Wed, Jun 11, 2014 at 05:43:22PM +0900, ishikawa wrote: >> 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?) > > Sounds like namespace problems. Try replacing MallocSizeOf with > mozilla::MallocSizeOf in content/media/MediaData.h and > content/media/SharedBuffer.h. > (And file a bug) > > Mike >
Hi, thank you for the tips. Even after changing the above, I still get errors. Stumped, I checked mxr.mozilla.org and noticed that there are many instances of MallocSizeOf (unqualified) and qualified mozilla:MallocSizeOf in the source code. (I should have recorded the error after the change to MediaData.h and SharedBuffer.h: I thought the errors came from the same place. I *think* the errors came from the same file... ) So I add -mcmodel=large to GCC 4.9, and tried to see what will happen. Then I hit into another issue even before I have all the objects to link libxul.so. An in-line asm code blows up under such a memory model because the usage of registers in the code seems to conflict with the manner the compiler would like to use. # -fPIC -mcmodel=large # and # -mcmode=large only (and from the look of the offending command line, -fPIC is automatically # appended by the compiler if I say -mcmodel=large? Not sure, maybe the libvpx build framework adds it?) # # caused cpuid() asm definition in # mozilla/media/libvpx/vpx_ports/x86.h to blow up. # # see the discussion in https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01484.html # There is a patch posted there, and I am sure that someone in the know # can use the patch to fix media/libvpx/vpx_ports/x86.h: # But I don't understand the GCC in-line asm of late. vpx_scale_rtcd.o dequantize_mmx.o In file included from /REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx/vpx_scale_rtcd_x86_64-linux-gcc.h:51:0, from /REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx/vpx_scale_rtcd.h:39, from /REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx/vpx_scale/vpx_scale_rtcd.c:12: /REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx/vpx_scale_rtcd_x86_64-linux-gcc.h: In function ‘setup_rtcd_internal’: /REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx/vpx_ports/x86.h:123:3: error: inconsistent operand constraints in an ‘asm’ cpuid(0, reg_eax, reg_ebx, reg_ecx, reg_edx); ^ /REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx/vpx_ports/x86.h:129:3: error: inconsistent operand constraints in an ‘asm’ cpuid(1, reg_eax, reg_ebx, reg_ecx, reg_edx); ^ In the directory /REF-OBJ-DIR/objdir-tb3/mozilla/media/libvpx The following command failed to execute properly: /usr/bin/ccache /usr/bin/gcc-4.9 -mcmodel=large -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -o vpx_scale_rtcd.o -c -I../../dist/system_wrappers -include /REF-COMM-CENTRAL/comm-central/mozilla/config/gcc_hidden.h -DHAVE_CONFIG_H=vpx_config.h -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -I/REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx -I. -I../../dist/include -I/REF-OBJ-DIR/objdir-tb3/mozilla/dist/include/nspr -I/REF-OBJ-DIR/objdir-tb3/mozilla/dist/include/nss -I/REF-OBJ-DIR/objdir-tb3/mozilla/dist/include -I/REF-COMM-CENTRAL/comm-central/mozilla/modules/zlib/src -fPIC -include ../../mozilla-config.h -DMOZILLA_CLIENT -MD -MP -MF .deps/vpx_scale_rtcd.o.pp -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Werror=int-to-pointer-cast -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused -Wcast-align -std=gnu99 -fgnu89-inline -fno-strict-aliasing -fno-math-errno -pthread -pipe -DDEBUG -D_DEBUG -DTRACING -gsplit-dwarf -g -O2 -freorder-blocks -fno-omit-frame-pointer -Wno-sign-compare /REF-COMM-CENTRAL/comm-central/mozilla/media/libvpx/vpx_scale/vpx_scale_rtcd.c /REF-COMM-CENTRAL/comm-central/mozilla/config/rules.mk:969: recipe for target 'vpx_scale_rtcd.o' failed make[6]: *** [vpx_scale_rtcd.o] Error 1 Oh, I just noticed that there is https://bugzilla.mozilla.org/show_bug.cgi?id=583199 to deal with the inline asm issue of the same file with Sun Solaris compiler (posted in 2010). I don't know if the use of "=b" in the thread there to save the register automatically would be applicable to GCC also. So should I file a meta bug entry for GCC 4.9 and post the two issues there? TIA _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
