On Wed, Feb 3, 2016 at 12:32 PM, Martin Jansa <martin.ja...@gmail.com> wrote: > This could be caused by chromium using own bundled binutils where the > version doesn't match, I've solved it in our recipe by: > +GYP_DEFINES_append = " linux_use_bundled_gold=0" > +GYP_DEFINES_append = " linux_use_bundled_binutils=0" >
there we go. chromium has world of its own but then they should really insulate themselves. > > In my cases it was failing while building native libvpx (also bundled in > chromium sources) when I've upgraded host binutils to > (GNU gold (GNU Binutils for Ubuntu 2.25.90.20160101) 1.11) included in > Ubuntu-16.04 Alpha > > > On Wed, Feb 3, 2016 at 9:21 PM, Khem Raj <raj.k...@gmail.com> wrote: >> >> >> > On Feb 3, 2016, at 12:09 PM, Paul Eggleton >> > <paul.eggle...@linux.intel.com> wrote: >> > >> > On Wed, 03 Feb 2016 11:56:45 Khem Raj wrote: >> >>> On Feb 3, 2016, at 11:29 AM, Trevor Woerner <twoer...@gmail.com> >> >>> wrote: >> >>> >> >>> My chromium build is now failing due to: >> >>> commit 86ade2cc2553c942d9526c5323a11ae151653505 >> >>> >> >>> binutils: Upgrade to 2.26 >> >>> | >> >>> | FAILED: x86_64-oe-linux-gcc -m64 -march=corei7 -mtune=corei7 >> >>> | -mfpmath=sse -msse4.2 >> >>> | --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64 >> >>> | -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro >> >>> | -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC >> >>> | >> >>> -B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0. >> >>> | >> >>> 2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bi >> >>> | n -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed >> >>> -Wl,--gc-sections >> >>> | -o chrome_sandbox -Wl,--start-group >> >>> | obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o >> >>> | obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group >> >>> | >> >>> /z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.26 >> >>> | >> >>> 12.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/ >> >>> | ld: error: >> >>> | >> >>> /z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/ >> >>> | crti.o: unsupported reloc 42 against global symbol __gmon_start__ >> >>> | ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42 >> >>> >> >>> Any suggestions on how to approach this? >> >> >> >> do a clean build. Its mixing objects >> > >> > Should we have bumped PR somewhere to avoid this? >> >> Don’t think so. this could happen due to new relocs appearing in glibc due >> to the fact >> thats its now compiled with newer binutils but we are still using old >> linker >> to link the app which does not understand these relocations. Why would >> that happen >> don’t know. >> >> > >> > Cheers, >> > Paul >> > >> > -- >> > >> > Paul Eggleton >> > Intel Open Source Technology Centre >> >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
