Upstream Support for flto plugin with automake

[William Kennington]

We shouldn't be hardcoding the use of lto anywhere in our builds and
instead should rely on higher layer build logic adding it if needed.
It's not very hard to apply classes in bitbake if we think our
binaries really need lto when built for a BMC target.

On Wed, Jul 3, 2019 at 7:38 PM Lei YU <mine260309 at gmail.com> wrote:
>
> On Thu, Jul 4, 2019 at 1:25 AM Patrick Venture <venture at google.com> wrote:
> >
> > Only one recipe currently uses flto-automake which provides for the
> > gcc-ar and gcc-ranlib replacements to build with the flto option.
> > IIRC, James added this because phosphor-pid-control required them to
> > compile.  Many (if not all) Makefiles in openbmc pass in the flto
> > option, and seem to compile fine.
> >
> > I did some light documentation reading on this feature and as I
> > understand it, when objects are compiled with this they're left in a
> > state to improve final "total optimization" during linking.  So,
> > perhaps in the cases where it compiles without the flto-automake swap
> > it's not actually able to take advantage of this during compilation?
> >
> > I ran into an issue today while debugging an SDK issue:
> > x86_64-openbmc-linux-ar:
> > .libs/libupdater.lax/libfirmware_common.a/libfirmware_common_la-sys.o:
> > plugin needed to handle lto object
> > x86_64-openbmc-linux-ar:
> > .libs/libupdater.lax/libfirmware_common.a/libfirmware_common_la-util.o:
> > plugin needed to handle lto object
> > x86_64-openbmc-linux-ranlib:
> > .libs/libupdater.a(libfirmware_common_la-sys.o): plugin needed to
> > handle lto object
> > x86_64-openbmc-linux-ranlib:
> > .libs/libupdater.a(libfirmware_common_la-util.o): plugin needed to
> > handle lto object
> >
> > This was with phosphor-ipmi-flash, building for the tool.  When
> > building for the BMC library it also builds those objects, but does so
> > without issue.  It seems to detect it automatically or favor it
> > already:
> >
> > checking for arm-openbmc-linux-gnueabi-ar... (cached)
> > arm-openbmc-linux-gnueabi-gcc-ar
> > checking for archiver @FILE support... @
> > checking for arm-openbmc-linux-gnueabi-strip... (cached)
> > arm-openbmc-linux-gnueabi-strip
> > checking for arm-openbmc-linux-gnueabi-ranlib...
> > arm-openbmc-linux-gnueabi-gcc-ranlib
> >
> > So it seems flto-automake is obsolete?
> >
> > If that's the case, I can 1) drop the change from phosphor-pid-control
> > (the only user) and 2) drop the bbclass.
> >
> > However, I was wondering what in the SDK could be used to inform it.
> > I ended up getting past this by adding the information to the
> > configure line, and that worked fine.
> >
> > Patrick
>
> It's my first time to notice that we have flto-automake.bbclass for general
> purpose, looks good!
>
> But in your case, if you are building phosphor-ipmi-flash in SDK, it has
> nothing to do with .bbclass, and you got the above issue.
>
> One possible solution is to speicify the AR/RANLIB in configure.ac, see
> example in
> https://github.com/openbmc/phosphor-time-manager/blob/master/configure.ac#L9-L11
>
> I do not know if we have better solutions though.