On 26/01/2009 09:20, Jason Tishler wrote:
I don't know, but building Python 2.6 with openssl support causes the
treading related operations to core dump. Maybe this particular code
path tickles a problem in Cygwin? For some reason, Python 2.5.2 and 3.0
do not exhibit the same behavior.
It see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Huang Bambo on 7/22/2009 9:37 PM:
> $ updatedb
> assertion "ent->fts_info == FTS_NSOK || state.type != 0" failed: file
> "/usr/src/findutils-4.5.4-1/src/findutils-4.5.4/find/ftsfind.c", line
> 475, function: consider_visiting
It would be
$ updatedb
assertion "ent->fts_info == FTS_NSOK || state.type != 0" failed: file
"/usr/src/findutils-4.5.4-1/src/findutils-4.5.4/find/ftsfind.c", line
475, function: consider_visiting
*** starting debugger for pid 28372, tid 27324
5 [sig] find 30340 try_to_debug: Failed to start debugger, Win
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 7/22/2009 4:26 PM:
>> 2009-07-22 Eric Blake
>>
>> * exceptions.cc (handle_exceptions): Set si_addr according to
>> POSIX for SIGSEGV.
>>
> Looks ok. Please check in.
Done.
- --
Don't work too hard, mak
Does anyone know of an ntfsclone package that works under 1.7? I tried
compiling 2.0 from sourceforge. I didn't get any errors from ./configure,
make, or make install but the executable doesn't return anything when I run
it. ntfsclone --help doesn't return anything either.
I've been using dd wi
Ken Brown writes:
> On 7/21/2009 10:22 PM, Haojun Bao wrote:
>> Here's how to reproduce it:
>>
>> 1. install w3m-el
>>
>> 2. start Xwin, and then start emacs with:
>>emacs.exe -q -l ~/1.el
>
> Cygwin's emacs-*-23.0.92-10 packages don't provide emacs.exe. So you
> must be using the version yo
Quoting Joshua John Bialkowski
I'm using g++ (GCC) version 3.4.4 from the cygwin installer, and
I've run in to
this very confusing problem. I'm compiling with the -mno-cygwin option
[...]
The problem I have is that when I launch a separate thread, and
then throw an
exception in that separate
Quoting Christopher Faylor
On Wed, Jul 22, 2009 at 08:05:21PM -0400, Joshua John Bialkowski wrote:
I've spent the entire day scouring the internet for a solution to my
problem, so
I apologize if this has already been answered. If that is the case a
pointer in
the right direction would be appr
I'm using g++ (GCC) version 3.4.4 from the cygwin installer, and
I've run in to
this very confusing problem. I'm compiling with the -mno-cygwin option
[...]
The problem I have is that when I launch a separate thread, and then
throw an
exception in that separate thread, my program will crash...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new release of m4, 1.4.13-2, is available for those testing cygwin 1.7,
replacing 1.4.13-1 and leaving 1.4.10b-2 as previous.
NEWS
This is a minor patch release to fix a crash identified when using m4 with
stdin closed. It also picks up the ne
On Wed, Jul 22, 2009 at 08:05:21PM -0400, Joshua John Bialkowski wrote:
>I've spent the entire day scouring the internet for a solution to my problem,
>so
>I apologize if this has already been answered. If that is the case a pointer in
>the right direction would be appreciated.
>[snip]
>#include
On 2009-07-23 00:05Z, Joshua John Bialkowski wrote:
>
> I'm using g++ (GCC) version 3.4.4 from the cygwin installer, and I've run in
> to
> this very confusing problem. I'm compiling with the -mno-cygwin option
[...]
> The problem I have is that when I launch a separate thread, and then throw an
I've spent the entire day scouring the internet for a solution to my problem, so
I apologize if this has already been answered. If that is the case a pointer in
the right direction would be appreciated.
I'm using g++ (GCC) version 3.4.4 from the cygwin installer, and I've run in to
this very confu
The following package has been updated for Cygwin 1.7:
(*) cygport: 0.9.8-1
Changes in this release:
* OCaml natdynlink modules (*.cmxs) are treated as DLLs in terms of
postinst-strip and dependency-list steps.
* Fixed DEPS_PATH.
* Various fixes for building gcc.
* apache2.cygclass: APREQ_* a
On Wed, Jul 22, 2009 at 09:18:57PM +, Eric Blake wrote:
>POSIX requires that for SIGSEGV and SIGBUS, the si_addr member of siginfo_t be
>set to the memory address where access failed, and not the address of the
>instruction attempting to access that address (for SIGILL and SIGFPE, the
>si_ad
I've updated libsigsegv to 2.6-1 and added a shared library in
libsigsegv0-2.6-1
I hope this solves the SEH corruption issue a little bit, as discussed
at http://cygwin.com/ml/cygwin/2009-07/msg00639.html
It's a small library for handling page faults in user mode.
A page fault occurs when a pro
POSIX requires that for SIGSEGV and SIGBUS, the si_addr member of siginfo_t be
set to the memory address where access failed, and not the address of the
instruction attempting to access that address (for SIGILL and SIGFPE, the
si_addr field is correct, and for all other signals, the si_addr is u
The following packages have been updated for Cygwin 1.7:
* dbus-1.2.16-1
* libdbus1_3-1.2.16-1
* libdbus1-devel-1.2.16-1
This is an update to the latest upstream release.
D-Bus is an IPC system, a simple way for applications to talk to one
another.
D-Bus supplies both a system bus (for event
Corinna Vinschen cygwin.com> writes:
> > However, for access to the filesystem information, the READ_CONTROL
> > isn't necessary. A desired access of 0 is sufficient in every case
> > I could lay my hands on (NTFS, NFS, Samba, FAT32, HGFS).
> >
> along these lines, can you please test the chang
Eric,
On Jul 22 20:54, Corinna Vinschen wrote:
> Hi Chuck,
>
> today I found a filesystem, HGFS, which is sensible against using just
> the READ_CONTROL flag in calls to NtOpenFile. The result is a
> STATUS_INVALID_PARAMETER status code.
>
> However, for access to the filesystem information, th
On Jul 22 14:47, Denis Petrov wrote:
> I have a file with a character 0xf028 in the name, which seems to
> break Cygwin's file name conversion routine. I took a cursory look
> through the code and I am going to try to step through it with a
> debugger but I thought maybe someone already has an idea
2009/7/22 Jon TURNEY:
> j...@byron ~
> $ mount -m
> //necker/jon /home/jon smbfs binary,noexec,noacl,user 0 0
> none /cygdrive cygdrive binary,posix=0,user 0 0
>
> I want this to be permanent, so I edit /etc/fstab to add a copy of the line:
> //necker/jon /home/jon smbfs binary,noexec,noacl,user 0
Hi Chuck,
today I found a filesystem, HGFS, which is sensible against using just
the READ_CONTROL flag in calls to NtOpenFile. The result is a
STATUS_INVALID_PARAMETER status code.
However, for access to the filesystem information, the READ_CONTROL
isn't necessary. A desired access of 0 is suff
I have a file with a character 0xf028 in the name, which seems to
break Cygwin's file name conversion routine. I took a cursory look
through the code and I am going to try to step through it with a
debugger but I thought maybe someone already has an idea how to make
Cygwin to play nice with it?
He
On Jul 22 19:59, Wolfgang Goetz wrote:
> Corinna Vinschen wrote:
> > On Jul 21 21:18, Wolfgang Goetz wrote:
> >> Corinna Vinschen wrote:
> >> snippet from 'net config workstation':
> >> ...
> >> Workstation domain EMEA
> >> ...
> >> Logon domain AD1
> >>
>
On Jul 23 03:02, Shaddy Baddah wrote:
> Corinna Vinschen wrote:
>> There are two places which check for STATUS_EAS_NOT_SUPPORTED.
>> If you check additionally for STATUS_NOT_SUPPORTED in both places,
>> does it work now?
>>
> That worked! Thank you very very much. I've attached the patch.
Cool.
Corinna Vinschen wrote:
> On Jul 21 21:18, Wolfgang Goetz wrote:
>> Corinna Vinschen wrote:
>> snippet from 'net config workstation':
>> ...
>> Workstation domain EMEA
>> ...
>> Logon domain AD1
>>
>>> Are you sure /etc/passwd is really correct?
>> made wit
Eric Blake byu.net> writes:
> >> Is there a chance that this represents a bug in
> >> libsigsegv SEH handling that needs to be reported upstream?
> >
> > I'll report that, if it turns out so.
>
> I've already mentioned it to Bruno, and am still working on a fix.
FWIW, rebuilding m4 1.4.13 pick
Hi Corinna,
Corinna Vinschen wrote:
The only thing obviously broken now are symlinks. I've done some
debugging and tracked it down to the fact that any call like this:
path.c:2254: if (NT_SUCCESS (status)
path.c:2255: && NT_SUCCESS (status
path.c:2256: = NtQueryInformation
On Jul 22 16:18, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > Thanks, but no. There's at least this one problem left which I simply
> > don't know how to fix. The situation is thus:
> >
> > fd = open()
> > fork ()
> > --> child
> > flock(fd, LOCK_SH);
> > ex
On Jul 22 17:11, Jon TURNEY wrote:
>
> j...@byron ~
> $ mount -o noacl //necker/jon /home/jon
> mount: warning - /home/jon does not exist.
> mount: defaulting to '--no-executable' flag for speed since native path
>references a remote share. Use '-f' option to override.
>
> j...@byron ~
> $
Corinna Vinschen cygwin.com> writes:
> Thanks, but no. There's at least this one problem left which I simply
> don't know how to fix. The situation is thus:
>
> fd = open()
> fork ()
> --> child
> flock(fd, LOCK_SH);
> exit ();
>
> The problem is that the lock disappears whe
j...@byron ~
$ mount -o noacl //necker/jon /home/jon
mount: warning - /home/jon does not exist.
mount: defaulting to '--no-executable' flag for speed since native path
references a remote share. Use '-f' option to override.
j...@byron ~
$ mount -m
//necker/jon /home/jon smbfs binary,noex
On Jul 23 01:40, Shaddy Baddah wrote:
> Hi,
>
> I've been trying to work through a problem with running cygwin from a
> VBoxSharedFolderFS (VirtualBox) folder mounted on my guest host. I've
> tried to work through the problem on my own, as I would imagine that
> VBoxSharedFolderFS support in cygwin
On Jul 22 15:27, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > > $ ./foo 4& sleep 2; ./foo 0
> > >
> > > Oops - process 14060 got the lock before 12692 and 21704 exited.
> >
> > This looks different with my patch:
> >
>
> Yep, so far, it looks like your patch follows the sema
Hi,
I've been trying to work through a problem with running cygwin from a
VBoxSharedFolderFS (VirtualBox) folder mounted on my guest host. I've
tried to work through the problem on my own, as I would imagine that
VBoxSharedFolderFS support in cygwin is of almost zero importance.
However I though
On Wed, Jul 22, 2009 at 03:01:44PM +0200, Olivier Lefevre wrote:
>I was hoping we would not be playing ye olde finger-pointing
>game. It used to work and it no longer does yet the interpreter
>has not changed. How could it not be an issue within Cygwin?
>
>I am not asking to take responsibility for
Corinna Vinschen cygwin.com> writes:
> > $ ./foo 4& sleep 2; ./foo 0
> >
> > Oops - process 14060 got the lock before 12692 and 21704 exited.
>
> This looks different with my patch:
>
Yep, so far, it looks like your patch follows the semantics I expect for every
one of my tests (the lock rem
On Jul 22 14:41, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> >
> > Do you have a working C testcase to demonstrate this?
>
> I still haven't gotten around to trying your patch, but here is the testcase
> I'm using (I guess it's not that simple, after all):
> [...testcase...]
>
On 7/21/2009 10:22 PM, Haojun Bao wrote:
Here's how to reproduce it:
1. install w3m-el
2. start Xwin, and then start emacs with:
emacs.exe -q -l ~/1.el
Cygwin's emacs-*-23.0.92-10 packages don't provide emacs.exe. So you
must be using the version you compiled yourself, unless you somehow
Corinna Vinschen cygwin.com> writes:
>
> Do you have a working C testcase to demonstrate this?
I still haven't gotten around to trying your patch, but here is the testcase
I'm using (I guess it's not that simple, after all):
$ cat foo.c
#include
#include
#include
#include
#include
#inclu
Olivier Lefevre wrote:
> By the way, this still works fine from cmd.com, so it
> really is a Cygwin issue.
This sounds suspiciously like a pty issue. Please try the following:
>From your normal bash prompt, type
echo $CYGWIN
If 'tty' is there, then figure out why and remove it at the source
Hello Eric,
Your suggestion helped. It turned out to that McAffe's virus scanner
was screwing up Cygwin. Killing it made the script work.
Thanks.
Sincerely,
Vitas Povilaitis
On Wed, Jul 22, 2009 at 8:19 AM, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to V
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Olivier Lefevre on 7/22/2009 7:01 AM:
> I was hoping we would not be playing ye olde finger-pointing
> game. It used to work and it no longer does yet the interpreter
> has not changed. How could it not be an issue within Cygwin?
But your
Olivier Lefevre wrote:
> I was hoping we would not be playing ye olde finger-pointing
> game. It used to work and it no longer does yet the interpreter
> has not changed. How could it not be an issue within Cygwin?
Because no Cygwin code is running in this application. Code that is not
running
I was hoping we would not be playing ye olde finger-pointing
game. It used to work and it no longer does yet the interpreter
has not changed. How could it not be an issue within Cygwin?
I am not asking to take responsibility for non-Cygwin executables
but to offer a hint as to what could possibly
Vitas Povilaitis wrote:
> Occasionally, a subscript fails to run, as in this example:
> $ ./t.sh Hello-1.0.0
> PACKAGE Hello VERSION 1.0.0
> PACKAGE Hello VERSION
> PACKAGE Hello VERSION 1.0.0
>
> $ ./t.sh Hello-1.0.0
> PACKAGE Hello VERSION 1.0.0
> PACKAGE Hello VERSION 1.0.0
> PACKAGE VERSION
By the way, this still works fine from cmd.com, so it
really is a Cygwin issue.
-- O.L.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubsc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Olivier Lefevre on 7/22/2009 6:45 AM:
>> But I would be interested in seeing the output of 'cygcheck Q.exe'
>
> c:\Programme/Kx/q/w32/q.exe
> C:\WINDOWS\system32\WS2_32.dll
> C:\WINDOWS\system32\ADVAPI32.dll
> C:\WINDOWS\syst
But I would be interested in seeing the output of 'cygcheck Q.exe'
c:\Programme/Kx/q/w32/q.exe
C:\WINDOWS\system32\WS2_32.dll
C:\WINDOWS\system32\ADVAPI32.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOW
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Olivier Lefevre on 7/22/2009 6:28 AM:
>> That's your bash version. What are your cygwin, libreadline6 and
>> libreadline7 versions?
>
> I have attached the output of 'cygcheck -svr'
Nothing out of the ordinary jumped out at me. But you
That's your bash version. What are your cygwin, libreadline6 and
libreadline7 versions?
I have attached the output of 'cygcheck -svr'
And an example of a failing interpreter would be...?
You most likely haven't heard of it: Q (available from www.kx.com)
Free download but need to register.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Vitas Povilaitis on 7/22/2009 6:15 AM:
> $ ./t.sh Hello-1.0.0
> PACKAGE Hello VERSION 1.0.0
> PACKAGE Hello VERSION
> PACKAGE Hello VERSION 1.0.0
> This is under Cygwin 1.5.25-15 under Windows XP Ver. 5.1 Build 2600
> Service Pack 2.
It c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Olivier Lefevre on 7/22/2009 6:12 AM:
> Since the last Cygwin update (I am now at 3.2.49(22)-release)
That's your bash version. What are your cygwin, libreadline6 and
libreadline7 versions?
> readline is no longer working in some interp
Occasionally, a subscript fails to run, as in this example:
$ cat t.sh
#!/bin/bash
PACKAGEVERSION=$1
PACKAGE=`echo $PACKAGEVERSION | sed 's/^\(.*\)-.*$/\1/'`
VERSION=`echo $PACKAGEVERSION | sed 's/^.*-\(.*\)$/\1/'`
echo "PACKAGE $PACKAGE VERSION $VERSION"
PACKAGE=`echo $PACKAGEVERSION | sed 's/
Since the last Cygwin update (I am now at 3.2.49(22)-release)
readline is no longer working in some interpreters started
from the bash shell, i.e., the languages offer an interactive
prompt and I used to be able to recall earlier commands
with the arrow keys but no more. This still works from the
On Jul 22 13:57, Thomas Wolff wrote:
> Corinna Vinschen wrote:
> > On Jul 19 21:28, Andy Koppe wrote:
> > > A couple of small mistakes in
> > > http://cygwin.com/1.7/cygwin-ug-net/setup-locale.html#setup-locale-charsetlist:
> > > ISO-8859-13 and -15 have codepage numbers 28603 and 28605, not 28563
Corinna Vinschen wrote:
> On Jul 19 21:28, Andy Koppe wrote:
> > A couple of small mistakes in
> > http://cygwin.com/1.7/cygwin-ug-net/setup-locale.html#setup-locale-charsetlist:
> > ISO-8859-13 and -15 have codepage numbers 28603 and 28605, not 28563
> > and 28565.
> Fixed.
I don't see it fixed o
On Jul 22 12:08, Corinna Vinschen wrote:
> Does the below patch fix the problem? Does the reasoning sound...
> reasonable?
> [...]
> - node->del_my_locks (after_fork ? 0 : get_unique_id (), get_handle ());
> + node->del_my_locks (after_fork ? 0 : get_unique_id (),
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reini Urban on 7/22/2009 2:24 AM:
>> Is there a chance that this represents a bug in
>> libsigsegv SEH handling that needs to be reported upstream?
>
> I'll report that, if it turns out so.
I've already mentioned it to Bruno, and am stil
On Jul 21 21:18, Wolfgang Goetz wrote:
> Corinna Vinschen wrote:
> > On Jul 20 23:54, Wolfgang Goetz wrote:
> snippet from 'net config workstation':
> ...
> Workstation domain EMEA
> ...
> Logon domain AD1
>
>
> > Are you sure /etc/passwd is really correc
On Jul 21 23:26, Eric Blake wrote:
> I finally figured out why autoconf is still failing its flock-related tests,
> and why perl was reliably failing even though my simple attempts in C were
> always passing. It turns out that if you do:
>
> open
> flock(LOCK_EX)
> if (!fork)
> execlp("sleep"
2009/7/17 Eric Blake:
> Dave Korn writes:
>
>> That looks fairly robust to me, shouldn't give us any problems. Question
>> is, what does the code that hooks and unhooks the exception handler look
>> like,
>> and where does it get called from?
>
> static void
> do_install_main_exception_filter (
2009/7/16 Wolfgang Goetz:
> Thrall, Bryan wrote:
>> Wolfgang Goetz wrote on Thursday, July 09, 2009 6:03 AM:
>>> perl-Tk is broken in 1.5 and 1.7
>>> $ widget
> ...NOK
>>> but is working under debugger control:
>>> $ ddd /usr/bin/widget (->Run ->Cont)
> ...OK
>
>> I've had similar problems; see
>>
64 matches
Mail list logo
