Richard, regarding your first mail, I'm afraid I'm not sure what you mean. Isn't this exactly the section of configure.ac that handles CC_FOR_TARGET? The Makefile is dumb and just passes the autoconf-substituted value for CC_FOR_TARGET directly through.
(I agree the patch will need some tweaks to work for all the build/host/target combination possibilities.) On Fri, Jan 25, 2019 at 12:18 PM Joseph Myers <jos...@codesourcery.com> wrote: > > On Fri, 25 Jan 2019, Nikhil Benesch wrote: > > > I am attempting to convince GCC to build target libraries with link-time > > optimizations enabled. I am primarily interested in libgo, but this > > discussion > > Note that as far as I know issues with host-dependencies of LTO bytecode > (bug 41526) may still exist, so this wouldn't work with Canadian cross > compilers. Ack, thanks for the heads up. For now I'm only interested in turning on LTO during native builds. > > I have a simple patch to the top-level configure.ac that resolves the issue > > by > > teaching the build system to use the gcc-ar and gcc-ranlib wrappers which > > were > > built earlier and know how to pass the linker plugin to the underlying > > ar/ranlib > > commands. The patch is small enough that I've included it at the end of this > > email. > > Will those wrappers properly wrap round tools for the target that were > configured using --with-build-time-tools? That's a good question. I think the answer is no. I'll investigate further. On Fri, Jan 25, 2019 at 12:39 PM Richard Biener <richard.guent...@gmail.com> wrote: > > On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers > <jos...@codesourcery.com> wrote: > >On Fri, 25 Jan 2019, Nikhil Benesch wrote: > > > >> I am attempting to convince GCC to build target libraries with > >link-time > >> optimizations enabled. I am primarily interested in libgo, but this > >discussion > > > >Note that as far as I know issues with host-dependencies of LTO > >bytecode > >(bug 41526) may still exist, so this wouldn't work with Canadian cross > >compilers. > > I was expecting the LTO byte code not to be retained in the built libraries. > > >> I have a simple patch to the top-level configure.ac that resolves the > >issue by > >> teaching the build system to use the gcc-ar and gcc-ranlib wrappers > >which were > >> built earlier and know how to pass the linker plugin to the > >underlying ar/ranlib > >> commands. The patch is small enough that I've included it at the end > >of this > >> email. > > > >Will those wrappers properly wrap round tools for the target that were > >configured using --with-build-time-tools? >
