This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: configure.{in -> ac} rename (commit 35eafcc71b) broke in-tree binutils building of gcc

> On Jul 15, 2015, at 9:20 AM, Alan Modra <> 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/ looks for
>> 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
>> 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> 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. 


> -- 
> Alan Modra
> Australia Development Lab, IBM

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]