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

[Denys Dmytriyenko]

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?


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