[RFU 1.7] gmp-4.3.1-1
A build of gmp-4.3.1-1 for cygwin 1.7 is available for upload. This is
a routine dot release from upstream.
==
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
wget -x -nH --cut-dirs=1 \
${D}/gmp/gmp-4.3.1-1-src.tar.bz2 \
${D}/gmp/gmp-4.3.1-1.tar.bz2 \
${D}/gmp/setup.hint \
${D}/gmp/libgmpxx4/libgmpxx4-4.3.1-1.tar.bz2 \
${D}/gmp/libgmpxx4/setup.hint \
${D}/gmp/libgmp3/libgmp3-4.3.1-1.tar.bz2 \
${D}/gmp/libgmp3/setup.hint \
${D}/gmp/libgmp-devel/libgmp-devel-4.3.1-1.tar.bz2 \
${D}/gmp/libgmp-devel/setup.hint
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
On 5/15/2009 1:05 PM, Ken Brown wrote: On 5/15/2009 10:46 AM, Christopher Faylor wrote: If you release a new 1.5 version now then you will have a few weeks at least to work out any wrinkles. So, it might make sense to have a stable version of emacs since the old version apparently had so many problems. That sounds like a good idea. I should be able to make a 1.5 version of emacs 22.3 (the last stable release) fairly easily. Remind me never to use the phrase fairly easily again. It turns out that I can't build emacs 22.3 using cygport, in either cygwin 1.5 or 1.7. This seems to result from the way emacs calls subprocesses in version 22, which has changed as of version 23. Part of the build process involves a bootstrap procedure, in which emacs.exe is built first and is then used to create some auxiliary files. The second step involves having the newly built emacs.exe call subprocesses, and it hangs when I do the build using cygport. (The build works fine if I don't use cygport, but then I would have to do the packaging by hand.) I don't think it's worth investing any more time in emacs 22. I've built emacs 23.0.92 for cygwin 1.5 (the same version that's already been uploaded for 1.7), and I'll send an RFU for it soon. One question: To follow the standard practice, I should give it a different release number than the 1.7 version, presumably 23.0.92-2. But it seems that all other package maintainers are using higher release numbers for 1.7 than for 1.5. Is this going to cause confusion? One last question: In the course of tracking down the problem in building 22.3 with cygport, I came across a file cygwin.h in the emacs source. I already had to modify it slightly, and I'm wondering if more changes should be made. In particular, I'm wondering if something in here is responsible for the time zone bug that I reported elsewhere (see my release announcement for the emacs 23.0.92-1 packages). I'm attaching cygwin.h from emacs 23.0.2, as already patched by me. I would appreciate it if someone would take a look and see if it's reasonable. I'm also attaching the diffs between the 22.3 version and the (unpatched) 23.0.92 version, since that's the most likely place for the time zone problem, which didn't occur in 22.3. Ken /* System description header file for Cygwin. Copyright (C) 1985, 1986, 1992, 1999, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc. This file is part of GNU Emacs. GNU Emacs is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Emacs. If not, see http://www.gnu.org/licenses/. */ /* SYSTEM_TYPE should indicate the kind of system you are using. It sets the Lisp variable system-type. */ #define SYSTEM_TYPE cygwin /* Emacs can read input using SIGIO and buffering characters itself, or using CBREAK mode and making C-g cause SIGINT. The choice is controlled by the variable interrupt_input. Define INTERRUPT_INPUT to make interrupt_input = 1 the default (use SIGIO) Emacs uses the presence or absence of the SIGIO and BROKEN_SIGIO macros to indicate whether or not signal-driven I/O is possible. It uses INTERRUPT_INPUT to decide whether to use it by default. SIGIO can be used only on systems that implement it (4.2 and 4.3). CBREAK mode has two disadvantages 1) At least in 4.2, it is impossible to handle the Meta key properly. I hear that in system V this problem does not exist. 2) Control-G causes output to be discarded. I do not know whether this can be fixed in system V. Another method of doing input is planned but not implemented. It would have Emacs fork off a separate process to read the input and send it to the true Emacs process through a pipe. */ #undef INTERRUPT_INPUT /* * Define HAVE_TERMIOS if the system provides POSIX-style * functions and macros for terminal control. * * Define HAVE_TERMIO if the system provides sysV-style ioctls * for terminal control. * * Do not define both. HAVE_TERMIOS is preferred, if it is * supported on your system. */ #define HAVE_TERMIOS /* * Define HAVE_PTYS if the system supports pty devices. */ #define HAVE_PTYS #define PTY_ITERATION for (i = 0; i 1; i++) /* ick */ #define PTY_NAME_SPRINTF/* none */ #define PTY_TTY_NAME_SPRINTF/* none */ #define PTY_OPEN\ do
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
On Sun, May 17, 2009 at 12:34:09PM -0400, Ken Brown wrote:
One question: To follow the standard practice, I should give it a
different release number than the 1.7 version, presumably 23.0.92-2.
But it seems that all other package maintainers are using higher
release numbers for 1.7 than for 1.5. Is this going to cause
confusion?
My 2c: It's not ideal but I don't think that bumping 1.7 to accommodate
1.5 is worth your aggravation. As long as they are different it should
be fine.
Minor comments inline.
/* System description header file for Cygwin.
Copyright (C) 1985, 1986, 1992, 1999, 2002, 2003, 2004, 2005, 2006,
2007, 2008, 2009 Free Software Foundation, Inc.
This file is part of GNU Emacs.
GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Emacs. If not, see http://www.gnu.org/licenses/. */
/* SYSTEM_TYPE should indicate the kind of system you are using.
It sets the Lisp variable system-type. */
#define SYSTEM_TYPE cygwin
/* Emacs can read input using SIGIO and buffering characters itself,
or using CBREAK mode and making C-g cause SIGINT.
The choice is controlled by the variable interrupt_input.
Define INTERRUPT_INPUT to make interrupt_input = 1 the default (use SIGIO)
Emacs uses the presence or absence of the SIGIO and BROKEN_SIGIO macros
to indicate whether or not signal-driven I/O is possible. It uses
INTERRUPT_INPUT to decide whether to use it by default.
SIGIO can be used only on systems that implement it (4.2 and 4.3).
CBREAK mode has two disadvantages
1) At least in 4.2, it is impossible to handle the Meta key properly.
I hear that in system V this problem does not exist.
2) Control-G causes output to be discarded.
I do not know whether this can be fixed in system V.
Another method of doing input is planned but not implemented.
It would have Emacs fork off a separate process
to read the input and send it to the true Emacs process
through a pipe. */
#undef INTERRUPT_INPUT
/*
* Define HAVE_TERMIOS if the system provides POSIX-style
* functions and macros for terminal control.
*
* Define HAVE_TERMIO if the system provides sysV-style ioctls
* for terminal control.
*
* Do not define both. HAVE_TERMIOS is preferred, if it is
* supported on your system.
*/
#define HAVE_TERMIOS
/*
* Define HAVE_PTYS if the system supports pty devices.
*/
#define HAVE_PTYS
#define PTY_ITERATION for (i = 0; i 1; i++) /* ick */
#define PTY_NAME_SPRINTF /* none */
#define PTY_TTY_NAME_SPRINTF /* none */
#define PTY_OPEN \
do \
{ \
int dummy; \
SIGMASKTYPE mask;\
mask = sigblock (sigmask (SIGCHLD)); \
if (-1 == openpty (fd, dummy, pty_name, 0, 0)) \
fd = -1;\
sigsetmask (mask); \
emacs_close (dummy); \
This will close a random number if openpty fails.
} \
while (0)
/* Define this symbol if your system has the functions bcopy, etc. */
#define BSTRING
/* Define CLASH_DETECTION if you want lock files to be written
so that Emacs can tell instantly when you try to modify
a file that someone else has modified in his Emacs. */
#define CLASH_DETECTION
/* If the system's imake configuration file defines `NeedWidePrototypes'
as `NO', we must define NARROWPROTO manually. Such a define is
generated in the Makefile generated by `xmkmf'. If we don't
define NARROWPROTO, we will see the wrong function prototypes
for X functions taking float or double parameters. */
#define NARROWPROTO 1
/* used in various places to enable cygwin-specific code changes */
#define CYGWIN 1
#define PENDING_OUTPUT_COUNT(FILE) ((FILE)-_p - (FILE)-_bf._base)
#define SYSV_SYSTEM_DIR 1
#define UNEXEC unexcw.o
#define POSIX_SIGNALS 1
/* force the emacs image to start high in memory, so dll relocation
can put things in low memory without causing all sorts of grief for
emacs lisp pointers */
/* but this can cause problems if the user later rebases; so I'm
changing it (KB) */
/* #define DATA_SEG_BITS 0x2000 */
/* #define LINKER $(CC)
winsup/cygwin ChangeLog mount.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-05-18 04:58:21 Modified files: cygwin : ChangeLog mount.cc Log message: * mount.cc (mount_info::got_usr_bin): Mark as NO_COPY. (mount_info::got_usr_lib): Ditto. (mount_info::root_idx): Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4490r2=1.4491 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/mount.cc.diff?cvsroot=uberbaumr1=1.38r2=1.39
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-17 10:09, IWAMURO Motonori wrote: 2009/5/17 Lenikle...@bodz.net: Thanks, but where can I get this patch? You can checkout it from CVS HEAD. Thanks for your information, well, I'm not expect to build from source, that really frustrates me, and brings me even more problems. Is there any mirror site for nightly builds? so I can use rsync to get it (If this patch is too minor to increase any of the version numbers). I've just looked at snapshots, but the last update time is 2009-05-13. I can't build from source, here are some errors, I guess there will be more errors, so I hope someone will compile cygpath at the first time, 6 weeks to the next release maybe too long to wait. 1, cvs update failed: ... (ignored) cvs update: Updating src/winsup/testsuite/winsup.api/samples cvs update: Updating src/winsup/utils cvs update: Updating src/winsup/w32api cvs update: Updating src/winsup/w32api/include cvs update: Updating src/winsup/w32api/include/GL cvs update: Updating src/winsup/w32api/include/ddk cvs update: Updating src/winsup/w32api/include/directx cvs update: Updating src/winsup/w32api/lib cvs update: Updating src/winsup/w32api/lib/ddk cvs update: Updating src/winsup/w32api/lib/directx cvs update: closing down connection to cygwin.com: Transport endpoint is not connected 2, configure failed: bash-3.2$ ./configure 5 [main] expr 952 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) ./configure: line 56: 952 Segmentation fault (core dumped) expr a : '\(a\)' /dev/null 21 4 [main] expr 2808 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3516 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3328 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2648 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 900 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 1840 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2972 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Thanks, Lenik -- 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/
rsync: send_files failed to open
11044 files in 3.87GB are correctly rsynced, while several files are failed.
see the output.
These files are marked as Permission denied (13), and my local
directories are writable.
--
# rsync -amv --delete --delete-excluded --exclude-from
./.msync/mod/cygwin.ex --log-file=/var/log/rsync/cygwin.log
rsync://ftp.kaist.ac.kr/cygwin/ cygwin
Welcome to KAIST File Archive, ftp.kaist.ac.kr!
(AKA ftp.kr.debian.org, kr.archive.ubuntu.com, ftp2.kr.vim.org,
{cvsup,ftp}2.kr.freebsd.org)
...
Contact f...@ftp.kaist.ac.kr for any problem or suggestion.
For more information, visit: http://ftp.kaist.ac.kr/
receiving file list ... done
rsync: send_files failed to open
release-2/.unionfs/automake/automake1.9/automake1.9-1.9.6-3-src.tar.bz2_HIDDEN~
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/glpk/libglpk-devel/libglpk-devel-4.35-1.tar.bz2_HIDDEN~
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/hdf5-1.6.8-1-src.tar.bz2_HIDDEN~ (in cygwin):
Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/hdf5-1.6.8-1.tar.bz2_HIDDEN~ (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/.unionfs/hdf5/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/setup.hint_HIDDEN~ (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/libhdf5-devel/libhdf5-devel-1.6.8-1.tar.bz2_HIDDEN~
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/libhdf5-devel/md5.sum (in cygwin): Permission
denied (13)
rsync: send_files failed to open release-2/.unionfs/qhull/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/qhull/setup.hint_HIDDEN~ (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/GNOME/libxml/libxml-devel/libxml-devel-1.8.17-3.tar.bz2 (in
cygwin): Permission denied (13)
rsync: send_files failed to open release-2/WordNet/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/apache2/apache2-devel/apache2-devel-2.2.6-1.tar.bz2 (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/aspell/aspell-dev/aspell-dev-0.60.5-1.tar.bz2 (in cygwin):
Permission denied (13)
rsync: send_files failed to open
release-2/aspell/aspell-en/aspell-en-6.0.0-1-src.tar.bz2 (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/autoconf/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open release-2/autoconf/setup.hint (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/bash/bash-completion/bash-completion-20060301-2-src.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/bcrypt/bcrypt-1.1-1-src.tar.bz2 (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/bool/bool-0.2.1-1-src.tar.bz2 (in cygwin): Permission denied
(13)
rsync: send_files failed to open release-2/brltty/tcl-brlapi/md5.sum
(in cygwin): Permission denied (13)
rsync: send_files failed to open release-2/compface/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open release-2/cron/cron-4.1-6-src.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open release-2/cron/md5.sum (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/csih/md5.sum (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/curl/curl-7.16.3-1.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/cyrus-sasl/cyrus-sasl-2.1.19-3-src.tar.bz2 (in cygwin):
Permission denied (13)
rsync: send_files failed to open
release-2/epstool/epstool-3.08-2-src.tar.bz2 (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/esound/libesound-devel/libesound-devel-0.2.36-1.tar.bz2 (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/esound/libesound-devel/md5.sum (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/esound/libesound0/setup.hint (in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/exif/libexif/libexif-devel/libexif-devel-0.6.16-1.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open release-2/exim/exim-4.68-2.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/expat/expat-2.0.1-1-src.tar.bz2 (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/expat/libexpat1-devel/md5.sum (in cygwin): Permission denied
(13)
rsync: send_files failed to open
release-2/gail/gail-1.8.8-1-src.tar.bz2 (in cygwin): Permission denied
(13)
rsync: send_files failed to open
release-2/gcc/gcc-objc/gcc-objc-3.4.4-3-src.tar.bz2 (in cygwin):
Permission denied (13)
rsync:
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 17 11:09, IWAMURO Motonori wrote: 2009/5/17 Lenik le...@bodz.net: Thanks, but where can I get this patch? You can checkout it from CVS HEAD. It occured to me that, if you're using a charset which differs from your current ANSI or OEM codepage, you might run into trouble with native Windows tools. Therefore I also added a new -C/--codepage option to cygpath to specify the codepage used to create a WIndows path from a Cygwin path. For instance: cygpath -C ANSI -aw . creates the full path of the CWD in the current ANSI codepage. The -C/--codepage option takes the following parameters: - ANSI to specify the current ANSI codepage (for interaction with GUI tools). - OEMto specify the current OEM codepage (for interaction with CLI tools). - UTF8 just guess... UTF-8 - n A decimal codepage number according to the following table: http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx Note that not all installations support all codepages. I hope that helps. Please note that the -C option doesn't work yet for the -p option. That's something I'll do after my vacation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 17 15:52, Lenik wrote: On 2009-5-17 10:09, IWAMURO Motonori wrote: 2009/5/17 Lenikle...@bodz.net: Thanks, but where can I get this patch? You can checkout it from CVS HEAD. [...] 6 weeks to the next release maybe too long to wait. We have about 2 weeks between the test releases. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-17 19:53, Corinna Vinschen wrote:
On May 17 15:52, Lenik wrote:
On 2009-5-17 10:09, IWAMURO Motonori wrote:
2009/5/17 Lenikle...@bodz.net:
Thanks, but where can I get this patch?
You can checkout it from CVS HEAD.
[...]
6 weeks to the next release maybe too long to wait.
We have about 2 weeks between the test releases.
Corinna
Thank you, I'll be very happy if I can apply your great patch in next
morning if not earlier. I'd rather hope I can get everything immediately
when I read your reply, and IMHO that should be very easy, all what you
have to do is make your working directory public and accessible. Stupid
idea, heh? :)
Currently I resolved it by a simple function:
function _u2w() {
local p=$(cygpath -au $1)
if [ ${p:0:5} = /mnt/ -o ${p:0:10} = /cygdrive/ ]; then
p=${p:1}
p=${p#*/}
p=${p/\//:/}
else
if [ ${p:0:9} = /usr/bin/ ]; then p=${p:4}; fi
if [ ${p:0:9} = /usr/lib/ ]; then p=${p:4}; fi
p=$(cygpath -am /)$p
fi
p=${p//\//\\}
echo $p
}
path=$(_u2w $path)
Lenik
--
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/
Re: BUG: libioperm + libtool + libpopt
duane yet, there is no 'libpoptanything' I can find to link against. david.korn Let me introduce you: david.korn http://cygwin.com/packages [snip] david.korn http://cygwin.com/cgi-bin2/package-grep.cgi?grep=libpopt.la Thanks, at times finding things is a maze of twisty passages all alike http://en.wikipedia.org/wiki/Colossal_Cave_Adventure Perhaps my bug report - should be reclassified as a bug in ioperm devel dependencies in that libioperm development - should automatically require libpopt devel. -Duane. -- 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/
Re: expr error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Lenik on 5/17/2009 6:51 AM: Program output: C:\Profiles\Shecti expr 6 [main] expr 3784 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 1906 [main] expr 3784 open_stackdumpfile: Dumping stack trace to expr.exe.stackdump 19089 [main] expr 3784 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 20953 [main] expr 3784 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Works for me. Possibly an instance of BLODA on your machine? Found: C:\lam\sys\cygwin-1.7\bin\sh.exe Warning: C:\lam\kala\lib\sh hides C:\lam\sys\cygwin-1.7\bin\sh.exe Are you sure you don't have some competing tools getting in the way of proper cygwin operation? - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoQJPEACgkQ84KuGfSFAYAB0QCfVxxMhQXaF3qMjBEkOCA/304k hn4AnA+ZIWZ28EyQD8odEGn3NLN5McZr =keh7 -END PGP SIGNATURE- -- 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/
Re: [1.7] Updated: {emacs,emacs-X11,emacs-el}-23.0.92-1
Date: Sun, 17 May 2009 00:33:13 -0400 From: Christopher Faylor cgf-use-the-mailinglist-please at cygwin dot com On Sun, May 17, 2009 at 06:12:04AM +0300, Eli Zaretskii wrote: Date: Sat, 16 May 2009 02:52:22 -0700 (PDT) From: Marc Girod marc dot girod at gmail dot com Eli Zaretskii wrote: ...if Emacs could know the Cygwin version. uname -r this gives on 2 installations e.g.: 1.5.25(0.156/4/2) 1.7.0(0.210/5/3) We haven't patched the uname program. emacs can use the same standard UNIX function calls as uname: http://cygwin.com/ml/cygwin/2009-05/msg00496.html Great, thanks. This means that an existing Emacs variable `operating-system-release', whose value is derived from uts.release, should hold either 1.5.SOMETHING or 1.7.SOMETHING, and that can be used to distinguish between the two Cygwin families. -- 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/
Re: Updated: {emacs,emacs-X11,emacs-el}-23.0.92-1
Eli Zaretskii wrote: This means that an existing Emacs variable `operating-system-release', whose value is derived from uts.release, should hold either 1.5.SOMETHING On a my recent build of Emacs-23.0.93 I get: C-h v operating-system-release operating-system-release is a variable defined in `C source code'. Its value is 1.5.25(0.156/4/2) Cheers, Angelo. --- Don't know much about history Don't know much biology Don't know much about a science book ... Sam Cooke, Wonderful World -- 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/
Re: expr error
On Sun, May 17, 2009 at 08:51:06PM +0800, Lenik wrote: 2363k 2009/01/27 C:\lam\sys\cygwin-1.7\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2009/1/27 23:49 Cygwin DLL version info: DLL version: 1.7.0 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 192 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Cygdrive default prefix: Build date: Tue Jan 27 16:49:28 CET 2009 Shared id: cygwin1S5 Any reason why you're using a version of Cygwin 1.7.x from January? Your information should look like this: 2436k 2009/05/15 c:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2009/5/15 11:15 Cygwin DLL version info: DLL version: 1.7.0 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 210 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Cygdrive default prefix: Build date: Fri May 15 17:15:33 CEST 2009 Shared id: cygwin1S5 cgf -- 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/
Re: [1.7] Updated: {emacs,emacs-X11,emacs-el}-23.0.92-1
Eli Zaretskii wrote: This means that an existing Emacs variable `operating-system-release', whose value is derived from uts.release, should hold either 1.5.SOMETHING or 1.7.SOMETHING, and that can be used to distinguish between the two Cygwin families. Indeed. I found it on 23.0.92 (not on 21.2), holding 1.7.0(0.210/5/3) -- View this message in context: http://www.nabble.com/Re%3A--1.7--Updated%3A-%7Bemacs%2Cemacs-X11%2Cemacs-el%7D-23.0.92-1-tp23559935p23585560.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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/
Re: expr error
Eric Blake wrote: Works for me. Possibly an instance of BLODA on your machine? Same error at mine (as reported earlier): 3 [main] expr 8032 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) /usr/bin/startx: line 40: 8032 Segmentation fault (core dumped) expr $1: ':[0-9][0-9]*$' /dev/null 21 Indeed, expr dumps core in a reproducible way: ~ expr aaa : 'a\+' Segmentation fault (core dumped) rebaseall and peflagsall run. Marc http://www.nabble.com/file/p23587259/cygcheck.srvc cygcheck.srvc -- View this message in context: http://www.nabble.com/expr-error-tp23583036p23587259.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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/
Re: expr error
Marc Girod wrote: Indeed, expr dumps core in a reproducible way: Actually, why no stracing it: ~ strace -o /tmp/expr.strace expr aaa : 'a\+' 716256 [main] expr 6192 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 717003 [main] expr 6192 open_stackdumpfile: Dumping stack trace to expr.exe.stackdump http://www.nabble.com/file/p23587322/expr.strace expr.strace Marc -- View this message in context: http://www.nabble.com/expr-error-tp23583036p23587322.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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/
Re: expr error
Marc Girod wrote: Actually, why no stracing it: Sorry, this also: http://www.nabble.com/file/p23587340/expr.exe.stackdump expr.exe.stackdump Marc -- View this message in context: http://www.nabble.com/expr-error-tp23583036p23587340.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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/
Re: expr error
On 2009-5-17 22:53, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Are you sure you don't have some competing tools getting in the way of proper cygwin operation? No, I've set PATH to cygwin/bin only, before execute expr. stackdump added. Exception: STATUS_ACCESS_VIOLATION at eip=0524 eax=0524 ebx=0001 ecx=7C80E6CB edx= esi=691C4DA4 edi=0005 ebp=0022CD28 esp=0022CD1C program=C:\lam\sys\cygwin-1.7\bin\expr.exe, pid 1392, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022CD28 0524 (, 691E, 0022CD90, 61020340) 0022CDB8 61020273 (, 0022CDF0, 610066A0, 7FFDB000) End of stack trace 63574 [main] expr 1392 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 65368 [main] expr 1392 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) -- 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/
Re: expr error
Lenik wrote: Are you sure you don't have some competing tools getting in the way of proper cygwin operation? No, I've set PATH to cygwin/bin only, before execute expr. Doesn't necessarily mean there aren't system-wide hooks being loaded into every application running. stackdump added. Can you get this to reproduce under GDB? A backtrace from the exception caught there, plus the output from info files, would tell us more. From the tiny bit of stackdump it managed to output before crashing, it does look like either the stack is very corrupted, or the program counter ended up in a rather unexpected area of memory owing to some intercepting DLL or similar. cheers, DaveK -- 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/
Re: expr error
On 2009-5-18 7:42, Dave Korn wrote: Lenik wrote: Are you sure you don't have some competing tools getting in the way of proper cygwin operation? No, I've set PATH to cygwin/bin only, before execute expr. Doesn't necessarily mean there aren't system-wide hooks being loaded into every application running. This is hard to say, but I think my system is ok, all tools in coreutils except expr are ok to run. stackdump added. Can you get this to reproduce under GDB? A backtrace from the exception caught there, plus the output from info files, would tell us more. From the tiny bit of stackdump it managed to output before crashing, it does look like either the stack is very corrupted, or the program counter ended up in a rather unexpected area of memory owing to some intercepting DLL or similar. I don't know how to do in detail, this is what I get, I don't have debug symbols. (gdb) run Starting program: /usr/bin/expr [New thread 3988.0xd84] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 3988.0x9f4] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) Thanks, Lenik -- 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/
Re: expr error
Lenik wrote: I don't know how to do in detail, this is what I get, I don't have debug symbols. Yeah, binaries shipped with the distro are stripped, but we'll still get some useful info. (gdb) run Starting program: /usr/bin/expr [New thread 3988.0xd84] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 3988.0x9f4] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) At this point, run the commands bt, info files, info reg and info frame, and show us the output they generate. cheers, DaveK -- 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/
Re: expr error
ok, (gdb) run Starting program: /usr/bin/expr [New thread 2412.0x92c] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 2412.0xcb8] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) bt #0 0x0524 in ?? () #1 0x69181041 in ?? () from /usr/bin/cyggmp-3.dll #2 0x691c9000 in ?? () from /usr/bin/cyggmp-3.dll #3 0x691ca000 in ?? () from /usr/bin/cyggmp-3.dll #4 0x0022cdb8 in ?? () #5 0x61020273 in per_module::run_ctors () from /usr/bin/cygwin1.dll #6 0x006fa418 in ?? () #7 0x61020340 in dll::init () from /usr/bin/cygwin1.dll #8 0x in ?? () (gdb) info files Symbols from /usr/bin/expr. Win32 child process: Using the running image of child thread 2412.0x92c. While running this, GDB does not access memory from... Local exec file: `/usr/bin/expr', file type pei-i386. Entry point: 0x401000 0x00401000 - 0x00419038 is .text 0x0041a000 - 0x0041a034 is .data 0x0041b000 - 0x0041d380 is .rdata 0x0041e000 - 0x0041e280 is .bss 0x0041f000 - 0x0041f8c4 is .idata 0x7c921000 - 0x7c99d23a is .text in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c99e000 - 0x7c9a1200 is .data in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c9a3000 - 0x7c9b27e4 is .rsrc in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c9b3000 - 0x7c9b5eac is .reloc in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c801000 - 0x7c8841e9 is .text in /mnt/c/WINDOWS/system32/kernel32.dll 0x7c885000 - 0x7c887600 is .data in /mnt/c/WINDOWS/system32/kernel32.dll 0x7c88a000 - 0x7c9173fc is .rsrc in /mnt/c/WINDOWS/system32/kernel32.dll 0x7c918000 - 0x7c91dc84 is .reloc in /mnt/c/WINDOWS/system32/kernel32.dll 0x61001000 - 0x6113f610 is .text in /usr/bin/cygwin1.dll 0x6114 - 0x611414b8 is .autoload_text in /usr/bin/cygwin1.dll 0x61142000 - 0x61167028 is .data in /usr/bin/cygwin1.dll 0x61168000 - 0x611bfd44 is .rdata in /usr/bin/cygwin1.dll 0x611c - 0x611f25d8 is .bss in /usr/bin/cygwin1.dll 0x611f3000 - 0x611fbb0c is .edata in /usr/bin/cygwin1.dll 0x611fc000 - 0x611fc400 is .rsrc in /usr/bin/cygwin1.dll 0x611fd000 - 0x61212a40 is .reloc in /usr/bin/cygwin1.dll 0x61213000 - 0x6121b1e0 is .cygwin_dll_common in /usr/bin/cygwin1.dll 0x6121d000 - 0x6122 is .idata in /usr/bin/cygwin1.dll 0x6122 - 0x6130 is .cygheap in /usr/bin/cygwin1.dll 0x77da1000 - 0x77e155c9 is .text in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e16000 - 0x77e18c00 is .data in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e1b000 - 0x77e43878 is .rsrc in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e44000 - 0x77e48af8 is .reloc in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e51000 - 0x77ed3743 is .text in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77ed4000 - 0x77eda90d is .orpc in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77edb000 - 0x77edbc00 is .data in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77edc000 - 0x77edc3f8 is .rsrc in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77edd000 - 0x77ee1494 is .reloc in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77fc1000 - 0x77fcd224 is .text in /mnt/c/WINDOWS/system32/secur32.dll 0x77fce000 - 0x77fce480 is .data in /mnt/c/WINDOWS/system32/secur32.dll 0x77fcf000 - 0x77fcf418 is .rsrc in /mnt/c/WINDOWS/system32/secur32.dll 0x77fd - 0x77fd0884 is .reloc in /mnt/c/WINDOWS/system32/secur32.dll 0x69181000 - 0x691c4db8 is .text in /usr/bin/cyggmp-3.dll 0x691c5000 - 0x691c8e54 is .data in /usr/bin/cyggmp-3.dll 0x691c9000 - 0x691c9004 is .rdata in /usr/bin/cyggmp-3.dll 0x691ca000 - 0x691ca170 is .bss in /usr/bin/cyggmp-3.dll 0x691cb000 - 0x691cf8c6 is .edata in /usr/bin/cyggmp-3.dll 0x691d - 0x691d0410 is .idata in /usr/bin/cyggmp-3.dll 0x691d1000 - 0x691d2680 is .reloc in /usr/bin/cyggmp-3.dll 0x65b81000 - 0x65b86558 is .text in /usr/bin/cygintl-8.dll 0x65b87000 - 0x65b8703c is .data in /usr/bin/cygintl-8.dll 0x65b88000 - 0x65b88854 is .rdata in /usr/bin/cygintl-8.dll 0x65b89000 - 0x65b895d8 is .bss in /usr/bin/cygintl-8.dll 0x65b8a000 - 0x65b8a5ae is .edata in /usr/bin/cygintl-8.dll 0x65b8b000 - 0x65b8b7e0 is .idata in /usr/bin/cygintl-8.dll 0x65b8c000 - 0x65b8c460 is .reloc in /usr/bin/cygintl-8.dll 0x67c71000 - 0x67c86fe8 is .text in /usr/bin/cygiconv-2.dll 0x67c87000 - 0x67c87008 is .data in /usr/bin/cygiconv-2.dll 0x67c88000 - 0x67d6481c is .rdata in
Re: [1.5] Problem with OpenSSH on Windows Home Server (Win2003)
Patrick Aikens wrote: I've installed cygwin 1.5 on my WHS box as Administrator. I've opened a cygwin terminal and executed the mkpasswd -l /etc/passwd and mkgroup -l /etc/group commands, executed ssh-host-setup and used privilege separation, and everything seems to have executed OK. I can ssh to that machine as Administrator just fine using password auth. However, I can't ssh in as any other user on that machine using password authentication - I get told that the password is incorrect, which I know it isn't. I can use key-based auth to login as any user, so I do have a workaround, but I'm curious as to why no user but Administrator can use password auth to log in? I've logged in via remote desktop as the user I wish to SSH as and ran ssh-user-config as that user (that's how I got the key-based login working). I haven't done that as Administrator, though, and it still lets me log in just fine there. Sorry if this is a bit rambling, but I've been working on this problem for a while and it's getting late where I am... cygcheck.out is attached. So, is this expected behavior then? Is it only possible to log in as the user that installed the server using password authentication? -- 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/
Re: expr error
Lenik wrote: ok, Thanks. Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) bt #0 0x0524 in ?? () #1 0x69181041 in ?? () from /usr/bin/cyggmp-3.dll #2 0x691c9000 in ?? () from /usr/bin/cyggmp-3.dll #3 0x691ca000 in ?? () from /usr/bin/cyggmp-3.dll #4 0x0022cdb8 in ?? () #5 0x61020273 in per_module::run_ctors () from /usr/bin/cygwin1.dll #6 0x006fa418 in ?? () #7 0x61020340 in dll::init () from /usr/bin/cygwin1.dll #8 0x in ?? () (gdb) info files The info files output confirms there's nothing unusual loaded into the process memory. That makes me think it's not BLODA. The presence of cyggmp-3.dll in the stack trace is interesting; that stack trace looks like it's probably correct, and we are running start-up constructors. Symbols from /usr/bin/expr. 0x69181000 - 0x691c4db8 is .text in /usr/bin/cyggmp-3.dll 0x691c5000 - 0x691c8e54 is .data in /usr/bin/cyggmp-3.dll 0x691c9000 - 0x691c9004 is .rdata in /usr/bin/cyggmp-3.dll 0x691ca000 - 0x691ca170 is .bss in /usr/bin/cyggmp-3.dll 0x691cb000 - 0x691cf8c6 is .edata in /usr/bin/cyggmp-3.dll 0x691d - 0x691d0410 is .idata in /usr/bin/cyggmp-3.dll 0x691d1000 - 0x691d2680 is .reloc in /usr/bin/cyggmp-3.dll 0x65b81000 - 0x65b86558 is .text in /usr/bin/cygintl-8.dll 0x65b87000 - 0x65b8703c is .data in /usr/bin/cygintl-8.dll 0x65b88000 - 0x65b88854 is .rdata in /usr/bin/cygintl-8.dll 0x65b89000 - 0x65b895d8 is .bss in /usr/bin/cygintl-8.dll 0x65b8a000 - 0x65b8a5ae is .edata in /usr/bin/cygintl-8.dll 0x65b8b000 - 0x65b8b7e0 is .idata in /usr/bin/cygintl-8.dll 0x65b8c000 - 0x65b8c460 is .reloc in /usr/bin/cygintl-8.dll 0x67c71000 - 0x67c86fe8 is .text in /usr/bin/cygiconv-2.dll 0x67c87000 - 0x67c87008 is .data in /usr/bin/cygiconv-2.dll 0x67c88000 - 0x67d6481c is .rdata in /usr/bin/cygiconv-2.dll 0x67d65000 - 0x67d654b8 is .bss in /usr/bin/cygiconv-2.dll 0x67d66000 - 0x67d66172 is .edata in /usr/bin/cygiconv-2.dll 0x67d67000 - 0x67d6734c is .idata in /usr/bin/cygiconv-2.dll 0x67d68000 - 0x67d68d00 is .reloc in /usr/bin/cygiconv-2.dll Now, this is interesting. All your DLLs are in very different places to mine, in a working instance of expr.exe: 0x63f41000 - 0x63f84db8 is .text in /usr/bin/cyggmp-3.dll 0x63f85000 - 0x63f88e54 is .data in /usr/bin/cyggmp-3.dll 0x63f89000 - 0x63f89004 is .rdata in /usr/bin/cyggmp-3.dll 0x63f8a000 - 0x63f8a170 is .bss in /usr/bin/cyggmp-3.dll 0x63f8b000 - 0x63f8f8c6 is .edata in /usr/bin/cyggmp-3.dll 0x63f9 - 0x63f90410 is .idata in /usr/bin/cyggmp-3.dll 0x63f91000 - 0x63f92680 is .reloc in /usr/bin/cyggmp-3.dll 0x6f5c1000 - 0x6f5c6558 is .text in /usr/bin/cygintl-8.dll 0x6f5c7000 - 0x6f5c703c is .data in /usr/bin/cygintl-8.dll 0x6f5c8000 - 0x6f5c8854 is .rdata in /usr/bin/cygintl-8.dll 0x6f5c9000 - 0x6f5c95d8 is .bss in /usr/bin/cygintl-8.dll 0x6f5ca000 - 0x6f5ca5ae is .edata in /usr/bin/cygintl-8.dll 0x6f5cb000 - 0x6f5cb7e0 is .idata in /usr/bin/cygintl-8.dll 0x6f5cc000 - 0x6f5cc460 is .reloc in /usr/bin/cygintl-8.dll 0x674c1000 - 0x674d6fe8 is .text in /usr/bin/cygiconv-2.dll 0x674d7000 - 0x674d7008 is .data in /usr/bin/cygiconv-2.dll 0x674d8000 - 0x675b481c is .rdata in /usr/bin/cygiconv-2.dll 0x675b5000 - 0x675b54b8 is .bss in /usr/bin/cygiconv-2.dll 0x675b6000 - 0x675b6172 is .edata in /usr/bin/cygiconv-2.dll 0x675b7000 - 0x675b734c is .idata in /usr/bin/cygiconv-2.dll 0x675b8000 - 0x675b8d00 is .reloc in /usr/bin/cygiconv-2.dll So I think you must have rebased, yes? Interesting. (gdb) info reg eax0x52486245376 ecx0x7c80e6cb2088822475 edx0x00 ebx0x11 esp0x22cd0c0x22cd0c ebp0x22cd180x22cd18 esi0x691c4da41763462564 edi0x2032 eip0x5240x524 eflags 0x10206[ PF IF RF ] cs 0x1b27 ss 0x2335 ds 0x2335 es 0x2335 fs 0x3b59 gs 0x00 (gdb) info frame Stack level 0, frame at 0x22cd10: eip = 0x524; saved eip 0x69181041 called by frame at 0x22cd14 Arglist at 0x22cd08, args: Locals at 0x22cd08, Previous frame's sp is 0x22cd10 Saved registers: eip at 0x22cd0c (gdb) quit Those all look sensible. Right, I think I have a guess what's going on. Please try re-installing libgmp3 using setup.exe and see if it solves the problem for you. I think this might be the same as http://www.cygwin.com/ml/cygwin/2009-02/msg00461.html http://www.cygwin.com/ml/cygwin/2009-02/msg00466.html http://sourceware.org/ml/binutils/2008-07/msg00372.html cheers, DaveK -- Unsubscribe info:
gcc linker flags
I've seen builds by other people in which the following linker flags are used: (a) --enable-auto-import (b) --enable-runtime-pseudo-reloc (c) --enable-auto-image-base My understanding is that (b) and (c) are already the default and that (a) will be the default when binutils is updated. Moreover, (a) is mostly used to suppress errors (though there are exceptions where it makes a difference). So none of these are really needed in most cases. Do I have it more or less right? I'm mainly interested in gcc-4 in cygwin 1.7, but if the answers would be different for gcc-3 or cygwin 1.5, I'd like to know that too. Thanks. Ken -- 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/
Cygwin 1.7.0-48, Vista Business SP1 and Openssh
Hi All... I just did a clean install of 1.7.0-48 on a Vista box today with the latest setup-1.7. The process went smoothly :-) But I noticed one strange thing. If I ssh into the box as myself (administrator account), all is well. If I ssh into the box as another account (non-administrator), the mount table only has / and /cygdrive. What I mean by this is, if I type mount, I do not get /usr/bin and /usr/lib listed. Now if I log in interactively to the box as the other user, and launch a Cygwin bash shell, the problem goes away on subsequent ssh's to the box by that user. If I then stop all Cygwin processes and then restart the ssd service, the problem reappears. Making the other account an administrator appeared to make no difference. Thanks, ...Karl _ Insert movie times and more without leaving Hotmail®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 -- 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/
Re: expr error
On 2009-5-18 11:45, Dave Korn wrote: Lenik wrote: ok, Thanks. Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) bt #0 0x0524 in ?? () #1 0x69181041 in ?? () from /usr/bin/cyggmp-3.dll #2 0x691c9000 in ?? () from /usr/bin/cyggmp-3.dll #3 0x691ca000 in ?? () from /usr/bin/cyggmp-3.dll #4 0x0022cdb8 in ?? () #5 0x61020273 in per_module::run_ctors () from /usr/bin/cygwin1.dll #6 0x006fa418 in ?? () #7 0x61020340 in dll::init () from /usr/bin/cygwin1.dll #8 0x in ?? () (gdb) info files The info files output confirms there's nothing unusual loaded into the process memory. That makes me think it's not BLODA. The presence of cyggmp-3.dll in the stack trace is interesting; that stack trace looks like it's probably correct, and we are running start-up constructors. Symbols from /usr/bin/expr. 0x69181000 - 0x691c4db8 is .text in /usr/bin/cyggmp-3.dll 0x691c5000 - 0x691c8e54 is .data in /usr/bin/cyggmp-3.dll 0x691c9000 - 0x691c9004 is .rdata in /usr/bin/cyggmp-3.dll 0x691ca000 - 0x691ca170 is .bss in /usr/bin/cyggmp-3.dll 0x691cb000 - 0x691cf8c6 is .edata in /usr/bin/cyggmp-3.dll 0x691d - 0x691d0410 is .idata in /usr/bin/cyggmp-3.dll 0x691d1000 - 0x691d2680 is .reloc in /usr/bin/cyggmp-3.dll 0x65b81000 - 0x65b86558 is .text in /usr/bin/cygintl-8.dll 0x65b87000 - 0x65b8703c is .data in /usr/bin/cygintl-8.dll 0x65b88000 - 0x65b88854 is .rdata in /usr/bin/cygintl-8.dll 0x65b89000 - 0x65b895d8 is .bss in /usr/bin/cygintl-8.dll 0x65b8a000 - 0x65b8a5ae is .edata in /usr/bin/cygintl-8.dll 0x65b8b000 - 0x65b8b7e0 is .idata in /usr/bin/cygintl-8.dll 0x65b8c000 - 0x65b8c460 is .reloc in /usr/bin/cygintl-8.dll 0x67c71000 - 0x67c86fe8 is .text in /usr/bin/cygiconv-2.dll 0x67c87000 - 0x67c87008 is .data in /usr/bin/cygiconv-2.dll 0x67c88000 - 0x67d6481c is .rdata in /usr/bin/cygiconv-2.dll 0x67d65000 - 0x67d654b8 is .bss in /usr/bin/cygiconv-2.dll 0x67d66000 - 0x67d66172 is .edata in /usr/bin/cygiconv-2.dll 0x67d67000 - 0x67d6734c is .idata in /usr/bin/cygiconv-2.dll 0x67d68000 - 0x67d68d00 is .reloc in /usr/bin/cygiconv-2.dll Now, this is interesting. All your DLLs are in very different places to mine, in a working instance of expr.exe: 0x63f41000 - 0x63f84db8 is .text in /usr/bin/cyggmp-3.dll 0x63f85000 - 0x63f88e54 is .data in /usr/bin/cyggmp-3.dll 0x63f89000 - 0x63f89004 is .rdata in /usr/bin/cyggmp-3.dll 0x63f8a000 - 0x63f8a170 is .bss in /usr/bin/cyggmp-3.dll 0x63f8b000 - 0x63f8f8c6 is .edata in /usr/bin/cyggmp-3.dll 0x63f9 - 0x63f90410 is .idata in /usr/bin/cyggmp-3.dll 0x63f91000 - 0x63f92680 is .reloc in /usr/bin/cyggmp-3.dll 0x6f5c1000 - 0x6f5c6558 is .text in /usr/bin/cygintl-8.dll 0x6f5c7000 - 0x6f5c703c is .data in /usr/bin/cygintl-8.dll 0x6f5c8000 - 0x6f5c8854 is .rdata in /usr/bin/cygintl-8.dll 0x6f5c9000 - 0x6f5c95d8 is .bss in /usr/bin/cygintl-8.dll 0x6f5ca000 - 0x6f5ca5ae is .edata in /usr/bin/cygintl-8.dll 0x6f5cb000 - 0x6f5cb7e0 is .idata in /usr/bin/cygintl-8.dll 0x6f5cc000 - 0x6f5cc460 is .reloc in /usr/bin/cygintl-8.dll 0x674c1000 - 0x674d6fe8 is .text in /usr/bin/cygiconv-2.dll 0x674d7000 - 0x674d7008 is .data in /usr/bin/cygiconv-2.dll 0x674d8000 - 0x675b481c is .rdata in /usr/bin/cygiconv-2.dll 0x675b5000 - 0x675b54b8 is .bss in /usr/bin/cygiconv-2.dll 0x675b6000 - 0x675b6172 is .edata in /usr/bin/cygiconv-2.dll 0x675b7000 - 0x675b734c is .idata in /usr/bin/cygiconv-2.dll 0x675b8000 - 0x675b8d00 is .reloc in /usr/bin/cygiconv-2.dll So I think you must have rebased, yes? Interesting. (gdb) info reg eax0x52486245376 ecx0x7c80e6cb2088822475 edx0x00 ebx0x11 esp0x22cd0c0x22cd0c ebp0x22cd180x22cd18 esi0x691c4da41763462564 edi0x2032 eip0x5240x524 eflags 0x10206[ PF IF RF ] cs 0x1b27 ss 0x2335 ds 0x2335 es 0x2335 fs 0x3b59 gs 0x00 (gdb) info frame Stack level 0, frame at 0x22cd10: eip = 0x524; saved eip 0x69181041 called by frame at 0x22cd14 Arglist at 0x22cd08, args: Locals at 0x22cd08, Previous frame's sp is 0x22cd10 Saved registers: eip at 0x22cd0c (gdb) quit Those all look sensible. Right, I think I have a guess what's going on. Please try re-installing libgmp3 using setup.exe and see if it solves the problem for you. I think this might be the same as http://www.cygwin.com/ml/cygwin/2009-02/msg00461.html http://www.cygwin.com/ml/cygwin/2009-02/msg00466.html http://sourceware.org/ml/binutils/2008-07/msg00372.html cheers, DaveK
Re: Cygwin 1.7.0-48, Vista Business SP1 and Openssh
On Sun, May 17, 2009 at 09:16:36PM -0700, Karl M wrote: If I ssh into the box as myself (administrator account), all is well. If I ssh into the box as another account (non-administrator), the mount table only has / and /cygdrive. What I mean by this is, if I type mount, I do not get /usr/bin and /usr/lib listed. Now if I log in interactively to the box as the other user, and launch a Cygwin bash shell, the problem goes away on subsequent ssh's to the box by that user. If I then stop all Cygwin processes and then restart the ssd service, the problem reappears. Making the other account an administrator appeared to make no difference. Could we have more details? Please attach a cygcheck output and a copy of your /etc/fstab file. cgf -- 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/
RE: Cygwin 1.7.0-48, Vista Business SP1 and Openssh
From: Karl Subject: Cygwin 1.7.0-48, Vista Business SP1 and Openssh Date: Sun, 17 May 2009 21:16:36 -0700 Hi All... I just did a clean install of 1.7.0-48 on a Vista box today with the latest setup-1.7. The process went smoothly :-) But I noticed one strange thing. If I ssh into the box as myself (administrator account), all is well. If I ssh into the box as another account (non-administrator), the mount table only has / and /cygdrive. What I mean by this is, if I type mount, I do not get /usr/bin and /usr/lib listed. Now if I log in interactively to the box as the other user, and launch a Cygwin bash shell, the problem goes away on subsequent ssh's to the box by that user. If I then stop all Cygwin processes and then restart the ssd service, the problem reappears. Making the other account an administrator appeared to make no difference. Thanks, ...Karl If I add back the fstab entries for /usr/lib and /usr/bin, all is well. I have attached my fstab file. Thanks, ...Karl _ Insert movie times and more without leaving Hotmail®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009none / cygdrive text,noacl,posix=0 0 0 C:/Cygwin/bin /usr/bin ntfs binary 0 0 C:/Cygwin/lib /usr/lib ntfs binary 0 0 -- 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/
RE: Cygwin 1.7.0-48, Vista Business SP1 and Openssh
Date: Mon, 18 May 2009 00:34:44 -0400 From: cgf Subject: Re: Cygwin 1.7.0-48, Vista Business SP1 and Openssh On Sun, May 17, 2009 at 09:16:36PM -0700, Karl M wrote: If I ssh into the box as myself (administrator account), all is well. If I ssh into the box as another account (non-administrator), the mount table only has / and /cygdrive. What I mean by this is, if I type mount, I do not get /usr/bin and /usr/lib listed. Now if I log in interactively to the box as the other user, and launch a Cygwin bash shell, the problem goes away on subsequent ssh's to the box by that user. If I then stop all Cygwin processes and then restart the ssd service, the problem reappears. Making the other account an administrator appeared to make no difference. Could we have more details? Please attach a cygcheck output and a copy of your /etc/fstab file. cgf Attached...Thanks ...Karl _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009 Cygwin Configuration Diagnostics Current System Time: Sun May 17 21:41:12 2009 Windows Vista Business Ver 6.0 Build 6001 Service Pack 1 Path: C:\Cygwin\usr\local\bin C:\Cygwin\bin C:\Cygwin\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Program Files\ATI Technologies\ATI.ACE\Core-Static C:\Program Files\SMARTMonTools\bin C:\Program Files\jZip C:\Program Files\FlexDLL C:\Program Files\GTK+\bin C:\Program Files\Unison C:\Program Files\QuickTime\QTSystem\ C:\Program Files\Common Files\Roxio Shared\DLLShared\ C:\Program Files\Common Files\Roxio Shared\10.0\DLLShared C:\Program Files\Objective Caml\bin Output from C:\Cygwin\bin\id.exe (nontsec) UID: 1000(km) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) Output from C:\Cygwin\bin\id.exe (ntsec) UID: 1000(km) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'km' PWD = '/home/km' CYGWIN = 'tty' HOME = '/home/km' TRACE_FORMAT_SEARCH_PATH = '\\NTREL202.ntdev.corp.microsoft.com\4F18C3A5-CA09-4DBD-B6FC-219FDD4C6BE0\TraceFormat' HOMEPATH = '\Users\km' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\km\AppData\Roaming' HOSTNAME = 'Coyote' TERM = 'cygwin' RoxioCentral = 'C:\Program Files\Common Files\Roxio Shared\10.0\Roxio Central36\' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 11, GenuineIntel' DFSTRACINGON = 'FALSE' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/c/Windows/system32' USERDOMAIN = 'COYOTE' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' DevMgr_Show_Nonpresent_Devices = '1' VS90COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio\Common7\Tools\' TEMP = '/c/Users/km/AppData/Local/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LIB = 'C:\Program Files\GTK+\lib' SSH_AUTH_SOCK = '/home/km/.ssh/ssh-auth-sock' UNISON = 'C:\Users\km\Unison' QTJAVA = 'C:\Program Files\Java\jre6\lib\ext\QTJava.zip' USERNAME = 'km' PROCESSOR_LEVEL = '6' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Users\km' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\COYOTE' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\km\AppData\Local' !C: = 'C:\Windows\System32' ProgramData = 'C:\ProgramData' SHLVL = '1' OCAMLLIB = 'C:\Program Files\Objective Caml\lib' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/c/Users/km/AppData/Local/Temp' SYSTEMROOT = 'C:\Windows' PRINTER = 'Microsoft XPS Document Writer' CVS_RSH = 'C:\Cygwin\bin\ssh.exe' PROCESSOR_REVISION = '0f0b' CLASSPATH = '.;C:\Program Files\Java\jre6\lib\ext\QTJava.zip' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '4' INCLUDE = 'C:\Program Files\GTK+\include' COMPUTERNAME = 'COYOTE' !ExitCode = '' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.gov%2fcygwin%2f HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.gov%2fcygwin%2f\OpenWithList HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\Cygwin' obcaseinsensitive set to 1 c: hd NTFS953866Mb 24% CP CS UN PA FC d: cd N/AN/A C:\Cygwin / system binmode C:\Cygwin\bin /usr/bin system binmode C:\Cygwin\lib /usr/lib system binmode . / system textmode,cygdrive,noacl,posix=0 Found:
Re: Cygwin 1.7.0-48, Vista Business SP1 and Openssh
On Sun, May 17, 2009 at 09:39:58PM -0700, Karl M wrote: From: Karl Subject: Cygwin 1.7.0-48, Vista Business SP1 and Openssh Date: Sun, 17 May 2009 21:16:36 -0700 I just did a clean install of 1.7.0-48 on a Vista box today with the latest setup-1.7. The process went smoothly :-) But I noticed one strange thing. If I ssh into the box as myself (administrator account), all is well. If I ssh into the box as another account (non-administrator), the mount table only has / and /cygdrive. What I mean by this is, if I type mount, I do not get /usr/bin and /usr/lib listed. Now if I log in interactively to the box as the other user, and launch a Cygwin bash shell, the problem goes away on subsequent ssh's to the box by that user. If I then stop all Cygwin processes and then restart the ssd service, the problem reappears. Making the other account an administrator appeared to make no difference. Thanks, If I add back the fstab entries for /usr/lib and /usr/bin, all is well. What does this mean? Did you send the fstab file from the failing case? cgf -- 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/
Re: gcc linker flags
Ken Brown wrote: I've seen builds by other people in which the following linker flags are used: (a) --enable-auto-import (b) --enable-runtime-pseudo-reloc (c) --enable-auto-image-base My understanding is that (b) and (c) are already the default and that (a) will be the default when binutils is updated. Moreover, (a) is mostly used to suppress errors (though there are exceptions where it makes a difference). So none of these are really needed in most cases. Do I have it more or less right? You could equally say All or some of them are needed in most cases, but hopefully the compiler and toolchain will take care of it for you in future and you won't have to bother about them. cheers, DaveK -- 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/
RE: Cygwin 1.7.0-48, Vista Business SP1 and Openssh
Date: Mon, 18 May 2009 00:45:54 -0400 From: cgf Subject: Re: Cygwin 1.7.0-48, Vista Business SP1 and Openssh On Sun, May 17, 2009 at 09:39:58PM -0700, Karl M wrote: From: Karl Subject: Cygwin 1.7.0-48, Vista Business SP1 and Openssh Date: Sun, 17 May 2009 21:16:36 -0700 I just did a clean install of 1.7.0-48 on a Vista box today with the latest setup-1.7. The process went smoothly :-) But I noticed one strange thing. If I ssh into the box as myself (administrator account), all is well. If I ssh into the box as another account (non-administrator), the mount table only has / and /cygdrive. What I mean by this is, if I type mount, I do not get /usr/bin and /usr/lib listed. Now if I log in interactively to the box as the other user, and launch a Cygwin bash shell, the problem goes away on subsequent ssh's to the box by that user. If I then stop all Cygwin processes and then restart the ssd service, the problem reappears. Making the other account an administrator appeared to make no difference. Thanks, If I add back the fstab entries for /usr/lib and /usr/bin, all is well. What does this mean? Did you send the fstab file from the failing case? The first line of the fstab is used for the failing case, adding the second and third lines suppresses the problem. ...Karl _ Insert movie times and more without leaving Hotmail®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 -- 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/
Re: Cygwin 1.7.0-48, Vista Business SP1 and Openssh
On Sun, May 17, 2009 at 09:53:15PM -0700, Karl M wrote: The first line of the fstab is used for the failing case, adding the second and third lines suppresses the problem. Does the latest snapshot work any better for you? cgf -- 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/
RE: Cygwin 1.7.0-48, Vista Business SP1 and Openssh
Date: Mon, 18 May 2009 01:12:37 -0400 From: cgf Subject: Re: Cygwin 1.7.0-48, Vista Business SP1 and Openssh On Sun, May 17, 2009 at 09:53:15PM -0700, Karl M wrote: The first line of the fstab is used for the failing case, adding the second and third lines suppresses the problem. Does the latest snapshot work any better for you? cgf Yes it does...Thanks, ...Karl _ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009 -- 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/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-17 15:52, Lenik wrote: 2, configure failed: bash-3.2$ ./configure 5 [main] expr 952 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) ./configure: line 56: 952 Segmentation fault (core dumped) expr a : '\(a\)' /dev/null 21 4 [main] expr 2808 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3516 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3328 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2648 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 900 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 1840 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2972 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) The expr error is fixed, and I can build cygpath from source now. Though I don't have NTDDK in hand, I'm suprised how it could be compiled. I can get the correct result from the new cygpath now, without -C option. Thank you guys. Lenik -- 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/
