On 5/28/12 6:54 PM, Jeremy Huntwork wrote:
> Maybe let's wait before updating anything again, just to be 100% certain
> on what the right path is here, and I'll try to reach out to upstream in
> the meantime to see if someone there is willing to give me an answer we
> can work with.
Well, I posted
On 5/28/12 6:37 PM, Matt Burgess wrote:
> On Mon, 2012-05-28 at 18:16 -0400, Jeremy Huntwork wrote:
>> On 5/28/12 6:15 PM, Jeremy Huntwork wrote:
>>> It's probably safer to add back the command that disables this script
>>> but just make sure that our explanation for it is accurate.
>>
>> Oh, and s
On Mon, 2012-05-28 at 18:16 -0400, Jeremy Huntwork wrote:
> On 5/28/12 6:15 PM, Jeremy Huntwork wrote:
> > It's probably safer to add back the command that disables this script
> > but just make sure that our explanation for it is accurate.
>
> Oh, and sorry for the trouble here, I realize I was t
On 5/28/12 6:15 PM, Jeremy Huntwork wrote:
> I think we may have been too quick on the draw with removing this
> command entirely. The reason being that this script was originally added
> into gcc to "fix" non-ANSI headers in various packages.
>
> http://gcc.gnu.org/viewcvs/trunk/fixincludes/README
On 5/9/12 4:29 PM, Matt Burgess wrote:
> On Wed, 2012-05-09 at 16:24 -0400, Jeremy Huntwork wrote:
>
>> I'll dig a bit and get back to you.
>
> Note that I'm busy digging too. Having fixincludes run in chapter 5
> looks safe; GCC only searches for headers under /mnt/lfs/tools/include
> or /tools/i