[oe] [meta-browser] Chromium and gold linker

[Khem Raj]

On 7/10/17 2:09 PM, Denys Dmytriyenko wrote:
> On Mon, Jul 10, 2017 at 02:00:35PM -0700, Khem Raj wrote:
>> On 7/10/17 1:47 PM, Denys Dmytriyenko wrote:
>>> On Mon, Jul 10, 2017 at 04:36:42PM -0400, Denys Dmytriyenko wrote:
>>>> Khem, et al,
>>>>
>>>> I couldn't find below patch being discussed on this mailing list before it got 
>>>> merged:
>>>>
>>>> https://github.com/OSSystems/meta-browser/commit/62e323848f569c4cdea5567b1917ce006d7705af
>>>
>>> https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c86e3236b51ec2dc2fc0145fb
>>>
>>> "ld-is-gold just means that my default linker is gold, however we build
>>> both linkers, so one should be able to enable gold just for linking
>>> chromium even if default ld is bfd linker."
>>>
>>> I strongly disagree with such interpretation - this would mean there's NO way 
>>> to disable gold linker completely, e.g. for when external toolchain doesn't 
>>> support it.
> 
> Copying OE architecture list for further discussion of "ld-is-gold" meaning.
> 
> 
>> it is not just interpretation but how it is designed if you look closely
>> to code in oe-core and as a matter of fact, there are certain packages
>> where we enforce one linker or other.
> 
> So far I only seen forcing bfd, as a legacy linker, not the other way around.
> 
> 
>> mere presence or absence of
>> ld-is-gold in distro features does not mean that other linker will not
>> be available. If your distro is making that assumption please correct that.
>>
>> I however agree, that using gold as default linker should have a knob
>> and it so does which is USEGOLD, if a distro or toolchain layer does not
>> want to use gold then they could set this variable to be off.
>>
>> USEGOLD = "" or USEGOLD = "-Dlinux_use_gold_flags=0"
> 
> Yes, I saw this variable and already added it to my bbappend. But the issue is 
> that it's per-recipe, not global. Do we need a separate distro-level flag to 
> avoid any and all gold linker references?

Leave aside the meaning for a moment, I think its convenient to use it
this way, I am not too hell bent for enforcing gold as default, so I
will send a patch to not default to gold. The flag is useful only when
bfd linker is system default and one just want to link chromium with
gold for various
reasons, they can set it explicitly in their own setups. We however will
have the mechanism to do so without making gold the system linker.

> 
> 
>> I think its better to use gold linker for linking chromium since it
>> reduced the link time for chrome quite significantly (8 mins to 2min) on
>> my experiments. But I am fine if other users think that we should not
>> make gold as default.  I can send a patch to toggle the USEGOLD switch
>>
>>>
>>>> According to the layer README, openembedded-devel is the official mailing list 
>>>> to submit patches. I understand that github pull request is a nice shortcut, 
>>>> but it prevents others from seeing and commenting on the patches...
>>>>
>>>>
>>>> My issue with this change is that it makes an assumption of using OE-built 
>>>> toolchain. It now breaks external toolchains like this:
>>
>> No it does not make assumption. See above.
>>
>>>>
>>>> | [17/20569] LINK genmacro
>>>> | FAILED: genmacro
>>>> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread -Wl,--as-needed -o genmacro -Wl,--start-group obj.host/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.genmacro.o -Wl,--end-group
>>>> | /usr/bin/ld.gold: fatal error: /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF machine number 40
>>>> | collect2: error: ld returned 1 exit status
>>>> | [18/20569] LINK genstring
>>>> | FAILED: genstring
>>>> | gcc  -L/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-rpath-link,/opt/linaro-2016.11/arm-linux-gnueabihf/lib -Wl,-O1 -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--no-as-needed -lpthread -Wl,--as-needed -o genstring -Wl,--start-group obj.host/third_party/yasm/source/patched-yasm/genstring.genstring.o -Wl,--end-group
>>>> | /usr/bin/ld.gold: fatal error: /opt/linaro-2016.11/arm-linux-gnueabihf/lib/libgcc_s.so.1: unsupported ELF machine number 40
>>>> | collect2: error: ld returned 1 exit status
>>>>
>>>> -- 
>>>> Denys
>>>> -- 
>>>> _______________________________________________
>>>> Openembedded-devel mailing list
>>>> Openembedded-devel at lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>>
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20170710/379ca7e8/attachment-0002.sig>