Upstream Support for flto plugin with automake

[Lei YU]

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.