binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

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/bin 
-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.2612.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?

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Khem Raj]

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


> On Feb 3, 2016, at 11:29 AM, Trevor Woerner <twoerner@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/bin -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.2612.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

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Paul Eggleton]

On Wed, 03 Feb 2016 11:56:45 Khem Raj wrote:
> > On Feb 3, 2016, at 11:29 AM, Trevor Woerner <twoerner@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?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Khem Raj]

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


> On Feb 3, 2016, at 12:09 PM, Paul Eggleton <paul.eggleton@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 <twoerner@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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

On 02/03/16 14:56, Khem Raj wrote:
>> On Feb 3, 2016, at 11:29 AM, Trevor Woerner <twoerner@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/bin -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.2612.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

Unfortunately this *is* with completely clean builds; I'm deleting 
everything except conf/ before each try. I just finished testing with 
ld-is-gold and it fails too in exactly the same way.

I'll make stuff available for you to test after I try a build with 
50.0.2636.0

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Martin Jansa]

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

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 <raj.khem@gmail.com> wrote:

>
> > On Feb 3, 2016, at 12:09 PM, Paul Eggleton <
> paul.eggleton@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 <twoerner@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
>
>

[-- Attachment #2: Type: text/html, Size: 4023 bytes --]

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Khem Raj]

On Wed, Feb 3, 2016 at 12:32 PM, Martin Jansa <martin.jansa@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.khem@gmail.com> wrote:
>>
>>
>> > On Feb 3, 2016, at 12:09 PM, Paul Eggleton
>> > <paul.eggleton@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 <twoerner@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
>>
>

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Burton, Ross]

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

On 3 February 2016 at 20:32, Martin Jansa <martin.jansa@gmail.com> wrote:

> This could be caused by chromium using own bundled binutils


Wait, WHAT?!  :O

[-- Attachment #2: Type: text/html, Size: 450 bytes --]

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

On 02/03/16 15:32, Martin Jansa 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"

w00t!! awesome. works for me :-)

So it looks like we both have working chromium recipes, yet the upstream 
one doesn't work. What version are you building? For what arch (which 
archs)? x11/wayland?

I have a working recipe for 50.0.2636.0, but I'm only interested in 
x86_64 and x11. wayland+ozone is a whole other mess ;-)

At some point it'll probably be easier if we build chromium with 
llvm-clang, the same as google is doing. Is that possible?

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Khem Raj]

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


> On Feb 3, 2016, at 7:06 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> 
> On 02/03/16 15:32, Martin Jansa 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"
> 
> w00t!! awesome. works for me :-)
> 
> So it looks like we both have working chromium recipes, yet the upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?

please submit your patch for meta-browser

> 
> I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and x11. wayland+ozone is a whole other mess ;-)
> 
> At some point it'll probably be easier if we build chromium with llvm-clang, the same as google is doing. Is that possible?

you can try using meta-clang

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

On 02/03/16 22:08, Khem Raj wrote:
>
>> On Feb 3, 2016, at 7:06 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>>
>> On 02/03/16 15:32, Martin Jansa 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"
>>
>> w00t!! awesome. works for me :-)
>>
>> So it looks like we both have working chromium recipes, yet the upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?
>
> please submit your patch for meta-browser

Any patch I submit is guaranteed to be rejected. It only supports x11 
and has only been tested on x86_64. If nothing else it would have to be 
named chromium-x11_<version>.bb, or something like that. I've actually 
removed the wayland/ozone stuff from my recipe.

Considering each build of chromium takes me 2.5 hours (just for chromium 
alone!) it makes it hard to care about environments I'm not using.

The only way chromium builds for wayland is when another project (ozone) 
is added to the mix. But, in my tests so far, not every release of 
chromium builds successfully with every version of ozone. So although 
building for x11 is easy and works for just about each release, building 
for wayland is much more hit-and-miss (and has less chance of success).

>>
>> I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and x11. wayland+ozone is a whole other mess ;-)
>>
>> At some point it'll probably be easier if we build chromium with llvm-clang, the same as google is doing. Is that possible?
>
> you can try using meta-clang

Okay. So if I have an image and everything in that image is built with 
gcc except for chromium, meta-clang will know what it needs to add to 
the image so that one clang-built package can run?

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Dan McGregor]

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

On 3 Feb 2016 7:30 p.m., "Trevor Woerner" <twoerner@gmail.com> wrote:
>
> On 02/03/16 22:08, Khem Raj wrote:
>>
>>
>>> On Feb 3, 2016, at 7:06 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>>>
>>> On 02/03/16 15:32, Martin Jansa 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"
>>>
>>>
>>> w00t!! awesome. works for me :-)
>>>
>>> So it looks like we both have working chromium recipes, yet the
upstream one doesn't work. What version are you building? For what arch
(which archs)? x11/wayland?
>>
>>
>> please submit your patch for meta-browser
>
>
> Any patch I submit is guaranteed to be rejected. It only supports x11 and
has only been tested on x86_64. If nothing else it would have to be named
chromium-x11_<version>.bb, or something like that. I've actually removed
the wayland/ozone stuff from my recipe.
>
> Considering each build of chromium takes me 2.5 hours (just for chromium
alone!) it makes it hard to care about environments I'm not using.
>
> The only way chromium builds for wayland is when another project (ozone)
is added to the mix. But, in my tests so far, not every release of chromium
builds successfully with every version of ozone. So although building for
x11 is easy and works for just about each release, building for wayland is
much more hit-and-miss (and has less chance of success).
>
>
>>>
>>> I have a working recipe for 50.0.2636.0, but I'm only interested in
x86_64 and x11. wayland+ozone is a whole other mess ;-)
>>>
>>> At some point it'll probably be easier if we build chromium with
llvm-clang, the same as google is doing. Is that possible?
>>
>>
>> you can try using meta-clang
>
>
> Okay. So if I have an image and everything in that image is built with
gcc except for chromium, meta-clang will know what it needs to add to the
image so that one clang-built package can run?
>

Clang built packages and GCC built packages should have the same run time
dependencies. You'd have to go out of your way to build against LLVM's
unwinder or c++ runtime.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[-- Attachment #2: Type: text/html, Size: 3237 bytes --]

Re: binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Khem Raj]

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


> On Feb 3, 2016, at 7:30 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> 
> On 02/03/16 22:08, Khem Raj wrote:
>> 
>>> On Feb 3, 2016, at 7:06 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>>> 
>>> On 02/03/16 15:32, Martin Jansa 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"
>>> 
>>> w00t!! awesome. works for me :-)
>>> 
>>> So it looks like we both have working chromium recipes, yet the upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?
>> 
>> please submit your patch for meta-browser
> 
> Any patch I submit is guaranteed to be rejected. It only supports x11 and has only been tested on x86_64. If nothing else it would have to be named chromium-x11_<version>.bb, or something like that. I've actually removed the wayland/ozone stuff from my recipe.
> 
> Considering each build of chromium takes me 2.5 hours (just for chromium alone!) it makes it hard to care about environments I'm not using.
> 
> The only way chromium builds for wayland is when another project (ozone) is added to the mix. But, in my tests so far, not every release of chromium builds successfully with every version of ozone. So although building for x11 is easy and works for just about each release, building for wayland is much more hit-and-miss (and has less chance of success).
> 
>>> 
>>> I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and x11. wayland+ozone is a whole other mess ;-)
>>> 
>>> At some point it'll probably be easier if we build chromium with llvm-clang, the same as google is doing. Is that possible?
>> 
>> you can try using meta-clang
> 
> Okay. So if I have an image and everything in that image is built with gcc except for chromium, meta-clang will know what it needs to add to the image so that one clang-built package can run?

actually it will make clang as default compiler and there are some stubborn recipes which are hardcoded to use gcc even when clang is available see
see https://github.com/kraj/meta-clang/tree/master/recipes-excluded/nonclangable

you just need to set

TOOLCHAIN = “gcc"


> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]