Ready for gcc-4 & cleaning up binutils source delete or not.
theoldfellow at gmail.com
Sat Apr 16 23:05:54 PDT 2005
Matthew Burgess wrote:
> TheOldFellow wrote:
>> However it's the LFS new technology gestation period that gets me down.
>> And I only have i686 boxes :-(
> This isn't meant to sound as harsh as it's going to.
I bet my skin is tougher than yours!
But, if you don't
> like the length of time it takes to get new technology into LFS then
> post *patches* to the XML book sources, not scripts :)
But that means I have to make all that xml stuff work first! :-)
Seriously, I'm not quite at that point yet, but I'll will get there soon.
> Additionally, the script you posted does more than just bumps gcc up to
> version 4.0.0, there's some other build changes in there too.
Yes, my intention was to show some alternatives and provoke a dicussion.
I do not propose that you just copy the script - the LFS aims are quite
different from Greg's - no reason you can't examine them for good ideas
> things easier to review and to understand and assess the impact of, I
> much prefer seeing scripts/patches/discussions on one specific topic at
> a time. I'm not saying the other changes won't be useful and/or
> necessary, just that they are probably/possibly orthogonal to upgrading
> the compiler.
Good point. I accept that. There were two points that I wanted you to
take on board: 1) The dumpspecs/-specs= approach, even for gcc-3X. 2)
Getting rid of the 'keep binutils sources around' which so confuses the
> IIUC, the only thing that is required to bump gcc up to 4.0.0 is deal
> with the lack of a specs file (-dumpsecs resolves that one) and the
> patches dealing with invalid C rejected by the new compiler. I'm
> willing to be proved wrong on this though, of course :)
The issue isn't just dumpspecs but also how you feed the altered specs
back to the compiler.
There are remarkably few packages that need patching as far as I found.
I'm making a list. Some major projects are already releasing
gcc-4-ready versions, gtx+/glib last week for instance, because Fedora
Core 4 is driving them. But I think your analysis is broadly correct.
More information about the lfs-dev