An idea for Portage to track LTO natively

[InBetweenNames]

It seems to me it would be very nice to track which packages are LTOed with Portage natively, similar to how multilib works. For example, we could have a USE_EXPAND variable called LTO which could be set to nolto, lto, or both at once.

LTO="lto" would mean that the package is built with slim LTO objects (the default in our configuration)
LTO="nolto" would mean that the package is built without LTO at all (nolto.conf).
LTO="lto nolto" would mean that the package is built with fat LTO objects (ltofat.conf).

A package which is built with exclusively nolto must link against other libraries with nolto set (either exclusively or inclusively with nolto or lto nolto respectively).

A package which is built lto may link against nolto or lto libraries. But if any library is lto nolto then a rebuild is triggered if the status of it changes, to force the linker to choose the right symbols.

I'm not sure how much work this would actually be, but it would be nice to have something like this to integrate LTO into Portage natively. Furthermore it would open the door to using other compilers as well, such as clang, to build your system. I'm a GCC guy myself, but I think the option should be there for users. If anyone has any thoughts or suggestions on this, please comment!

[darkbasic]

That would be really interesting, but sounds like a lot of work.

[InBetweenNames]

Indeed it does. I can't think of any other way to do this than to patch Portage itself. That said, I think a lot of existing infrastructure could be re-used. The hardest part would probably be learning Portage's internals. I do know there are extension mechanisms in there at least.

[darkbasic]

I'm pretty sure you can reuse lots of things, but from what I heard learning portage internals is far from being easy. Good luck, you have my fingers crossed :)

[InBetweenNames]

Fortunately for us, we have no deadlines :)

[InBetweenNames]

Alright, after seeing a few things I'm noticing a pattern. We could create a bashrc.d script for all GentooLTO related business, like LTO patches (instead of using /etc/patches) (#105), tracking which packages are compiled with LTO enabled (for dependency tracking), AutoFDO injection (#150), fixing mangled archives (#49), and -fwhole-program injection for packages that can be built as a unity build with meson (#151).

This would concisely solve these existing problems in a pluggable way, with functionality that could be enabled or disabled via USE flags on sys-config/ltoize.

Honestly, I can't believe I hadn't thought of this sooner. This is the whole point of bashrc.d after all :)

For this issue, it should also be possible for an ebuild to specify an LTO override directly where the *FLAGS themselves are not modified, and the ebuild itself ensures that the package is built with LTO in its own way (an LTO_CUSTOM variable, for example). For users who build their kernels with LTO, this could be particularly useful, and be trackable via portage.

I'm not sure if a USE_EXPAND variable will make sense for this, though. It will probably have to be grafted in manually as a "pseudo USE-flag", or something like that.

[ghost]

Hi. Does this mean that if A uses library B and B uses C (all three are lto), then upgrading C will automatically trigger subsequent rebuild of B and of A?

[InBetweenNames]

It should. Portage tracks these kinds of things through @preserved-rebuild. However, your system won't break it you don't rebuild.

…

On Wed, Apr 17, 2019 at 8:10 PM Jan Ziak ***@***.***> wrote: Hi. Does this mean that if A uses library B and B uses C (all three are lto), then upgrading C will automatically trigger subsequent rebuild of B and of A? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3VLDAJRVEKAM2P635NWDTPQ6353ANCNFSM4D3RP6JA> .