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....
