public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Charles Wilson <cwilson@ee.gatech.edu>
To: earnie_boyd@yahoo.com, cygwin@sourceware.cygnus.com
Subject: Re: Compiling Perl under b20.1
Date: Sat, 06 Mar 1999 12:07:00 -0000	[thread overview]
Message-ID: <36E18AF6.A967D7DA@ece.gatech.edu> (raw)
In-Reply-To: <19990306184033.2269.rocketmail@send1e.yahoomail.com>

Earnie Boyd wrote:

> ---Charles Wilson <cwilson@ee.gatech.edu> wrote:
> 8<
> > Now, all three of your patches address problems I didn't see; the
> main difference
> > between us being binary vs. text mounts. If that is the case, should
> these tests
> > be skipped for all cygwin (binary and text mount) or should the
> tests be fixed so
> > that they work for both binary and text mounts? I'm not sure if the
> second option
> > means hacking the test scripts, or hacking perl itself.
> >
> 8<
>
> IMHO, it seems that the easiest fix for this would be for perl to
> always open a script file in text mode processing.  Any file that can
> be potentially created by a human with an editor should be opened for
> text mode processing.

The issue is that the scripts in question directly open files themselves,
specifying O_RDWR | O_CREAT, etc. and test access to those files using
stat(). Thus the problem in these cases seem to be the scripts (and the
CYGWIN=ntea variable), not the perl exec itself.

Here's the three tests that failed for Sebastien but worked for me:

fs.t  FAILED tests 5,7,9,10
    each of these are testing access using stat(). I've got CYGWIN=ntea,
I'm guessing that Sebastien doesn't. Here is a representative part of
fs.t:

($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,
    $blksize,$blocks) = stat('c');
if ($Is_Dosish) {print "ok 7 # skipped: no link\n";}
elsif (($mode & 0777) == 0777) {print "ok 7\n";}
else {print "not ok 7\n";}

sdbm.t  FAILED test 2, 5-18
    test 2 seems similar to the stat() problems above.
    tests 5-18 seem to involve a hashtable written to a file (I think),
and the behavior of that hashtable is then tested. If the file is on a
text mount, and but is opened in O_BINARY mode (ie. due to the
USEMYBINMODE  patch) then you get problems?

anydbm.t FAILED test 2, 5-12
    test 2 is another stat() problem
    tests 5-12 are similar to the the failed tests in sdbm.t.

Sebastien - try setting ntea and building perl again - but watch out for
those eadata files. Setting ntea, and using only my patch (not your
changes) should get rid of the failures in fs.t, and the failures of
test2 in sdbm and anydbm. At least, that's my guess.


--Chuck





--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

WARNING: multiple messages have this Message-ID
From: Charles Wilson <cwilson@ee.gatech.edu>
To: earnie_boyd@yahoo.com, cygwin@sourceware.cygnus.com
Subject: Re: Compiling Perl under b20.1
Date: Wed, 31 Mar 1999 19:45:00 -0000	[thread overview]
Message-ID: <36E18AF6.A967D7DA@ece.gatech.edu> (raw)
Message-ID: <19990331194500.A2LI5sl-aLqm2wnU8UcQFYkIfkLVd3mArzvNAMxV4NY@z> (raw)
In-Reply-To: <19990306184033.2269.rocketmail@send1e.yahoomail.com>

Earnie Boyd wrote:

> ---Charles Wilson <cwilson@ee.gatech.edu> wrote:
> 8<
> > Now, all three of your patches address problems I didn't see; the
> main difference
> > between us being binary vs. text mounts. If that is the case, should
> these tests
> > be skipped for all cygwin (binary and text mount) or should the
> tests be fixed so
> > that they work for both binary and text mounts? I'm not sure if the
> second option
> > means hacking the test scripts, or hacking perl itself.
> >
> 8<
>
> IMHO, it seems that the easiest fix for this would be for perl to
> always open a script file in text mode processing.  Any file that can
> be potentially created by a human with an editor should be opened for
> text mode processing.

The issue is that the scripts in question directly open files themselves,
specifying O_RDWR | O_CREAT, etc. and test access to those files using
stat(). Thus the problem in these cases seem to be the scripts (and the
CYGWIN=ntea variable), not the perl exec itself.

Here's the three tests that failed for Sebastien but worked for me:

fs.t  FAILED tests 5,7,9,10
    each of these are testing access using stat(). I've got CYGWIN=ntea,
I'm guessing that Sebastien doesn't. Here is a representative part of
fs.t:

($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,
    $blksize,$blocks) = stat('c');
if ($Is_Dosish) {print "ok 7 # skipped: no link\n";}
elsif (($mode & 0777) == 0777) {print "ok 7\n";}
else {print "not ok 7\n";}

sdbm.t  FAILED test 2, 5-18
    test 2 seems similar to the stat() problems above.
    tests 5-18 seem to involve a hashtable written to a file (I think),
and the behavior of that hashtable is then tested. If the file is on a
text mount, and but is opened in O_BINARY mode (ie. due to the
USEMYBINMODE  patch) then you get problems?

anydbm.t FAILED test 2, 5-12
    test 2 is another stat() problem
    tests 5-12 are similar to the the failed tests in sdbm.t.

Sebastien - try setting ntea and building perl again - but watch out for
those eadata files. Setting ntea, and using only my patch (not your
changes) should get rid of the failures in fs.t, and the failures of
test2 in sdbm and anydbm. At least, that's my guess.


--Chuck





--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


  reply	other threads:[~1999-03-06 12:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-03-06 10:41 Earnie Boyd
1999-03-06 12:07 ` Charles Wilson [this message]
     [not found]   ` < 36E18AF6.A967D7DA@ece.gatech.edu >
1999-03-07 15:33     ` Sebastien Barre
1999-03-07 23:19       ` Charles Wilson
     [not found]         ` < 36E37A18.A15F8524@ece.gatech.edu >
1999-03-08  5:43           ` Sebastien Barre
1999-03-31 19:45             ` Sebastien Barre
1999-03-08  5:43           ` 'ntea' CHECK please (was Re: Compiling Perl) Sebastien Barre
1999-03-31 19:45             ` Sebastien Barre
1999-03-31 19:45         ` Compiling Perl under b20.1 Charles Wilson
1999-03-08  0:07       ` Charles Wilson
     [not found]         ` < 36E38547.482A019A@ece.gatech.edu >
1999-03-08  5:43           ` Sebastien Barre
1999-03-31 19:45             ` Sebastien Barre
1999-03-31 19:45         ` Charles Wilson
1999-03-31 19:45       ` Sebastien Barre
1999-03-31 19:45   ` Charles Wilson
1999-03-31 19:45 ` Earnie Boyd
  -- strict thread matches above, loose matches on Subject: below --
1999-03-07 18:53 Earnie Boyd
1999-03-31 19:45 ` Earnie Boyd
1999-03-05  6:22 Steven Zeil
1999-03-31 19:45 ` Steven Zeil
1999-03-04 18:06 Allan Peda
     [not found] ` < 36DF49C5.BDE486B0@interport.net >
1999-03-05  8:06   ` Sebastien Barre
1999-03-05 13:13     ` Charles Wilson
     [not found]       ` < 36E048F5.9B384A50@ece.gatech.edu >
1999-03-06  2:49         ` Sebastien Barre
1999-03-06 10:27           ` Charles Wilson
     [not found]             ` < 36E1739A.BEC6F38C@ece.gatech.edu >
1999-03-07 15:33               ` Sebastien Barre
1999-03-07 22:26                 ` Charles Wilson
1999-03-31 19:45                   ` Charles Wilson
1999-03-31 19:45                 ` Sebastien Barre
1999-03-31 19:45             ` Charles Wilson
1999-03-31 19:45           ` Sebastien Barre
1999-03-31 19:45       ` Charles Wilson
1999-03-31 19:45     ` Sebastien Barre
1999-03-31 19:45 ` Allan Peda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36E18AF6.A967D7DA@ece.gatech.edu \
    --to=cwilson@ee.gatech.edu \
    --cc=cygwin@sourceware.cygnus.com \
    --cc=earnie_boyd@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).