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"
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 <[email protected]> wrote: > > > On Feb 3, 2016, at 12:09 PM, Paul Eggleton < > [email protected]> wrote: > > > > On Wed, 03 Feb 2016 11:56:45 Khem Raj wrote: > >>> On Feb 3, 2016, at 11:29 AM, Trevor Woerner <[email protected]> > 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
