Skip to contentSkip to conversation

noticeably longer build (link?) times with binutils 2.26

DISCUSSION Trevor Woerner 5 participants 14 messages Feb 8, 2016 – Feb 11, 2016

lore
Share & tools
lore
#0 lore raw

This is more of a "FYI", but I've noticed that the build time of my chromium recipe has gone from ~45 minutes to ~2h15m when the only thing that changes is to move openembedded-core from the commit just before upgrading binutils to version 2.26 ([fd75637] native.bbclass: Set CXXFLAGS from BUILD_CXXFLAGS not BUILD_CFLAGS) to the one immediately after ([86ade2c] binutils: Upgrade to 2.26).

Oddly enough I don't see this same behaviour when building, for example, core-image-minimal, so I have no idea what makes chromium so special and, therefore, whether other recipes might be similarly affected.

Also, it seems as though a lot of the added time is coming from the linking stage, but I don't have (or know how to get) hard numbers for that. Is there a way to get build times for each task within one recipe?

I've repeated this test 6 times (build just before binutils-2.26, build just after binutils-2.26) and the results are always within a couple minutes of each other. So I doubt this is some random occurrence.

#1 lore raw

Which arch/tune are you targeting? I know that on a few processors 2.26 has added "link time optimization" (i.e. our processor is broken and we're working around problems in the linker.)

It's possible you hit one of those cases, or it may simply be that much slower for some reason. But worse then double the time is really terrible.

Quoted 19 lines · Trevor Woerner

This is more of a "FYI", but I've noticed that the build time of my chromium recipe has gone from ~45 minutes to ~2h15m when the only thing that changes is to move openembedded-core from the commit just before upgrading binutils to version 2.26 ([fd75637] native.bbclass: Set CXXFLAGS from BUILD_CXXFLAGS not BUILD_CFLAGS) to the one immediately after ([86ade2c] binutils: Upgrade to 2.26).

Oddly enough I don't see this same behaviour when building, for example, core-image-minimal, so I have no idea what makes chromium so special and, therefore, whether other recipes might be similarly affected.

Also, it seems as though a lot of the added time is coming from the linking stage, but I don't have (or know how to get) hard numbers for that. Is there a way to get build times for each task within one recipe?

I've repeated this test 6 times (build just before binutils-2.26, build just after binutils-2.26) and the results are always within a couple minutes of each other. So I doubt this is some random occurrence.

#5 lore raw
In reply to Trevor Woerner
Quoted 6 lines · Trevor Woerner

This is more of a "FYI", but I've noticed that the build time of my chromium recipe has gone from ~45 minutes to ~2h15m when the only thing that changes is to move openembedded-core from the commit just before upgrading binutils to version 2.26 ([fd75637] native.bbclass: Set CXXFLAGS from BUILD_CXXFLAGS not BUILD_CFLAGS) to the one immediately after ([86ade2c] binutils: Upgrade to 2.26).

Is it using gold linker ? if not can you try both bfd and gold

Quoted 17 lines

Oddly enough I don't see this same behaviour when building, for example, core-image-minimal, so I have no idea what makes chromium so special and, therefore, whether other recipes might be similarly affected.

Also, it seems as though a lot of the added time is coming from the linking stage, but I don't have (or know how to get) hard numbers for that. Is there a way to get build times for each task within one recipe?

I've repeated this test 6 times (build just before binutils-2.26, build just after binutils-2.26) and the results are always within a couple minutes of each other. So I doubt this is some random occurrence.
--
_______________________________________________
Openembedded-core mailing list [email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#2 lore raw
In reply to Mark Hatle
Quoted 1 line · Mark Hatle

Which arch/tune are you targeting?

Build Configuration:

BB_VERSION        = "1.28.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "openSUSE-project-13.2"
TARGET_SYS        = "x86_64-poky-linux"
MACHINE           = "qemux86-64"
DISTRO            = "poky"
DISTRO_VERSION    = "2.0+snapshot-20160208"
TUNE_FEATURES     = "m64 core2"
TARGET_FPU        = ""

Essentially: minnowboard max (turbot, specifically)

Quoted 2 lines

It's possible you hit one of those cases, or it may simply be that much slower for some reason. But worse then double the time is really terrible.

Yes, I had started to assume Jenkins had gone "off the deep end" ;-)

#6 lore raw
In reply to Khem Raj
Quoted 8 lines · Khem Raj
Quoted 6 lines · Trevor Woerner

This is more of a "FYI", but I've noticed that the build time of my chromium recipe has gone from ~45 minutes to ~2h15m when the only thing that changes is to move openembedded-core from the commit just before upgrading binutils to version 2.26 ([fd75637] native.bbclass: Set CXXFLAGS from BUILD_CXXFLAGS not BUILD_CFLAGS) to the one immediately after ([86ade2c] binutils: Upgrade to 2.26).

Is it using gold linker ? if not can you try both bfd and gold

A week or so ago, as part of something else (but before the binutils update to 2.26), I tried performing a clean build using the gold linker. Unfortunately that image was not able to boot:

https://lists.yoctoproject.org/pipermail/meta-intel/2016-January/003697.html
(but there were no replies)

It dies somewhere between the EFI bootloader and grub2 (or perhaps just after grub starts). There's no grub output.

I'll try doing the build with the gold linker, but the results of that build might not be useful to me.

#7 lore raw
Quoted 11 lines · Trevor Woerner
Quoted 7 lines · Khem Raj
Quoted 6 lines · Trevor Woerner

This is more of a "FYI", but I've noticed that the build time of my chromium recipe has gone from ~45 minutes to ~2h15m when the only thing that changes is to move openembedded-core from the commit just before upgrading binutils to version 2.26 ([fd75637] native.bbclass: Set CXXFLAGS from BUILD_CXXFLAGS not BUILD_CFLAGS) to the one immediately after ([86ade2c] binutils: Upgrade to 2.26).

Quoted 6 lines
Quoted 1 line

Is it using gold linker ? if not can you try both bfd and gold

A week or so ago, as part of something else (but before the binutils update to 2.26), I tried performing a clean build using the gold linker. Unfortunately that image was not able to boot:

https://lists.yoctoproject.org/pipermail/meta-intel/2016-January/003697.html
(but there were no replies)

it might fix both issues for you in best case.

Quoted 4 lines

It dies somewhere between the EFI bootloader and grub2 (or perhaps just after grub starts). There's no grub output.

I'll try doing the build with the gold linker, but the results of that build might not be useful to me.

Thats ok. Its for narrowing ld issues which is build time right now.

Quoted 5 lines

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#3 lore raw
In reply to Trevor Woerner
Quoted 4 lines · Trevor Woerner

MACHINE = "qemux86-64"

Essentially: minnowboard max (turbot, specifically)

As an aside, if you're actually building for the MinnowMax then the meta-intel BSP will be a lot better.

Ross

#4 lore raw
Quoted 10 lines · Ross

On 9 February 2016 at 02:56, Trevor Woerner <[email protected] <mailto:[email protected]>> wrote:

MACHINE = "qemux86-64"

Essentially: minnowboard max (turbot, specifically)

As an aside, if you're actually building for the MinnowMax then the meta-intel BSP will be a lot better.

The images I build for my actual board do use the meta-intel BSP and set MACHINE to "intel-corei7-64".

This massive explosion in build time for chromium coincided with me adding a new disk to my build machine and moving my Jenkins builds over to the new disk. At first I assumed the problem might be related to the new disk so I was performing build speed tests on both the old and new disks. For this I setup 2 new builds (one on each disk) and set MACHINE to qemux86-64 by default and had forgot about it. But you bring up a good point, I should be using the same MACHINE (although my Jenkins instance is still using the correct MACHINE as is seeing the huge increase in build times too).

#8 lore raw
In reply to Trevor Woerner

I've tried every combination I can think of and no matter what I try, if gold is the linker the chromium build always errors out with:

collect2: fatal error: cannot find 'ld'

#10 lore raw
Quoted 8 lines · Khem Raj

IIRC gold has its own notions to enable gold
so you need to enable that

Quoted 5 lines · Trevor Woerner

I've tried every combination I can think of and no matter what I try, if gold is the linker the chromium build always errors out with:

collect2: fatal error: cannot find 'ld'

Building with gold does cut the build time of the chromium component back down.

binutils 2.25, bfd: 00:47:51, 00:44:24, 00:44:25
binutils 2.26, bfd: 02:07:45, 02:09:31, 02:02:42

binutils 2.26, gold: 00:43:49, 00:45:18, 00:42:51

But the only way I could get it to work was to manually perform the following steps:

$ cd <oe tmp dir>/sysroots/<native sysroot>/usr/bin
$ ln -s <cross toolchain prefix>/<cross toolchain prefix>ld.gold ld.gold

where:
<native sysroot> = x86_64-linux
<cross toolchain prefix> = x86_64-poky-linux

to give:

$ cd <oe-tmp-dir>/sysroots/x86_64-linux
$ ln -s x86_64-poky-linux/x86_64-poky-linux-ld.gold ld.gold

Maybe I can play with the recipe a bit more to get this to work "automatically"; maybe by setting the LD environment variable differently or something.

But, as I said before, the last time I tried booting a gold-linked image on the minnow grub2 refused to work :-(

#11 lore raw
Quoted 29 lines · Trevor Woerner
Quoted 8 lines · Khem Raj

IIRC gold has its own notions to enable gold
so you need to enable that

Quoted 5 lines · Trevor Woerner

I've tried every combination I can think of and no matter what I try, if gold is the linker the chromium build always errors out with:

collect2: fatal error: cannot find 'ld'

Building with gold does cut the build time of the chromium component back down.

binutils 2.25, bfd: 00:47:51, 00:44:24, 00:44:25
binutils 2.26, bfd: 02:07:45, 02:09:31, 02:02:42

binutils 2.26, gold: 00:43:49, 00:45:18, 00:42:51

But the only way I could get it to work was to manually perform the following steps:

$ cd <oe tmp dir>/sysroots/<native sysroot>/usr/bin
$ ln -s <cross toolchain prefix>/<cross toolchain prefix>ld.gold ld.gold

where:
<native sysroot> = x86_64-linux
<cross toolchain prefix> = x86_64-poky-linux

Quoted 5 lines

to give:

$ cd <oe-tmp-dir>/sysroots/x86_64-linux
$ ln -s x86_64-poky-linux/x86_64-poky-linux-ld.gold ld.gold

Maybe I can play with the recipe a bit more to get this to work "automatically"; maybe by setting the LD environment variable differently or something.

you can always pass -fuse-ld=gold to LDFLAGS secondly if you can tar up all needed objects and let others reproduce it would help.

Quoted 7 lines

But, as I said before, the last time I tried booting a gold-linked image on the minnow grub2 refused to work :-( --
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#12 lore raw
In reply to Trevor Woerner
Quoted 28 lines · Trevor Woerner
Quoted 8 lines · Khem Raj

IIRC gold has its own notions to enable gold
so you need to enable that

Quoted 5 lines · Trevor Woerner

I've tried every combination I can think of and no matter what I try, if gold is the linker the chromium build always errors out with:

collect2: fatal error: cannot find 'ld'

Building with gold does cut the build time of the chromium component back down.

binutils 2.25, bfd: 00:47:51, 00:44:24, 00:44:25
binutils 2.26, bfd: 02:07:45, 02:09:31, 02:02:42

binutils 2.26, gold: 00:43:49, 00:45:18, 00:42:51

But the only way I could get it to work was to manually perform the following steps:

$ cd <oe tmp dir>/sysroots/<native sysroot>/usr/bin
$ ln -s <cross toolchain prefix>/<cross toolchain prefix>ld.gold ld.gold

where:
<native sysroot> = x86_64-linux
<cross toolchain prefix> = x86_64-poky-linux

Quoted 7 lines

to give:

$ cd <oe-tmp-dir>/sysroots/x86_64-linux
$ ln -s x86_64-poky-linux/x86_64-poky-linux-ld.gold ld.gold

Maybe I can play with the recipe a bit more to get this to work "automatically"; maybe by setting the LD environment variable differently or something.

Did you add ld-is-gold to DISTRO_FEATURES?

Quoted 8 lines

But, as I said before, the last time I tried booting a gold-linked image on the minnow grub2 refused to work :-(

Signature · 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
#13 lore raw
Quoted 1 line · Martin Jansa

Did you add ld-is-gold to DISTRO_FEATURES?

Yes, it's the only way I know of to build an image with gold instead of bfd. And no other thing that gets built has any problems finding and running the linker.

I'll post my chromium recipe shortly, although it's not that much different from the upstream version 40 (other than having stripped out all the wayland-specific stuff).