Odd configure problems on Cygwin
Gary Johnson
could use an update, so I pulled and updated the latest changes from
the Mercurial repository, ran "make distclean" and
./configure --prefix=/usr/local --with-features=huge --without-x
--enable-gui=no
(one line) as I always do for Cygwin and got a bunch of error
messages before configure exited. I tried again with "make
distclean" and a simpler configure command that also tried to fix a
curses library problem reported by the previous run:
./configure --without-x --enable-gui=no --with-tlib=ncurses
I still got a lot of the same "Permission denied" errors. The
output of that command, beginning just before the first error is:
checking for uint32_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for ino_t... yes
checking for dev_t... auto/configure: line 1933: conftest.c:
Permission denied
sed: can't read conftest.c: Permission denied
no
checking whether byte ordering is bigendian... auto/configure: line
9532: conftest.c: Permission denied
sed: can't read conftest.c: Permission denied
auto/configure: line 9567: conftest.c: Permission denied
sed: can't read conftest.c: Permission denied
auto/configure: line 9614: conftest.c: Permission denied
sed: can't read conftest.c: Permission denied
auto/configure: line 9700: conftest.c: Permission denied
sed: can't read conftest.c: Permission denied
yes
checking for rlim_t... auto/configure: line 9756: conftest.c:
Permission denied
no
checking for stack_t... auto/configure: line 9792: conftest.c:
Permission denied
no
checking whether stack_t has an ss_base field... auto/configure:
line 9822: conftest.c: Permission denied
sed: can't read conftest.c: Permission denied
no
checking --with-tlib argument... ncurses
checking for linking with ncurses library... auto/configure: line
9866: conftest.c: Permission denied
sed: can't read conftest.c: Permission denied
configure: error: FAILED
I've never seen a "Permission denied" error from a configure script
before. I haven't investigated this further but thought someone
here might have seen this when building for Cygwin and already know
the solution.
I'm running Cygwin 1.5.25 on a Windows XP system. Yes, I know 1.5
is obsolete, but I've been unable to get sshd working on other
Cygwin installations and I'm unwilling to risk breaking sshd on this
one by upgrading to 1.7.
Regards,
Gary
Tony Mechelynck
Under what login name were you running this compile? Is it the same as
the "owning username" shown by ls -l for the "permission denied"
sources? Hadn't you changed it via su or sudo? What are these files'
permissions as listed by ls -l ? (I would expect at least -rw-r--r-- or
possibly, under Windows, -rwxr-xr-x) Depending on your findings, the
solution might involve either compiling under the correct username, or
running chmod and/or chown recursively on the sources.
Best regards,
Tony.
--
Your fault: core dumped
Benjamin R. Haskell
> I built Vim 7.3.0 on my Cygwin system last August and thought it could
> use an update, so I pulled and updated the latest changes from the
> Mercurial repository, ran "make distclean" and
>
> ./configure --prefix=/usr/local --with-features=huge --without-x
> --enable-gui=no
>
> (one line) as I always do for Cygwin and got a bunch of error messages
> before configure exited. I tried again with "make distclean" and a
> simpler configure command that also tried to fix a curses library
> problem reported by the previous run:
>
> ./configure --without-x --enable-gui=no --with-tlib=ncurses
>
> I still got a lot of the same "Permission denied" errors.
These look like the kinds of errors one tends to get when doing a `make
install` as root (on noncygwin). My guess is that you ran `make` or
`make install` while running as Administrator.
--
Best,
Ben
Gary Johnson
I didn't get to either the 'make' or 'make install' steps. The
errors came from the './configure ...' step. I executed
'./configure ...' as the same user I always have.
Regards,
Gary
Benjamin R. Haskell
> On 2011-03-23, Benjamin R. Haskell wrote:
>> On Wed, 23 Mar 2011, Gary Johnson wrote:
>>
>>> I built Vim 7.3.0 on my Cygwin system last August and thought it
>>> could use an update, so I pulled and updated the latest changes from
>>> the Mercurial repository, ran "make distclean" and
>>>
>>> ./configure --prefix=/usr/local --with-features=huge --without-x
>>> --enable-gui=no
>>>
>>> (one line) as I always do for Cygwin and got a bunch of error
>>> messages before configure exited. I tried again with "make
>>> distclean" and a simpler configure command that also tried to fix a
>>> curses library problem reported by the previous run:
>>>
>>> ./configure --without-x --enable-gui=no --with-tlib=ncurses
>>>
>>> I still got a lot of the same "Permission denied" errors.
>>
>> These look like the kinds of errors one tends to get when doing a
>> `make install` as root (on noncygwin). My guess is that you ran
>> `make` or `make install` while running as Administrator.
>
> I didn't get to either the 'make' or 'make install' steps. The errors
> came from the './configure ...' step.
Right. The permissions problems could stem from `make distclean` not being
able to completely clear out the prior build.
If you're running `make distclean`, presumably you've built from that
same directory in the past. And, maybe the last time you successfully
built Vim (all the way through), you were (inadvertently?) running as
Administrator. Just something to watch for in general. But probably
not the issue, given:
> I executed './configure ...' as the same user I always have.
Another source of weird permissions problems could be (re-)running the
Cygwin setup.exe (which could bump you up to Administrator). I didn't
note what Windows version you were on.
--
Best,
Ben
Gary Johnson
The same login name I always use, "Gary Johnson". (If I knew then
what I know now, I would not have used a name with a space.)
> Is it the same as the "owning username" shown by ls -l for the
> "permission denied" sources?
I forgot to mention that. I executed "find conftest.c" from the vim
directory--the directory containing .hg and the one from which I
executed "./configure ..."--and got no results, so I couldn't check
the permissions.
> Hadn't you changed it via su or sudo?
I never use su or sudo on Cygwin.
> What are these files' permissions as listed by ls -l ? (I would
> expect at least -rw-r--r-- or possibly, under Windows, -rwxr-xr-x)
As I wrote above, I couldn't check the permissions because the file
didn't exist after configure was done.
> Depending on your findings, the solution might involve either
> compiling under the correct username, or running chmod and/or
> chown recursively on the sources.
From the vim directory I ran the following command:
$ find . | xargs ls -dl | grep -v 'Gary Johnson None'
So there are no files that are owned by other than user "Gary
Johnson" and group "None".
I could check configure to see if it ever explicitly checks anything
against my user name and see if it handles spaces properly. That's
a problem with rcs and some versions of ssh, so it might be a
problem with configure or some tool that it's using.
Note that the process I'm using worked fine through August, 2010, so
if it is something in configure it's something that has changed
since then.
Thank you and Ben for your suggestions.
Regards,
Gary
Gary Johnson
XP SP3
Gary
bill lam
cannot get x permission, eg. umask setting, then those test programs
cannot be run.
Срд, 23 Мар 2011, Gary Johnson писал(а):
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Gary Johnson
> During ./configure, it will compile and run some c programs, if new files
> cannot get x permission, eg. umask setting, then those test programs
> cannot be run.
$ umask
0022
Gary
clemens fischer
> The same login name I always use, "Gary Johnson". (If I knew then
> what I know now, I would not have used a name with a space.)
Reminds me of my first attempt of compiling linux. Back then I had
structured parts of the file hierarchy by using ":" (colon) separated
names. There was no mention anywhere that the build procedure breaks
with colons, I had to find out by trial and error.
> From the vim directory I ran the following command:
>
> $ find . | xargs ls -dl | grep -v 'Gary Johnson None'
>
> So there are no files that are owned by other than user "Gary
> Johnson" and group "None".
My instinct would advise:
$ ... egrep -v -i '^[^[:space:]]+[[:space:]]+[^[:space:]]+[[:space:]]+(Gary|Johnson|None)'
because this would guard against white space issues and provide similiar
(but not the exact same!) results. The problem lies with files named
"Gary", "Johnson" or "None" by accident.
> I could check configure to see if it ever explicitly checks anything
> against my user name and see if it handles spaces properly. That's
> a problem with rcs and some versions of ssh, so it might be a
> problem with configure or some tool that it's using.
That's a Titanic Task given the wads of m4 preprocessing
incomprehendable by mortals.
> Note that the process I'm using worked fine through August, 2010, so
> if it is something in configure it's something that has changed
> since then.
You might get (un)lucky, then, since all the autoconfig stuff consists
of so many parts. Are you running a package manager that keeps logs by
chance? If not, a list of files sorted by time might help. How about
"find /dev-tools-root/ -mtime -111 -ls" to show files changed within the
last 111 days?
clemens