Using __gnu_lto_slim to detect -fno-fat-lto-objects

Richard Biener richard.guenther@gmail.com
Wed Feb 22 08:58:24 GMT 2023


On Wed, Feb 22, 2023 at 9:28 AM Florian Weimer <fweimer@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
>


More information about the Gcc mailing list