From: gsar AT engin DOT umich DOT edu (Gurusamy Sarathy) Subject: Re: Another success report for cygwin32/perl5.003_17 28 Dec 1996 21:41:08 -0800 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199612290528.AAA18518.cygnus.gnu-win32@aatma.engin.umich.edu> Original-To: Ilya Zakharevich Original-cc: gsar AT engin DOT umich DOT edu (Gurusamy Sarathy), Perl-Win32-Porters AT ActiveWare DOT com, gnu-win32 AT cygnus DOT com In-reply-to: Your message of "Sat, 28 Dec 1996 03:32:11 EST." <199612280832 DOT DAA00728 AT monk DOT mps DOT ohio-state DOT edu> Original-Sender: owner-gnu-win32 AT cygnus DOT com Ilya Zakharevich writes: >Gurusamy Sarathy writes: >> * exec of symlinked executables fails in gnuwin32 V17.1, so >> ./t/perl.exe must be a copy of ./perl.exe, not a symlink >> (do this manually before running `make test`) > >Are there symlinks on NT (or is it NT+sygn?) ? If no, just set ln=cp >in hints file. Cygwin32 provides symlinks via the DLL. Seem to be slightly flakey though, so I did as you suggest. >> You should have a mostly functional perl (see description of test >> failures below). There does exist a serious problem with the -i >> command-line flag (inplace editing of files). This seems to wipe out >> the file, so DO NOT do that. Most other failures are due to >> UNIXisms/bugs in stat(). > >What you describe is very similar to what I had in my first OS/2 >attempts. You forgot to set -DDOSISH. That fixes the -i flag trouble, but introduces a few new ones (since Cygwin32 is probably more unixish than dosish). I have a copy now that fails exactly the same 12 tests using either dosish.h or unixish.h. 8 of them have to do with stat() fields. >> op/exec...........FAILED on test 6 >> Total tests: 8 >> Failed: 1 (6) >> The return value of system("not_a_command") seems messed up. >I hardwire the expected value (2^16-1 ?) into os2.c's do_spawn. Cygwin32 is supposed to emulate the behavior of UNIX waitpid(), so I'd rather the bug is fixed there. >> lib/sdbm..........FAILED on test 2 >> sdbm store returned -1, errno 13, key "102" at lib/sdbm.t line 104. >> Total tests: 12 >> Failed: 9 (2 5-12) >> This seems to fail due to a permissions problem. >Is there O_BINARY on Cygwin32? Yup, adding O_BINARY in sdbm.c fixes all but one failure (that one has to do with what stat() thinks the permissions are). For the benefit of the Cygnus folks, here's a summary of the problems I have had on NT 3.51 (SP3). I think these point to bugs that must be fixed in the kit: * Buggy sigpipe delivery. If the read end of the pipe is closed prematurely, the write end does not seem to receive SIGPIPE properly. One the other hand, using C seems to deliver the signal just fine. * The status word that waitpid() and wait() return seem to be buggy. WEXITSTATUS() is not properly set when the child terminates abnormally. * calling vfprintf() results in a coredump. * O_NONBLOCK (or O_NDELAY and its SysV clone) appear in the headers, but don't seem to be implemented properly on pipe fds. For instance, the Configure test to determine if a read() on a dry O_NONBLOCK fd returns EAGAIN, just hangs forever on the read(). Is Cygwin32 ever going to be POSIX compliant? * forking fails if the executable was actually a symlink and not a regular file. Similar problems seem to exist with the various -X file tests on symlinks. * lowercase names given to setenv()/getenv() don't seem to work. Perhaps the toolkit should normalize names internally to uppercase? * stat() incompatibilities arising from the dummy chmod(), the nlink field, and the cooked up mtime/atime/ctime fields. Some bugs that I came across in the supplied tools: * `/bin/rm -f foobar` fails to delete foobar if it is held open by a process. I looks like a flaw in the design of the NT filesystem (since all other means to delete a file are similarly defeated). * Oftentimes, if I have killed a make run with frantic punching of ^C's, NT seems to think that files are held open by the processes that got interrupted (and won't let me delete those files). ps seems to share the same bewilderment (in that it will claim killed/dead processes are still active). * patch.exe does not work (yes, I do have /tmp and /var/tmp). It renames the original to *.orig and does not write a new file in its place (perhaps the renaming of the tmpfile is failing somehow). * I sometimes get "Out of free slots!" (or similar) errors. I'm on a machine with 32MB RAM. Hope all this is of someuse to someone somewhere somewhen. - Sarathy. gsar AT engin DOT umich DOT edu - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".