Mail Archives: cygwin/1997/01/20/18:29:43
nick AT ni-s DOT u-net DOT com (Nick Ing-Simmons) writes:
>
> Tom Christiansen <tchrist AT perl DOT com> writes:
> >Perlnews (alas) reads:
> >
> > Perl5.004 builds out of the box on Unix, Plan9, LynxOS,
> > VMS, OS/2, QNX, and AmigaOS.
> >
> >Nick, didn't you discover that one could build perl in the Win32
> >environment iff some Gnu (Cygnus?) build environment were included?
>
> Not me,
> (Our (work) Win32 machine was an evaluation box and its license has expired).
> but I to think someone did.
>
> >
> >--tom
Yes perl5 builds under Cygnus's gnuwin32 environment for NT and Win95
with a small patch mentioned below (don't know if this has made it into
5.004). I get 85% test compliance. most of the problems come from fstat
mismatches.
I have attached the email history I saved below.
I have duplicated the results with perl 5.00319 (with one added bug not
mentioned below - io/tell (test 7 fails))
this is really *super* work from Cygnus with the added benefit of very
little impact to the perl source.
-GSM
--------------
perl5.003_17 compiles with minimal changes on WindowsNT
using the freely available Cygnus Win32 toolkit (version 17.1).
The toolkit is available at "http://www.cygnus.com/misc/gnu-win32".
I have seen one other report to this effect, but the details
were sketchy. This attempt hopefully provides more info.
Important things to note:
* apply patch with patch -p0 -N < this_file
* Run Configure:
- choose "gnuwin32" for system type
- $libs must have -lcygwin (hintsfile adds this, so accept default)
- must provide path to libcygwin.a, libc.a etc., when Configure
asks for extra libraries (the default in the hintsfile assumes
you have mounted gnu-win32 in /usr)
- accept defaults everywhere else
* make
* 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`)
* make test
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().
Mucho thanks to Cygnus for gnu-win32.
Enjoy,
- Sarathy.
gsar AT engin DOT umich DOT edu
----------------------------------8<--------------------------------------
*** Makefile.SH.dist Sat Dec 28 00:07:22 1996
--- Makefile.SH Sat Dec 28 00:25:32 1996
***************
*** 311,316 ****
--- 311,317 ----
@sh ./makedir lib/auto
@echo " AutoSplitting perl library"
@./miniperl -Ilib -e 'use AutoSplit; \
+ $$AutoSplit::CheckModTime = 0 if $$^O eq "cygwin32nt"; \
autosplit_lib_modules(@ARGV)' lib/*.pm lib/*/*.pm
# Take care to avoid modifying lib/Config.pm without reason
*** pp_sys.c.dist Wed Dec 31 18:59:10 1969
--- pp_sys.c Fri Dec 27 20:46:39 1996
***************
*** 3921,3927 ****
PP(pp_spwent)
{
dSP;
! #ifdef HAS_PASSWD
setpwent();
RETPUSHYES;
#else
--- 3921,3928 ----
PP(pp_spwent)
{
dSP;
! /* CYGWIN32 is missing setpwent(), (but has the others!) */
! #if 0
setpwent();
RETPUSHYES;
#else
*** /dev/null Sat Dec 28 01:12:48 1996
--- hints/gnuwin32.sh Fri Dec 27 20:52:34 1996
***************
*** 0 ****
--- 1,23 ----
+ #! /bin/sh
+ # gnuwin32.sh - hintsfile for building perl on Windows NT using the
+ # Cygnus Win32 Development Kit.
+ # See "http://www.cygnus.com/misc/gnu-win32/" to learn about the kit.
+ #
+
+ path_sep=\;
+ exe_ext='.exe'
+ firstmakefile='GNUmakefile'
+
+ if test -f $sh.exe; then sh=$sh.exe; fi
+
+ startsh="#!$sh"
+
+ cc='gcc'
+ ld='gcc'
+
+ usrinc='/usr/include /usr/i386-cygwin32/lib'
+ libs='-lcygwin -lm -lc'
+
+ # these are not yet supported
+ #so='dll'
+ #i_dlfcn='define'
bash$ ./perl -Ilib -V
Summary of my perl5 (5 patchlevel 3 subversion 17) configuration:
Platform:
osname=cygwin32nt, osvers=3.51, archname=i586-cygwin32nt
uname='cygwin32nt pujyam 3.51 17.4 i586 '
hint=recommended, useposix=true, d_sigaction=define
bincompat3=n useperlio= d_sfio=
Compiler:
cc='gcc', optimize='-g', gccversion=cygnus-2.7.2-961023
cppflags='-DDEBUGGING'
ccflags ='-DDEBUGGING'
stdchar='char', d_stdstdio=, usevfork=false
voidflags=15, castflags=0, d_casti32=define, d_castneg=define
intsize=4, alignbytes=4, usemymalloc=y, randbits=31
Linker and Libraries:
ld='ld', ldflags =''
libpth=/usr/lib /usr/i386-cygwin32/lib
libs=-lcygwin -lm -lc
libc=/usr/i386-cygwin32/lib/libc.a, so=none
useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_none.xs, dlext=none, d_dlsymun=, ccdlflags=''
cccdlflags='', lddlflags=''
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING
Built under cygwin32nt
Compiled at Dec 28 1996 00:34:44
@INC:
lib
/usr/local/lib/perl5/i586-cygwin32nt/5.00317
/usr/local/lib/perl5
/usr/local/lib/perl5/site_perl/i586-cygwin32nt
/usr/local/lib/perl5/site_perl
.
Here are some annotations on the failed tests:
io/fs.............FAILED on test 1
Total tests: 26
Failed: 7 (1 4 5 7 9 10 18)
Skipped: 23-26
All of these have to do with the return values of stat(). The tests
are too UNIX-specific.
io/inplace........FAILED on test 1
cat: .a.bak: No such file or directory
cat: .b.bak: No such file or directory
cat: .c.bak: No such file or directory
Total tests: 2
Failed: 2 (1 2)
Creation of the backup file seems to fail completely.
>>BUG-ALERT! With an empty $^I, the file is totally wiped out!<<
io/pipe...........FAILED on test 7
Total tests: 8
Failed: 1 (7)
Cygwin32 seems to have buggy SIGPIPE handling.
op/exec...........FAILED on test 6
Total tests: 8
Failed: 1 (6)
The return value of system("not_a_command") seems messed up.
op/groups.........ok
/usr/bin/groups: /usr/bin/groups: No such file or directory
Total tests: 2
Failed: 0
"/usr/bin/groups" must be "/usr/bin/groups.exe" to avoid the error message.
op/magic..........FAILED on test 1
Total tests: 6
Failed: 1 (1)
Looks like lowercase envnames like in $ENV{"foo"} don't get set in Cygwin32.
Changing the name to $ENV{"FOO"} makes it work.
op/split..........FAILED on test 11
Total tests: 14
Failed: 1 (11)
`perl -D1024 -e ''` seems to cause a coredump.
op/stat...........FAILED on test 3
ls: Op.stat.tmp: Permission denied
Total tests: 56
Failed: 5 (3 4 9 20 35)
3 and 4 are UNIX specific stat() failures.
9 and 35 are due to unimplemented setuid() et al. in Cygwin32.
20 is due to bogus chmod() in Cygwin32.
lib/anydbm........FAILED on test 2
sdbm store returned -1, errno 13, key "102" at lib/anydbm.t line 99.
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.
lib/filecopy......FAILED on test 8
Died at lib/filecopy.t line 80.
Total tests: 11
Failed: 3 (8 9 11)
These seems to be caused by a dysfunctional File::Copy::move().
lib/findbin.......FAILED on test 1
readdir(../../../..): No such file or directory at ../lib/Cwd.pm line 105.
Total tests: 1
Failed: 1 (1)
readdir() from the root directory seems to fail.
lib/io_pipe.......FAILED on test 5
Total tests: 6
Failed: 1 (5)
Cygwin32 seems to have buggy SIGPIPE handling.
lib/parsewords....FAILED on test 1
Can't locate auto/Text/ParseWords/shellwords.al in @INC at lib/parsewords.t line 12
This is fixed after forcing autosplit of Text/ParseWords.pm.
Autosplitting failed due to bogus stat().
C<$AutoSplit::CheckModTime = 0;> before autosplitting in the Makefile
fixes it.
lib/searchdict....FAILED on test 1
Total tests: 3
Failed: 1 (1)
Search::Dict.pm relies on stat(), incompatible in Cygwin32.
Skipped test-suites:
lib/db-btree......skipping test on this platform
lib/db-hash.......skipping test on this platform
lib/db-recno......skipping test on this platform
lib/gdbm..........skipping test on this platform
lib/io_sock.......skipping test on this platform
lib/io_udp........skipping test on this platform
lib/locale........FAILED on test 0
Can't locate POSIX.pm in @INC at lib/locale.t line 11.
BEGIN failed--compilation aborted at lib/locale.t line 11.
lib/ndbm..........skipping test on this platform
lib/odbm..........skipping test on this platform
lib/posix.........skipping test on this platform
lib/socket........skipping test on this platform
......................................
To leave this list, send an email message to ListManager AT ActiveWare DOT com
with the body:
leave Perl-Win32-Porters
NTList compliments of Internet Shopper
http://www.net-shopper.co.uk/software/ntmail/ntlist.htm
-------
-------------------------------------
X-ListMember: gmarzot AT BayNetworks DOT com [Perl-Win32-Porters AT ActiveWare DOT com]
Gurusamy Sarathy writes:
>
>
> perl5.003_17 compiles with minimal changes on WindowsNT
> Important things to note:
>
> * apply patch with patch -p0 -N < this_file
> * Run Configure:
> - choose "gnuwin32" for system type
> - $libs must have -lcygwin (hintsfile adds this, so accept default)
> - must provide path to libcygwin.a, libc.a etc., when Configure
> asks for extra libraries (the default in the hintsfile assumes
> you have mounted gnu-win32 in /usr)
There is some code in hints/os2.sh to find libraries, one can borrow
it.
> - accept defaults everywhere else
> * make
> * 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.
> * make test
>
> 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.
> io/inplace........FAILED on test 1
> cat: .a.bak: No such file or directory
> cat: .b.bak: No such file or directory
> cat: .c.bak: No such file or directory
>
> Total tests: 2
> Failed: 2 (1 2)
> Creation of the backup file seems to fail completely.
> >>BUG-ALERT! With an empty $^I, the file is totally wiped out!<<
-DDOSISH.
> io/pipe...........FAILED on test 7
>
> Total tests: 8
> Failed: 1 (7)
> Cygwin32 seems to have buggy SIGPIPE handling.
>
> 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.
> lib/anydbm........FAILED on test 2
> sdbm store returned -1, errno 13, key "102" at lib/anydbm.t line 99.
> 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?
> lib/filecopy......FAILED on test 8
> Died at lib/filecopy.t line 80.
>
> Total tests: 11
> Failed: 3 (8 9 11)
> These seems to be caused by a dysfunctional File::Copy::move().
Bug in filecopy.t. I fixed it in my last patch.
Ilya
......................................
To leave this list, send an email message to ListManager AT ActiveWare DOT com
with the body:
leave Perl-Win32-Porters
NTList compliments of Internet Shopper
http://www.net-shopper.co.uk/software/ntmail/ntlist.htm
>perl5.003_17 compiles with minimal changes on WindowsNT
>using the freely available Cygnus Win32 toolkit (version 17.1).
>The toolkit is available at "http://www.cygnus.com/misc/gnu-win32".
>I have seen one other report to this effect, but the details
>were sketchy. This attempt hopefully provides more info.
Good news!
I tried with NTrigue but machine was sick.
>
>Important things to note:
>
> * apply patch with patch -p0 -N < this_file
>*** pp_sys.c.dist Wed Dec 31 18:59:10 1969
>--- pp_sys.c Fri Dec 27 20:46:39 1996
>***************
>*** 3921,3927 ****
> PP(pp_spwent)
> {
> dSP;
>! #ifdef HAS_PASSWD
> setpwent();
> RETPUSHYES;
> #else
>--- 3921,3928 ----
> PP(pp_spwent)
> {
> dSP;
>! /* CYGWIN32 is missing setpwent(), (but has the others!) */
>! #if 0
> setpwent();
> RETPUSHYES;
> #else
I hope this is a temporary measure - we want a patch which will
allow sources to build either way.
I guess gnuwin32.sh could add -DNO_SETPWENT ...
......................................
To leave this list, send an email message to ListManager AT ActiveWare DOT com
with the body:
leave Perl-Win32-Porters
NTList compliments of Internet Shopper
http://www.net-shopper.co.uk/software/ntmail/ntlist.htm
-------------------------------------
X-ListMember: gmarzot AT BayNetworks DOT com [Perl-Win32-Porters AT ActiveWare DOT com]
Gurusamy Sarathy wrote:
> 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().
Great.
The -I bug, I remember as being active under the DOS versions of perl4.
I vaguely recall there was a patch (by Lloyd Zussman?) issued.
<chaim>
......................................
To leave this list, send an email message to ListManager AT ActiveWare DOT com
with the body:
leave Perl-Win32-Porters
NTList compliments of Internet Shopper
http://www.net-shopper.co.uk/software/ntmail/ntlist.htm
-------------------------------------
X-ListMember: gmarzot AT BayNetworks DOT com [Perl-Win32-Porters AT ActiveWare DOT com]
Ilya Zakharevich <ilya AT math DOT ohio-state DOT edu> 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<kill("PIPE", $$)>
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
......................................
To leave this list, send an email message to ListManager AT ActiveWare DOT com
with the body:
leave Perl-Win32-Porters
NTList compliments of Internet Shopper
http://www.net-shopper.co.uk/software/ntmail/ntlist.htm
-------------------------------------
X-ListMember: gmarzot AT BayNetworks DOT com [Perl-Win32-Porters AT ActiveWare DOT com]
nick AT ni-s DOT u-net DOT com (Nick Ing-Simmons) writes:
>>--- pp_sys.c Fri Dec 27 20:46:39 1996
[...]
>> dSP;
>>! /* CYGWIN32 is missing setpwent(), (but has the others!) */
>>! #if 0
>> setpwent();
>> RETPUSHYES;
>> #else
>
>I hope this is a temporary measure - we want a patch which will
>allow sources to build either way.
>I guess gnuwin32.sh could add -DNO_SETPWENT ...
Yup, I'm merely toying with the sources at this point. It seems
to be an oversight in Cygwin32 libs, so hopefully
we won't have to accomodate any workarounds for long.
I plan to look at how the Hip/Activeware NT-specific enhancements
will fit into the CYGWIN framework in the next few weeks, as
time permits. I'll probably try and fix dynaloading before then,
if I can find the incantations neccessary to give to cygnus-gcc
to build DLLs.
Anyone know where I can get good searchable winhelp/manpages for all
of the Cygnus toolkit? Please cc any replies, I'm not yet on the
gnuwin32 list.
- Sarathy.
gsar AT engin DOT umich DOT edu
......................................
To leave this list, send an email message to ListManager AT ActiveWare DOT com
with the body:
leave Perl-Win32-Porters
NTList compliments of Internet Shopper
http://www.net-shopper.co.uk/software/ntmail/ntlist.htm
-------------------------------------
X-ListMember: gmarzot AT BayNetworks DOT com [Perl-Win32-Porters AT ActiveWare DOT com]
Gurusamy Sarathy writes:
> * `/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).
This is what -DDOSISH is about. I consider it as a sane behaviour, but
*nix is more flexible here (though more expensive). There is no link
count on files, there is just a lockcount, and there is no unlink,
just delete.
> * 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).
Probably they are :-(. This happens under OS/2 too, there are
unkillable processes. A _great_ design flaw...
> * 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).
OS/2's one (though I have a very old gnupatch) has the same bug. I
work around via
chmod -R +w *
first.
> * I sometimes get "Out of free slots!" (or similar) errors.
> I'm on a machine with 32MB RAM.
If it were OS/2, I would advice raising number of threads in
config.sys.
Ilya
--
G. S. Marzot <gmarzot AT baynetworks DOT com> Network Management Development
Bay Networks Inc. (508)670-8888 x63990
--
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -