On Wed, Feb 22, 2023 at 9:28 AM Florian Weimer <fwei...@redhat.com> wrote: > > * 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.
Ah, I didn't notice that - I think we only scan static archives for LTO bytecode and reject that case. Richard. > Florian >
