On 01 May 2007 18:43, Brian Dessent wrote: > Aaron Gray wrote: >> >>> JFTR, the patch is only required for building gcc, not for building >>> winsup. As Brian says, we'll deal with any winsup problems on the cygwin >>> list. >> >> Sorry for adding to the confusion as I am actually trying to build GCC CVS >> on Cygwin :)
(Well, not if you're messing around in the winsup dir you aren't!) Anyway, for that case, you do indeed need to patch your local stdio.h; you don't need to worry about building a whole fresh winsup/newlib/cygwin, just hack it about directly in /usr/include. >> Can you give me any indication of when the next version of Cygwin will be, >> and if it will have latest GCC from CVS ? > > Those are two unrelated questions; Cygwin is not a monolithic thing, it > is like a distribution with packages. The version of the Cygwin DLL is > unrelated to the version of gcc that is packaged. > > To answer the former, that's up to the Cygwin maintainers, but probably > not any time soon. The stdio.h thing is trivial to work around, you > don't need to even touch winsup or anything. Just take the stdio.h from > newlib CVS and stick it in /usr/include. You don't have to rebuild > Cygwin or anything. And just for completeness I'll mention that when the next release does happen, it will come with a new version of /usr/include/stdio.h, that will have the patch built in. > To answer the second question, that's a much different question. I > don't think the Cygwin gcc maintainer would ever package a development > (non-released) version of gcc. Well, if there were *exceptional* circumstances that made it *very* worthwhile, I might spin a release from CVS, but on the whole HEAD is too unstable and experimental for production use. > And on top of that, gcc v4.x is very > immature on win32 and still have a number of unresolved problems. Thus > both the MinGW project and the Cygwin project still only offer binaries > of 3.4.x. It remains to be seen when gcc v4 will stabilize on win32. > Danny Smith has said that the MinGW project will release a packaged > 4.2.0 when it is released, but there will likely be a lot of local MinGW > patches -- both projects rely on heavily patched sources to fix > regressions that can't/won't/haven't been addressed upstream. What he said. As for cygwin, I might not go for a 4.2.0 release straight away; I think I'll wait until we've got the trunk sorted out with the new 4.x features (dwarf eh, shared libgcc etc), then look at backporting them (as a cygwin-local patchset) to whichever is the most recent stable release at that time. cheers, DaveK -- Can't think of a witty .sigline today....