http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> --- Joseph, thank you for those precisions, I hadn't realized the width of the problem. Similarly, on my Debian multiarch machine, when I cross-compile for arm, I use a libgcc.a that was built natively on arm, so that would break as well. I believe LTO streams come with a format version, and gcc checks that it understands this version before proceeding (and gives an error otherwise). Maybe it could also embed the host triple and check that it is the same. And possibly downgrade the errors to warnings as long as we have a fat object and can fall back to regular linking. I understand this all makes it too early for LTO by default. I guess a configure option --enable-lto-libraries that defaults to "no" would still make sense, with suitably dire warnings in the doc.
