bugGNU RCS - Bugs: bug #32078, cygwin not supported for 5.8

 
 

bug #32078: cygwin not supported for 5.8

Submitter:  Thien-Thi Nguyen <ttn>
Submitted:  Sat 08 Jan 2011 03:29:58 PM UTC
   
 
Category:  None Severity:  5 - Blocker
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  ttn
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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

Thien-Thi Nguyen <ttn>
Group administrator
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).

Thien-Thi Nguyen <ttn>
Group administrator
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:


const char *
find_in_path (const char *progname)
{
#if defined _WIN32 || defined __WIN32__ || defined __CYGWIN__ || defined __EMX__ || defined __DJGPP__
  /* Win32, Cygwin, OS/2, DOS */
  /* The searching rules with .COM, .EXE, .BAT, .CMD etc. suffixes are
     too complicated.  Leave it to the OS.  */
  return progname;
#else
  /* Unix */
  [...]
}


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

Thien-Thi Nguyen <ttn>
Group administrator
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.

Thien-Thi Nguyen <ttn>
Group administrator
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.

Thien-Thi Nguyen <ttn>
Group administrator
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).

Thien-Thi Nguyen <ttn>
Group administrator
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".

Thien-Thi Nguyen <ttn>
Group administrator
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.)

Thien-Thi Nguyen <ttn>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttn (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-01-14 ttn StatusConfirmed Fixed
    2011-01-14 ttn StatusIn Progress Confirmed
        Open/ClosedOpen Closed
    2011-01-11 ttn Severity4 - Important 5 - Blocker
        StatusNeed Info In Progress

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code