Upstream Support for flto plugin with automake

[Patrick Venture]

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.

Thanks, I realize that.  I only happen to notice the issue when
building for SDK that I needed to specify it, but I didn't include the
bblcass for bitbake -- so in that case I didn't need it.  That drew my
attention to not needing the bbclass anywhere.

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