[meta-browser] Chromium and gold linker

[meta-browser] Chromium and gold linker

[Denys Dmytriyenko]

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

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:

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

Re: [meta-browser] Chromium and gold linker

[Denys Dmytriyenko]

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.


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

Re: [meta-browser] Chromium and gold linker

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 3804 bytes --]

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@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [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@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> 
> 

Re: [meta-browser] Chromium and gold linker

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 4918 bytes --]

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@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>>
> 
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [Openembedded-architecture] [meta-browser] Chromium and gold linker

[Denys Dmytriyenko]

On Mon, Jul 10, 2017 at 10:35:26PM +0100, Phil Blundell wrote:
> On Mon, 2017-07-10 at 17:09 -0400, 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/62e323848f569c
> > > > > 4cdea5567b1917ce006d7705af
> > > > 
> > > > https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c
> > > > 86e3236b51ec2dc2fc0145fb
> > > > 
> > > > "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.
> 
> The attribution above is a bit confusing so I'm not quite sure who
> wrote what.  But it is certainly true that "ld-is-gold" in
> DISTRO_FEATURES means, and always has meant, simply that gold is to be
> installed as the default linker.  In other words, if you invoke plain
> "ld", you will get gold, and if you need the BFD linker - usually
> because you are using linker scripts that gold doesn't understand -
> then you must invoke ld.bfd.  See
> 207a9013670560d62c793a66f01e19f4760a71a8 from some six years ago for
> the place that it was originally added.
> 
> As far as I know, we do not have (and never have had) any
> DISTRO_FEATURE that will inhibit gold from being installed altogether,

It is not about being installed, but about being supported by the toolchain 
in use - think of external toolchains not built by OE-Core... The original 
question was whether it's appropriate to force gold linker in recipes, if 
ld-is-gold is not set by the distro.


> nor can I immediately think of a reason why this would be generally
> useful.  Obviously, any DISTRO that wants to do this is welcome to
> provide a bbappend for binutils.
> 
> p.
> 

Re: [Openembedded-architecture] [meta-browser] Chromium and gold linker

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 2718 bytes --]



On 7/10/17 3:07 PM, Denys Dmytriyenko wrote:
> On Mon, Jul 10, 2017 at 10:35:26PM +0100, Phil Blundell wrote:
>> On Mon, 2017-07-10 at 17:09 -0400, 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/62e323848f569c
>>>>>> 4cdea5567b1917ce006d7705af
>>>>>
>>>>> https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c
>>>>> 86e3236b51ec2dc2fc0145fb
>>>>>
>>>>> "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.
>>
>> The attribution above is a bit confusing so I'm not quite sure who
>> wrote what.  But it is certainly true that "ld-is-gold" in
>> DISTRO_FEATURES means, and always has meant, simply that gold is to be
>> installed as the default linker.  In other words, if you invoke plain
>> "ld", you will get gold, and if you need the BFD linker - usually
>> because you are using linker scripts that gold doesn't understand -
>> then you must invoke ld.bfd.  See
>> 207a9013670560d62c793a66f01e19f4760a71a8 from some six years ago for
>> the place that it was originally added.
>>
>> As far as I know, we do not have (and never have had) any
>> DISTRO_FEATURE that will inhibit gold from being installed altogether,
> 
> It is not about being installed, but about being supported by the toolchain 
> in use - think of external toolchains not built by OE-Core... The original 
> question was whether it's appropriate to force gold linker in recipes, if 
> ld-is-gold is not set by the distro.

We do not have a set API for external toolchains, and thats also wy
external toolchains have to contantly adjust with newer OE release.
however, in this case external toolchains could provide ld.gold that
symlinks to bfd linker

> 
> 
>> nor can I immediately think of a reason why this would be generally
>> useful.  Obviously, any DISTRO that wants to do this is welcome to
>> provide a bbappend for binutils.
>>
>> p.
>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [Openembedded-architecture] [meta-browser] Chromium and gold linker

[Denys Dmytriyenko]

On Mon, Jul 10, 2017 at 03:16:54PM -0700, Khem Raj wrote:
> 
> 
> On 7/10/17 3:07 PM, Denys Dmytriyenko wrote:
> > On Mon, Jul 10, 2017 at 10:35:26PM +0100, Phil Blundell wrote:
> >> On Mon, 2017-07-10 at 17:09 -0400, 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/62e323848f569c
> >>>>>> 4cdea5567b1917ce006d7705af
> >>>>>
> >>>>> https://github.com/OSSystems/meta-browser/commit/55a74501bc65c90c
> >>>>> 86e3236b51ec2dc2fc0145fb
> >>>>>
> >>>>> "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.
> >>
> >> The attribution above is a bit confusing so I'm not quite sure who
> >> wrote what.  But it is certainly true that "ld-is-gold" in
> >> DISTRO_FEATURES means, and always has meant, simply that gold is to be
> >> installed as the default linker.  In other words, if you invoke plain
> >> "ld", you will get gold, and if you need the BFD linker - usually
> >> because you are using linker scripts that gold doesn't understand -
> >> then you must invoke ld.bfd.  See
> >> 207a9013670560d62c793a66f01e19f4760a71a8 from some six years ago for
> >> the place that it was originally added.
> >>
> >> As far as I know, we do not have (and never have had) any
> >> DISTRO_FEATURE that will inhibit gold from being installed altogether,
> > 
> > It is not about being installed, but about being supported by the toolchain 
> > in use - think of external toolchains not built by OE-Core... The original 
> > question was whether it's appropriate to force gold linker in recipes, if 
> > ld-is-gold is not set by the distro.
> 
> We do not have a set API for external toolchains, and thats also wy
> external toolchains have to contantly adjust with newer OE release.
> however, in this case external toolchains could provide ld.gold that
> symlinks to bfd linker

That is true, yes. Which also reminds me to submit a report to Linaro about 
this gold linker breakage...


> >> nor can I immediately think of a reason why this would be generally
> >> useful.  Obviously, any DISTRO that wants to do this is welcome to
> >> provide a bbappend for binutils.
> >>
> >> p.
> >>
>