* Tom Stellard:
On 11/15/21 05:06, Florian Weimer wrote:
In the future, we might want to switch GCC not to generate both object code and LTO representation during the build process. For most packages, dual generation is not necessary because no relocatable object files for static linking are included in the RPM (neither as separate ET_REL .o files, nor in static .a archives). Final (non-relocatable) links of any kind will generate object code, so only LTO representation needs to be written by GCC. But in case relocatable object files are produced by the package (e.g., for a -static subpackage for static linking), it is necessary to generate object code for relocatable files as well. The reason is that only object code (not LTO representation) is a stable format, and it's the only way to achieve cross-toolchain linking. The way I envisioned LTO-only building for GCC was to replace the brp-strip-lto script https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/brp-strip-lto with somehting that errors out (fails the build) if any relocatable object files (.o) or static archives (.a) by default, and stop producing object code by default, only LTO representation. If a special redhat-rpm-config flag is set, brp-strip-lto comes back, and GCC is configured to produce both object code and LTO representation (basically what we have today).
If we produced LTO only static archives, does this mean end-users who want to use them would need to build their applications with LTO enabled?
No, when building for LTO-only mode, it would be a hard error (build failure) if an RPM is built that contains .o or .a files. So the situation that an end users sees LTO only static archives after installing a -devel RPM package cannot actually happen.
Thanks, Florian