On Tue, Jul 14, 2015 at 7:00 PM, <pins...@gmail.com> wrote: > > > >> On Jul 15, 2015, at 9:20 AM, Alan Modra <amo...@gmail.com> wrote: >> >>> On Tue, Jul 14, 2015 at 10:13:06AM +0100, Jan Beulich wrote: >>> Alan, gcc maintainers, >>> >>> I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead >>> of 2.24 as I had in use with 4.9.2) to fail in rather obscure ways. Quite >>> a bit of digging resulted in me finding that gcc/configure.ac looks for >>> configure.in in a number of binutils subtrees. >> >> I haven't used combined tree builds of binutils+gcc for a very long >> time, so this issue wasn't on my radar at all, sorry. >> >>> Globally replacing >>> configure.in by configure.[ai][cn] appears to address this, but I'm not >>> sure whether that would be an acceptable change >> >> Certainly sounds reasonable. >> >>> (there doesn't seem >>> to be a fix for this in gcc trunk either, which I originally expected I >>> could >>> simply backport). >> >> The configure.in->configure.ac rename happened over a year ago so I >> guess this shows that not too many people use combined binutils+gcc >> builds nowadays. I've always found combined binutils+gcc builds not >> worth the bother compared to simply building and installing binutils >> first, as Jim suggests. > > > Combined builds are very useful for doing Candian crosses. Though it might > just because my build script has been doing a combined build now for 5 years. > Also I noticed it was broken and ignored it as my script did not break, only > when I did a native build did it break. >
We should fix gcc/configure.ac. -- H.J.
