Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Sender: cwilson AT ece DOT gatech DOT edu Message-ID: <373B0960.AC7287C2@ece.gatech.edu> Date: Thu, 13 May 1999 13:18:25 -0400 From: Charles Wilson X-Mailer: Mozilla 4.51 [en] (X11; I; HP-UX B.10.20 9000/777) X-Accept-Language: en MIME-Version: 1.0 To: Rick Saltzman CC: Sebastien Barre , cygwin AT sourceware DOT cygnus DOT com Subject: Re: Perl5, cygwin32, administrateur References: <199905130727 DOT JAA11680 AT blackhole DOT aixia DOT net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/stat.............ls: /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 F:\cygnus\cygwin-b20\usr\local\src\perl5.005_03\t;.; E:\WINNT\System32;E:\WINNT\system;E:\WINNT;..") 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 directory. 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 > http://sourceware.cygnus.com/cygwin/cygwin-ug-net/setup-mount.html > 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. > > 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 directory. > > I modified cygwin32.sh 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 > cygwin32.sh (config.sh) 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. --Chuck -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com