[OE-core] binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Khem Raj]

> On Feb 3, 2016, at 7:30 PM, Trevor Woerner <twoerner at gmail.com> wrote:
> 
> On 02/03/16 22:08, Khem Raj wrote:
>> 
>>> On Feb 3, 2016, at 7:06 PM, Trevor Woerner <twoerner at 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 at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160203/1a5f2cde/attachment-0002.sig>