Perl5, cygwin32, administrateur

Charles Wilson
Mon May 31 21:10:00 GMT 1999

Rick Saltzman wrote:

> Thanks Sebastien,
> I had previously used these instructions but still ended up with the same
> difficulties you, wilson and morlock ran into.  To wit:
> Installed cygwin
> Read and followed the instructions in:
> build-instructions.READFIRST, README.cygwin, build-instructions.charles-wilson
> Ran into the following problems:
> x2p dependencies do not get made

??? I'm not sure what you mean by this...

> The build completes
> make test fails on file tests (stat) even with CYGWIN=ntea

You'll still get some failures: tests 4 and 35 in stat.t If I remember correctly,
stat.t/test35 tests access to /dev. Which is fine on a true Unix system, but /dev
doesn't exist in Cygwin. So naturally those specific tests fail. stat.t/test4
tests the difference between file creation and file modification times. I am not
sure whether cygwin provides reliable access to those two pieces of imformation -
NT stores separate file creation and modification times, but Win95/98 do not. If
the OS doesn't store the info, cygwin can't provide it. You're running NT, but
perhaps cygwin behaves the same under NT and Win9x -- only returns a single
timestamp value.

My test results:

RESULTS: make test

Failed 4 test scripts out of 190, 92.63% okay.
u=2.143  s=4.897  cu=120.165  cs=159.697  scripts=180  tests=6430

RESULTS: ./perl harness
most things were "foo/bar............ok" with the following exceptions:

base/rs.............ok, 4/14 subtests skipped
op/groups...........skipping test on this platform
op/magic............FAILED test 23
        Failed 1/35 tests, 97.14% okay (-4 skipped tests: 30 okay,85.71%)
op/ /dev: No such file or directory
FAILED tests 4, 35
        Failed 2/58 tests, 96.55% okay
op/taint............FAILED tests 1, 3, 31
        Failed 3/149 tests, 97.99% okay (-12 skipped tests: 134 okay, 89.93%)
        (Also got the following popup message four times - "The dynamic
        link library cygwin1.dll could not be found in the specified path
lib/findbin.........FAILED test 1
        Failed 1/1 tests, 0.00% okay
lib/gdbm............skipping test on this platform
lib/ipc_sysv........skipping test on this platform
lib/ndbm............skipping test on this platform
lib/odbm............skipping test on this platform
lib/posix...........skipping test on this platform
lib/thread..........skipping test on this platform

Failed Test  Status Wstat Total Fail  Failed  List of failed

lib/findbin.t                 1    1 100.00%  1
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    2   3.45%  4, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 4/190 test scripts, 97.89% okay. 7/6430 subtests failed, 99.89% okay.

> make install fails because of write permissions

This is a known NTism. If you are trying to install as Administrator, the
following sequence of events occur:

(1) install script creates a new directory, say /usr/local/lib/perl5, owned by
Administrator, with permissions drwxr-xr-x.

(2) NT overrules that decision, and makes the directory be owned by the
Administators GROUP, not the Administrator USER. However, the permission on the
directory is still drwxr-xr-x.

(3) install script tries to copy a file into /usr/local/lib/perl5.

(4) Permissions are wrong: you are the Administrator USER, and a member of the
Administrators GROUP. The directory is owned by the Administrators GROUP, but it
does not have group write access. The only "user" allowed to write into the
directory is the Adminstrators GROUP, but there exists NO user who IS that group,
only users who are MEMBERS of that group. Therefore, no-one can write into that

This silly sequence of events happens because MS, in its wisdom, decided that all
files created by users who are members of the Administrators group will be owned
by the group, not the user. This works okay with the access-control-list based
permissions scheme used by windows, but doesn't work very will with the more
limited unix-style permissions implemented by cygwin.

The solution is to build/install as a normal, non-Admin user.

AFAIK, this problem cannot be solved by a patch - short of changing the file
creation access permissions in the makefile so that everything is wide open, full
write access to all users. Which is probably not a good idea.

> I must emphasize that I used the patch and followed the instructions but ran
> into these problems which the patch should have solved, I thought.
> I did NOT mount /bin as per Morlocks instructions and could not access
> to obtain a description of the how and why of this.

This is necessary because many shell scripts start with the #!/bin/bash or
#!/bin/sh construct (or the "#!/bin/perl") This tells the current shell which
interpreter to use to execute the script. You have three alternatives: (1) change
every script you ever download, create, or run to have "#!/usr/local/bin/bash" or
whatever, or (2) create a /bin and put bash.exe, sh.exe in it, or (3) create /bin
and mount /cygnus/cygwin-b20/h-i386-blah/bin to it. This third option is
generally the easiest.

> I am not building on C:
> I am buiding on E: with E: mounted as / (default on my system)
> A directory /usr/local exists
> A directory /usr/local/bin is in my execution path

Have you "flattened" your directory structure? What's in /usr/local/bin? Is there
a /usr/bin? Where is h-386-cygwin? I think the biggest problem here is that you
installed cygwin, and immediate expected to build new applications before your
cygwin environment was stable. Remember, with cygwin, EVERYTHING is in beta. I
wish it were otherwise, but you can't just unpack it and expect everything to
work perfectly. The main problem is the funky directory structure that the cygnus
guys use. I understand why - it helps with multiple platform deployment - but it
sure is weird. Most of us rearrange things to a more "normal" structure, before
doing anything else.

One of these days, I'm going to write a shell script or a MSDOS batch file that
takes a default cygwin installation tree and turns it into a "normal" tree. But I
don't have time right now. Rick, I'm sending you a separate, private email, with
some cygwin setup instructions, my (flattened) directory structure, etc.

> I am running as Adminstrateur

don't. <g>

> I read the instructions and prepared the source.
> After patching I did the following.
> I modified gcc2 and ld2 so that they both contain ':' as the first character.
> If I do not do this, they do not execute.

This shouldn't be necessary. I think it has to do with your missing /bin

> I modified to add a line.  This is for install.
> prefix='/usr/local'
> I added a symbolic link to /usr.  This corresponds to the path used in patch.
> ln -s /cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32
> I then copied the indicated files, ran sh Configure -d and ran make with the
> above problems.  I tried "mount -b e: /" and redid the entire procedure but
> this did not even allow Configure to create files properly.  I tried patching
> ( so that the symbolic link would not be neccessary but
> this did not change anything.  I tried not adding the prefix line, but the
> file permissions were still incorrect for installing.  I tried building using
> dynamic rather than static libraries and saw no difference in the end result.

Please let me know if the setup changes I suggested in the other email, and
building as a normal user help.


Want to unsubscribe from this list?
Send a message to

More information about the Cygwin mailing list