Upstream Support for flto plugin with automake

[Patrick Venture]

On Wed, Jul 3, 2019 at 11:04 PM William Kennington <wak at google.com> wrote:
>
> 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.

I don't disagree, but specifying it explicitly is a really really
common pattern in openbmc.  Maybe it should be an anti-pattern?  I'll
leave that up to others, but if that's the way it's headed, I can
update the code I maintain.

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