Fri 14 Jan 2011 11:43:58 AM UTC, comment #7:
For t510, t511, we inhibit file read-only checks for cygwin (as determined by ‘uname -s’).
This is arguably a slippery slope, and masks latent failures in some future situation where woe uses a unixoid filesystem, but for the time being, it lets us close this bug and do other things.
Marking this "closed".
|
Fri 14 Jan 2011 11:18:33 AM UTC, comment #6:
Yeah, letting the OS do its thing was the right approach. Of the six failing tests previously, four now pass. Only two remain: those that check for RCS file writeability (t510, t511).
|
Fri 14 Jan 2011 10:23:26 AM UTC, comment #5:
Indeed, ‘find_peer_prog’ was the culprit (specifically ‘find_in_path’ from gnulib). After trying to tease ‘find_in_path’ towards DTRT, a brief peek at its source reveals that under cygwin, there is never a chance for it to DTRT:
However, it was not a total loss. In our meanderings, we did manage to discover ‘EXEEXT’ and a way to propagate that to the C code (commit d7b98f429), so we use that with the current approach (commit 24aa53ad0) in hopes that the OS can DTRT with just a little help. We'll see... (hydra seems to have created the tarball ok).
|
Thu 13 Jan 2011 10:51:36 AM UTC, comment #4:
OK, woe32 ucontext library (LGPL) now embedded:
So far so good; RCS builds under Cygwin. But there are problems:
At the latter link, there appear to be several core dumps for co, rcsdiff, and rcsmerge. These are all commands that call other RCS commands, so i suspect the problem is either in ‘find_peer_prog’ or the subprocess spawning mechanism. I hope it is not the latter. Unfortunately, i have no way to extract useful information from those core dumps, so it looks like some defensive assert-type code is indicated. Sigh.
|
Tue 11 Jan 2011 02:10:23 PM UTC, comment #3:
Oops, spoke too soon: gnulib DOES NOT have ucontext.h; the available documentation (http://www.gnu.org/software/hello/manual/gnulib/ucontext_002eh.html) indicates that the header and module would still need to be written by Someone.
|
Tue 11 Jan 2011 02:03:47 PM UTC, comment #2:
On the other hand, gnulib does have a ucontext.h (which provides ucontext_t), but no module specifically for that header. So, a cleaner approach would be to either figure out how to use that file sans module, or contribute such a module to gnulib (and then use it).
|
Tue 11 Jan 2011 01:42:32 PM UTC, comment #1:
OK, looks like indeed RCS has been available for cygwin for some time now, so its inability to build there is a regression.
Severity now "blocker".
It looks like ucontext_t for cygwin is achievable via http://www.codeproject.com/KB/threads/ucontext.aspx (LGPL library), so it's just a matter of bundling / configuration.
Status now "in progress".
|
Sat 08 Jan 2011 03:29:58 PM UTC, original submission:
I don't know if RCS 5.7 worked with cygwin, but certainly the current RCS 5.7.95 (pretest for 5.8) does not. This is because we now use ucontext_t, which cygwin does not provide. I don't think gnulib provides it, either.
I'm marking this "important" and "need info" because if indeed 5.7 DID work with cygwin, then this represents a regression.
Overall, however, woe32 support is very low priority, so if it turns out 5.7 never did work with cygwin, then we can change its status to "wish" and "postponed".
FWIW, this issue was brought into focus by the hydra continuous build system. The latest cygwin build (which failed because of ucontext_t lack) is at:
(For now, we have removed cygwin from the list of builds.)
|