----- Original Message -----
From: "Reini Urban" <[EMAIL PROTECTED]>
To: <cygwin@cygwin.com>
Sent: Sunday, March 23, 2008 3:48 AM
Subject: Re: Building perl-5.10.0
Sisyphus schrieb:
----- Original Message ----- From: "Matthew Persico"
Well after a bit of googling around, the answer is this:
1) In a Windows cmd command prompt, cd where your cygwin lives - mine
is at c:\opt\cygwin
Mine is at C:\cygwin.
2) cd ..
I first ran 'attrib cygwin' to see what was already there:
Within cygwin you have better tools than the attrib or cacls.
Use your shell and the posix tools, and don't add additional ACL's by
using the explorer!
C:\>attrib cygwin
C:\cygwin
3) attrib -r cywgin - that removed the read-only bit. Don't try it in
Windows Explorer; it does not "stick"
>
I then ran 'attrib -r cygwin' (even though it doesn't appear to be
readonly to begin with).
4) Then in a Cygwin window, cd /
5) chmod 777 .
That errors out as follows:
[EMAIL PROTECTED] /
$ chmod 777 .
chmod: changing permissions of `.': Permission denied
After all that I get:
[EMAIL PROTECTED] /
$ ls -alrt
total 165
dr-xr-xr-x 1 0 root 0 Jan 1 1970 cygdrive
dr-xr-xr-x 1 Rob None 0 Dec 1 2006 proc
d---r-x---+ 7 admin Users 0 Mar 12 12:37 var
d---r-x---+ 2 admin Users 0 Mar 12 12:37 dev
d---r-x---+ 2 admin Users 0 Mar 12 12:37 tmp
----r-x---+ 1 admin Users 57 Mar 12 12:38 Cygwin.bat
drwxrwxrwx+ 3 Rob None 0 Mar 12 12:38 home
d---r-x---+ 12 admin Users 4096 Mar 12 12:38 ..
d---r-x---+ 12 admin Users 4096 Mar 12 12:38 .
d---r-x---+ 11 admin Users 4096 Mar 12 12:50 etc
d---r-x---+ 11 admin Users 12288 Mar 12 12:51 lib
d---r-x---+ 16 admin Users 4096 Mar 12 12:51 usr
d---r-x---+ 2 admin Users 131072 Mar 15 21:20 bin
----r-x---+ 1 admin Users 7022 Mar 15 21:20 Cygwin.ico
With such a mess, first fix your directories, than the files.
Or better start from scratch.
Ummm ... it's a fresh installation ... which I would have thought already
constitutes a "start from scratch".
A sane initial permission concept for cygwin would help.
Your big problem is that cygwin has no write access, the user even no
read access! d---r-x---+
The second problem is the +, the special Windows ACL, which should not
be here on a plain new cygwin installation.
Well ... it *is* there. (I had to google for "ACL" ... just to give you some
idea of the extent to which I am already familiar with permissions.)
POSIX access() doesn't check the additional ACL's, just the underlying
windows calls allow or deny access then. This can be right or this can
be contradictive.
and running 'make' terminates as before.
Besides the obvious not-writable lib/auto dir, note that Dynaloader
requires the generated dll to be +x. Of course the blib/arch dir also as
for every dir.
I made (or at least I think I made) lib/auto writable, but it didn't make
any difference. I changed it so that the permisions now read:
drwxrwxrwx+ 3 Rob None 0 Mar 15 00:18 auto
The error remains unchanged, however.
Module::Install had a recent bug in doing POSIX::access() checks for
writable dirs, which is wrong for your cases. Without the +
(additional ACL's) it works fine.
This is a fairly new installation of Cygwin, btw. (I stuffed up the old
one trying to install rsync and had to delete the lot.) So there could
be some additional stuff here that needs sorting out. I have, however,
already built some perl extensions using the 5.8.8 build that was
installed when I created this fresh build of Cygwin.
And the fact that I can build 5.8.8 from source, but not 5.10.0 leads me
to wonder whether this is instead a query that should be raised on p5p ?
I would rather blaim cygwin and esp. you.
Ok ... I won't raise it on p5p. But I still don't understand why I can build
5.8.8 from source but not 5.10.0. (I would have expected that the very same
issues that prevent 5.10.0 from building would have also prevented 5.8.8
from building. That's obviously not the case, so I can only assume that
build requirements must have changed dramatically between 5.8.8 and 5.10.0.)
Module::Install is also faulty.
Note that perl 5.10 is a bit stricter, mainly in taint checking. Group
writable is forbidden with 5.10 taint now.
Thanks for the reply, Matthew ... appreciated.
I have a ACL sanifier in my /usr/local/bin/fixfacl,
which recursively removes first the additional ACL's for directories,
and then for the files, and simply overwrites it with my preferred
user/group.
But this a special hack just for me and my seperation into executable or
non executable files. I don't care for the additional ACL's.
Don't touch symlinks with setfacl or chmod!
#!/bin/sh
if [ "$1"="." ]; then
setfacl -f /etc/facl.dir .
find -type d \! -name '.*' -exec setfacl -f /etc/facl.dir '{}' \;
find -type f -executable -exec setfacl -f /etc/faclx.file '{}' \;
find -type f \! -executable -exec setfacl -f /etc/facl.file '{}' \;
exit
fi
if test -d "$1"; then
setfacl -f /etc/facl.dir "$1"
exit
fi
if test -f "$1"; then
test -x "$1" && setfacl -f /etc/faclx.file "$1" && exit
setfacl -f /etc/facl.file "$1"
exit
fi
The simple and destructive way would be:
find -type d -exec setfacl -f /etc/facl.dir '{}' \;
find -type f -exec setfacl -f /etc/facl.file '{}' \;
This would destroy all executable bits.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--------------------------------------------------------------------------------
# file: lines.png
# owner: rurban
# group: users
user::rw-
group::r--
mask:rwx
other:r--
--------------------------------------------------------------------------------
# file: .
# owner: root
# group: users
user::rwx
group::rwx
mask:rwx
other:r-x
--------------------------------------------------------------------------------
I pretty much don't understand any of your advice - and I accept that's my
problem, not yours.
I can see that you spent quite some time (and probably also effort) in
assembling that reply. Unfortunately that time and effort was probably
wasted - and I apologise for that.
I have some (math related) modules, and I like to keep an eye on how they
work with the latest stable (and blead) perls. On native Win32, we don't get
access to a -Duse64bitint perl and, since such perls (ie perls built
with -Duse64bitint, but without -Duselongdouble) do some rather unusual and
unique things with numbers, one is always especially keen to keep in touch
with those builds. Cygwin does provide a -Duse64bitint perl, so it was an
obvious choice. But if one has to be intelligent to get perl-5.10.0 (and
perl-5.11.0) to build on Cygwin, then I'll just settle for building my
various configurations of 5.10.0 and 5.11.0 on linux - where the builds
simply work without any need to make posts seeking help re permissions
issues.
Cheers,
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
