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

Khem Raj raj.khem at gmail.com
Mon Jul 10 21:00:35 UTC 2017


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.
> 

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. 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"


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/be4a5c7c/attachment-0002.sig>


More information about the Openembedded-devel mailing list