From: Denys Dmytriyenko <denis@denix.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembedded-architecture@lists.openembedded.org,
openembedded-devel@lists.openembedded.org
Subject: Re: [meta-browser] Chromium and gold linker
Date: Mon, 10 Jul 2017 17:09:03 -0400 [thread overview]
Message-ID: <20170710210903.GD26405@denix.org> (raw)
In-Reply-To: <598b8f59-0d75-314e-6f18-7f5daa24fa07@gmail.com>
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@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
>
next prev parent reply other threads:[~2017-07-10 21:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 20:36 [meta-browser] Chromium and gold linker Denys Dmytriyenko
2017-07-10 20:47 ` Denys Dmytriyenko
2017-07-10 21:00 ` Khem Raj
2017-07-10 21:09 ` Denys Dmytriyenko [this message]
2017-07-10 21:25 ` Khem Raj
[not found] ` <1499722526.27415.1.camel@pbcl.net>
2017-07-10 22:07 ` [Openembedded-architecture] " Denys Dmytriyenko
2017-07-10 22:16 ` Khem Raj
2017-07-10 22:22 ` Denys Dmytriyenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170710210903.GD26405@denix.org \
--to=denis@denix.org \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.