On Mon, Nov 15, 2021 at 12:13:19PM -0700, Jeff Law wrote:
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).
Right. In fact, I had a brp-strip-lto which did precisely this and I did a Fedora build with that brp-strip-lto to get a set of packages that wanted to install a .o or .a composed from .o files. I did a build with that, but I don't have the results anymore.
What we perhaps could try (but not sure how far we could get) if we detect in an installed *.a or *.o GCC LTO bytecode, instead of erroring out and failing the build try to convert it to normal *.o file (for *.a recursively for each *.o file in there with LTO bytecode) - at least if debug info is emitted and there is DW_AT_producer, try to reconstruct gcc command line and gcc -r that_perhaps_slightly_massaged_command_line -o new.o old.o
Or if we recorded all command line options we care about into LTO bytecode (Optimization/Target options are recorded already on a per-function basis but I'm worried about others), just have a gcc driver mode that turns a non-fat LTO object into normal non-LTO object.
Jakub