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 > >> [email protected] > >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > > -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
