* [meta-browser] Chromium and gold linker @ 2017-07-10 20:36 Denys Dmytriyenko 2017-07-10 20:47 ` Denys Dmytriyenko 0 siblings, 1 reply; 8+ messages in thread From: Denys Dmytriyenko @ 2017-07-10 20:36 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [meta-browser] Chromium and gold linker 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 0 siblings, 1 reply; 8+ messages in thread From: Denys Dmytriyenko @ 2017-07-10 20:47 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [meta-browser] Chromium and gold linker 2017-07-10 20:47 ` Denys Dmytriyenko @ 2017-07-10 21:00 ` Khem Raj 2017-07-10 21:09 ` Denys Dmytriyenko 0 siblings, 1 reply; 8+ messages in thread From: Khem Raj @ 2017-07-10 21:00 UTC (permalink / raw) To: Denys Dmytriyenko, openembedded-devel [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [meta-browser] Chromium and gold linker 2017-07-10 21:00 ` Khem Raj @ 2017-07-10 21:09 ` Denys Dmytriyenko 2017-07-10 21:25 ` Khem Raj [not found] ` <1499722526.27415.1.camel@pbcl.net> 0 siblings, 2 replies; 8+ messages in thread From: Denys Dmytriyenko @ 2017-07-10 21:09 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-architecture, openembedded-devel 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 > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [meta-browser] Chromium and gold linker 2017-07-10 21:09 ` Denys Dmytriyenko @ 2017-07-10 21:25 ` Khem Raj [not found] ` <1499722526.27415.1.camel@pbcl.net> 1 sibling, 0 replies; 8+ messages in thread From: Khem Raj @ 2017-07-10 21:25 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: openembedded-architecture, openembedded-devel [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <1499722526.27415.1.camel@pbcl.net>]
* Re: [Openembedded-architecture] [meta-browser] Chromium and gold linker [not found] ` <1499722526.27415.1.camel@pbcl.net> @ 2017-07-10 22:07 ` Denys Dmytriyenko 2017-07-10 22:16 ` Khem Raj 0 siblings, 1 reply; 8+ messages in thread From: Denys Dmytriyenko @ 2017-07-10 22:07 UTC (permalink / raw) To: Phil Blundell; +Cc: openembedded-architecture, openembedded-devel 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. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Openembedded-architecture] [meta-browser] Chromium and gold linker 2017-07-10 22:07 ` [Openembedded-architecture] " Denys Dmytriyenko @ 2017-07-10 22:16 ` Khem Raj 2017-07-10 22:22 ` Denys Dmytriyenko 0 siblings, 1 reply; 8+ messages in thread From: Khem Raj @ 2017-07-10 22:16 UTC (permalink / raw) To: Denys Dmytriyenko, Phil Blundell Cc: openembedded-architecture, openembedded-devel [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Openembedded-architecture] [meta-browser] Chromium and gold linker 2017-07-10 22:16 ` Khem Raj @ 2017-07-10 22:22 ` Denys Dmytriyenko 0 siblings, 0 replies; 8+ messages in thread From: Denys Dmytriyenko @ 2017-07-10 22:22 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-architecture, Phil Blundell, openembedded-devel 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. > >> > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-07-10 22:22 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox