* Richard Biener: > On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> > wrote: >> >> Can we use the COMMON symbol __gnu_lto_slim to detect >> -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker >> plugin)? > > Yes.
Great, thanks. >> We currently build the distribution with -ffat-lto-objects, and I want >> to switch away from that. Packages will need to opt in to >> -ffat-lto-objects if static objects they build escape the buildroot. >> And to make sure that this opt-in happens, I want to fail the build if >> there would be any -fno-fat-lto-objects objects leaking. > > For SUSE we're checking that no LTO bytecode leaks instead, thus we check > for __gnu_lto_v? (I think). The reason is that even for static libraries > we do not want to ship LTO bytecode. We build with -ffat-lto-objects, and this means we can create perfectly fine object files by stripping the LTO data: <https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/brp-strip-lto> This means that so far, we only had to fix LTO compilation problems in the packages, but not teach individual packages about LTO and non-LTO object files. Of course it's wasteful because few packages actually install the object files (without a final link into a program or shared object), and that's what I want to fix. Florian
