Hi all,
(Please CC me in replies, I'm not subscribed to the list)
Question: is this a Cygwin bug, gcc bug, or somebody else's bug entirely?
The following STC shows the problem:
$ cat bug.cpp
#include cstdio
static thread_local struct X {
int x;
X() { puts(hi); }
~X() { puts(bye!);
On 12/11/2013 5:30 PM, JonY wrote:
On 11/13/2013 02:35, Yucong Sun wrote:
Good new! I've found the link failure issue, it is caused by -rdynamic
sunyc@sunyc-wks ~
$ cat 2.cc
#include deque
struct tick_event {
int i;
};
int main() {
std::dequetick_event * list;
tick_event *a
On 04/11/2013 7:47 AM, Andrey Repin wrote:
Greetings, Kptain!
Today my Cygwin package is around 1.4Gb.
I've tried to restrict amount of package required by distribution, it seems
lot of dependencies are required.
Does someone know how to restrict and optimize Cygwin packages knowing I'm
using
On 04/11/2013 9:24 AM, Ryan Johnson wrote:
On 04/11/2013 7:47 AM, Andrey Repin wrote:
Greetings, Kptain!
Today my Cygwin package is around 1.4Gb.
I've tried to restrict amount of package required by distribution,
it seems
lot of dependencies are required.
Does someone know how to restrict
On 04/11/2013 11:00 AM, Christopher Faylor wrote:
On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote:
On 10/30/2013 9:51 AM, Ryan Johnson wrote:
On 30/10/2013 8:48 AM, Charles Wilson wrote:
Yeah; even for my stripped-down version, I need to pre-process the
setup.ini and remove all
On 31/10/2013 2:11 PM, Jason Tishler wrote:
On Tue, Oct 15, 2013 at 12:28:31PM +0900, nu774 wrote:
Installing libffi-devel will let python pick system libffi, so you
can skip that libffi building part you are currently stuck.
(2013/10/15 10:10), Ryan Johnson wrote:
/usr/src/python3-3.3.2-3
On 30/10/2013 8:48 AM, Charles Wilson wrote:
On 10/26/2013 5:40 AM, David Stacey wrote:
On 25/10/13 17:12, Charles Wilson wrote:
Oooo - this sounds like fun. I've knocked up some (very bad) perl that
gives you what you need. It generates a graphviz file that you can pipe
to 'dot' to generate
On 25/10/2013 12:12 PM, Charles Wilson wrote:
Does anybody have a script or a tool that can parse a setup.ini and
generate a dependency graph? I'm using pmcyg to create a
stripped-down standalone installation CD and it's too big, so I'm
trying to figure out where the culprit is that's pulling
Hi python maintainer,
Is there any chance to get a build of python 3.3 on x86_64? (I need PEP
380, delegating to a subgenerator, and the Windows version doesn't play
nice with cygwin shells). I tried downloading the sources and applying
the patches mentioned in the .cygport file for the
On 14/10/2013 10:17 AM, Ryan Johnson wrote:
Hi python maintainer,
Is there any chance to get a build of python 3.3 on x86_64? (I need
PEP 380, delegating to a subgenerator, and the Windows version doesn't
play nice with cygwin shells). I tried downloading the sources and
applying the patches
On 08/10/2013 7:48 PM, Warren Young wrote:
On 10/8/2013 04:22, Don Hatch wrote:
Checking in a text file of size = 256k
corrupts the rcs file, irretrievably losing most of the contents
It's documented in the rcs NEWS file:
- Env var RCS_MEM_LIMIT controls stdio threshold.
For
On 09/10/2013 9:37 AM, Warren Young wrote:
On 10/9/2013 01:05, Don Hatch wrote:
Would it be possible to simply declare 5.8 DOA
The Cygwin package system allows one to mark 5.8-1 as obsolete, but I
don't know if it can be told and downgrade to 5.7-11.
If not, can we make a 5.9 that's
On 08/10/2013 9:53 AM, Jakub Horbacewicz wrote:
Hello,
I have to use Windows server for making backups of network devices. To
accomplish that I have to run Rancid, so I need to install Cygwin. Can
you help me with compiling Rancid through Cygwin? I cannot find any
tutorial or tips in google.
On 08/10/2013 2:52 PM, Don Hatch wrote:
I've always been baffled by cygwin setup's behavior.
I wish I understood it and could control it.
Here is a typical example where I want to do something
very simple and I have no idea how to get the setup program
to do it. Help!
My goal: upgrade rcs to
On 08/10/2013 3:34 PM, Larry Hall (Cygwin) wrote:
On 10/8/2013 3:25 PM, David Boyce wrote:
But as a point of practicality, 64-bit Cygwin can help with some
cases of
DLL address space collisions. So if you haven't experimented with
64-bit Cygwin in your environment, it may be worth your time.
On 04/10/2013 9:21 AM, Erik Soderquist wrote:
if I succeeded I would by then be running a Fedora system rather
than CentOS; IS team here would have had my hide for breakfast...
Next attempt: trying to get a test VM for Ubuntu or Mint; IS team may
have my hide just for asking that one...
I
On 02/10/2013 7:55 PM, Erik Soderquist wrote:
On Wed, Oct 2, 2013 at 6:51 PM, Ryan Johnson
ryan.john...@cs.utoronto.ca wrote:
I doubt it's an X-server code issue. You tried it on too many machines with
problems, and too many other people aren't spamming the list about this,
which suggests it's
On 03/10/2013 11:44 AM, Erik Soderquist wrote:
Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already
applied. VM has 512 MB ram, and the only package I installed after the
OS was cygwin. Issue presents in this environment as soon as Firefox
connects/starts. Page Faults Delta over
On 03/10/2013 12:27 PM, Ryan Johnson wrote:
On 03/10/2013 11:44 AM, Erik Soderquist wrote:
Installed a fresh VM with a Windows XP 64 bit ISO, sp2 already
applied. VM has 512 MB ram, and the only package I installed after
the OS was cygwin. Issue presents in this environment as soon as
Firefox
On 03/10/2013 4:55 PM, Adam Kellas wrote:
My company uses Cygwin and we experience fairly frequent fork
failures, believed to be BLODA-related. I say believed to be because
in this corporate environment, like many, we cannot uninstall the
virus scanner even long enough to see what happens
On 02/10/2013 2:50 PM, Erik Soderquist wrote:
I am currently using the X server on a Windows 7 64 bit host for
Firefox (in particular, occasional terminals too). While everything
works, I am experiencing very severe memory page faulting causing the
graphical interface to appear to hang for
On 24/09/2013 5:04 AM, Tue Henriksen wrote:
problems with sem_getvalue function
snip
On success, it should return 0, otherwise -1. However, it looks like the
function lately has been changed so it now returns the semaphore count, and
leaves '*sval' unchanged.
A patch to fix this was
On 17/09/2013 11:07 AM, Jon TURNEY wrote:
On 16/09/2013 23:02, Ryan Johnson wrote:
On 16/09/2013 2:45 PM, Jon TURNEY wrote:
On 12/09/2013 18:02, Ryan Johnson wrote:
Subject line says it all...
(I thought this came up before but either I remembered wrong or my Google-foo
is weak today
On 16/09/2013 2:45 PM, Jon TURNEY wrote:
On 12/09/2013 18:02, Ryan Johnson wrote:
Subject line says it all...
(I thought this came up before but either I remembered wrong or my Google-foo
is weak today).
These start menu links aren't installed by the xorg-server package, but by the
xinit
On 13/09/2013 11:22 AM, Aaron Schneider wrote:
What's the equivalent for cygwin 64 bits to readline in 32 bits?
Um readline?
$ uname -smo
CYGWIN_NT-6.1 x86_64 Cygwin
$ cygcheck -dc |grep readline
libreadline-devel 6.2-1
libreadline7
Hi all,
I fired up a sqlite3 shell today and was dismayed to find that readline
support is AWOL... it's been quite a while since I ran it, so I don't
know when this might have changed.
CYGWIN_NT-6.1 ryan-laptop 1.7.25(0.270/5/3) 2013-08-31 20:37 x86_64 Cygwin
cygcheck reports (among other
On 12/09/2013 11:26 AM, Frédéric Bron wrote:
Try *copying* setup64.exe to foo.exe. Or download it again but save it
with the name foo.exe.
Windows may be remembering that the file used to be called setup*.exe.
That memory might not get copied.
Doesn't work: the requested operation requires
On 12/09/2013 11:52 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Ryan Johnson sent the following at Thursday, September 12, 2013 11:31 AM
Try *copying* setup64.exe to foo.exe. Or download it again but save it
with the name foo.exe.
Windows may be remembering that the file used to be called
On 12/09/2013 2:50 PM, Warren Young wrote:
On 9/12/2013 05:47, Ryan Johnson wrote:
I fired up a sqlite3 shell today and was dismayed to find that readline
support is AWOL...
It works here, under both MinTTY and cmd.exe.
By that I mean that I ran sqlite3, typed .help at it, then Up-Arrow
Subject line says it all...
(I thought this came up before but either I remembered wrong or my
Google-foo is weak today).
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
On 12/09/2013 5:27 PM, Warren Young wrote:
On 9/12/2013 13:14, Ryan Johnson wrote:
$ ldd $(which sqlite3)
ntdll.dll = /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(0x7772)
kernel32.dll = /cygdrive/c/Windows/system32/kernel32.dll
(0x7760)
KERNELBASE.dll
On 09/09/2013 12:24 PM, Adam Kellas wrote:
Is this a bug which is fixable in Cygwin or just something to be lived with?
% gcc -o /dev/null devnull.c
% ls -ld /dev/null*
crw-rw-rw- 1 dboyce Domain Users 1, 3 Sep 9 09:14 /dev/null
-rwxrwxr-x+ 1 dboyce Domain Users 53827 Sep 9 09:14
On 04/09/2013 7:09 PM, Christopher Faylor wrote:
On Wed, Sep 04, 2013 at 03:26:10PM -0600, Warren Young wrote:
This bug could well be Wine's, rather than Cygwin's.
Wine can always play the It's not documented to work that way card but
the bottom line is still that it is not a platform that we
On 05/09/2013 8:08 AM, Earnie Boyd wrote:
On Wed, Sep 4, 2013 at 6:13 PM, Charles Wilson wrote:
On 9/4/2013 5:43 PM, Earnie Boyd wrote:
Just a note to those of you using Cygwin64 to build packages. You
will need to most likely replace the config.guess and config.sub files
in those packages
On 27/08/2013 8:06 AM, Ken Brown wrote:
On 8/27/2013 4:28 AM, Ryan Johnson wrote:
On 17/08/2013 2:41 PM, Ryan Johnson wrote:
Hi all,
The following STC causes emacs-nox to peg a CPU indefinitely. Emacs
remains responsive, but C-c C-k doesn't kill the compile; you have to
exit emacs to remove
Ping... is anyone else at least able to reproduce this?
On 17/08/2013 2:41 PM, Ryan Johnson wrote:
Hi all,
The following STC causes emacs-nox to peg a CPU indefinitely. Emacs
remains responsive, but C-c C-k doesn't kill the compile; you have to
exit emacs to remove the Compiling status
On 27/08/2013 8:06 AM, Ken Brown wrote:
On 8/27/2013 4:28 AM, Ryan Johnson wrote:
On 17/08/2013 2:41 PM, Ryan Johnson wrote:
Hi all,
The following STC causes emacs-nox to peg a CPU indefinitely. Emacs
remains responsive, but C-c C-k doesn't kill the compile; you have to
exit emacs to remove
Hi SVN maintainer,
Is a 64-bit release going to come out soon? SVN is quite a pain to build
manually, compared with most other packages, especially if support for
SSL, etc. is configured...
Thanks!
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 21/08/2013 12:11 PM, Corinna Vinschen wrote:
On Aug 21 12:04, Ryan Johnson wrote:
Hi SVN maintainer,
Is a 64-bit release going to come out soon? SVN is quite a pain to
build manually, compared with most other packages, especially if
support for SSL, etc. is configured...
Subversion is part
On 19/08/2013 5:32 AM, Corinna Vinschen wrote:
On Aug 16 16:49, Ken Brown wrote:
The problem that has been discussed at length in the thread 64-bit
emacs crashes a lot appears to have been solved on the emacs-devel
list. (I say appears to because I'm waiting for Ryan to confirm
this.) The
On 19/08/2013 6:49 AM, Ryan Johnson wrote:
On 19/08/2013 5:32 AM, Corinna Vinschen wrote:
On Aug 16 16:49, Ken Brown wrote:
The problem that has been discussed at length in the thread 64-bit
emacs crashes a lot appears to have been solved on the emacs-devel
list. (I say appears to because I'm
On 19/08/2013 7:39 AM, Corinna Vinschen wrote:
On Aug 19 07:04, Ryan Johnson wrote:
On 19/08/2013 6:49 AM, Ryan Johnson wrote:
One thing I don't understand, though: shouldn't a stack overflow
normally manifest as a seg fault when trying to access the invalid
addresses, rather than silent
On 18/08/2013 12:53 AM, Christopher Faylor wrote:
On Sat, Aug 17, 2013 at 02:41:32PM -0400, Ryan Johnson wrote:
The following STC causes emacs-nox to peg a CPU indefinitely. Emacs
remains responsive, but C-c C-k doesn't kill the compile; you have to
exit emacs to remove the Compiling status
Hi all,
The following STC causes emacs-nox to peg a CPU indefinitely. Emacs
remains responsive, but C-c C-k doesn't kill the compile; you have to
exit emacs to remove the Compiling status. Killing the buffer or
starting a new compile offers to kill the offending process, but doesn't.
On 16/08/2013 12:34 AM, Ryan Johnson wrote:
On 15/08/2013 10:35 PM, Ken Brown wrote:
On 8/15/2013 4:55 PM, Ryan Johnson wrote:
At this point I'm pretty confident it's memory corruption of some kind.
Consider the following semi-STC:
1. Invoke: emacs-nox -Q; echo -e att $(jobs -p)\nc
/dev
On 16/08/2013 5:13 AM, Eli Zaretskii wrote:
Date: Fri, 16 Aug 2013 01:59:41 -0400
From: Ryan Johnson **snip**
Please don't feed the spammers. I get enough as it is...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation
On 16/08/2013 4:49 PM, Ken Brown wrote:
The problem that has been discussed at length in the thread 64-bit
emacs crashes a lot appears to have been solved on the emacs-devel
list. (I say appears to because I'm waiting for Ryan to confirm this.)
WJFFM so far (fingers crossed!)
The problem
On 14/08/2013 10:04 AM, Ryan Johnson wrote:
On 10/08/2013 2:01 PM, Ken Brown wrote:
I'm not sure that garbage collection is the underlying problem here.
Agree it's probably not GC... GC would just tend to trip over any bad
pointers that were lurking around...
After a rash of crashes where I
On 15/08/2013 1:10 PM, Eli Zaretskii wrote:
Date: Thu, 15 Aug 2013 12:58:02 -0400
From: Ken Brown kbr...@cornell.edu
CC: Eli Zaretskii e...@gnu.org
Eli is the expert on bidi.c (he wrote it). He can probably tell you
whether you've really bumped into an emacs bug here.
There's nothing wrong
On 15/08/2013 5:14 PM, Ken Brown wrote:
On 8/15/2013 4:55 PM, Ryan Johnson wrote:
Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at
/usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
You're not using the latest gcc, which is 4.8.1-3. Any chance that
that's your
On 15/08/2013 5:58 PM, Ken Brown wrote:
On 8/15/2013 5:24 PM, Ryan Johnson wrote:
On 15/08/2013 5:14 PM, Ken Brown wrote:
On 8/15/2013 4:55 PM, Ryan Johnson wrote:
Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at
/usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S
On 15/08/2013 6:02 PM, Ken Brown wrote:
On 8/15/2013 5:58 PM, Ken Brown wrote:
On 8/15/2013 5:24 PM, Ryan Johnson wrote:
On 15/08/2013 5:14 PM, Ken Brown wrote:
On 8/15/2013 4:55 PM, Ryan Johnson wrote:
Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at
/usr/src/debug
On 15/08/2013 6:48 PM, Ryan Johnson wrote:
On 15/08/2013 6:02 PM, Ken Brown wrote:
On 8/15/2013 5:58 PM, Ken Brown wrote:
On 8/15/2013 5:24 PM, Ryan Johnson wrote:
On 15/08/2013 5:14 PM, Ken Brown wrote:
On 8/15/2013 4:55 PM, Ryan Johnson wrote:
Program received signal SIGSEGV, Segmentation
On 15/08/2013 7:07 PM, Ken Brown wrote:
On 8/15/2013 6:48 PM, Ryan Johnson wrote:
On 15/08/2013 6:02 PM, Ken Brown wrote:
On 8/15/2013 5:58 PM, Ken Brown wrote:
On 8/15/2013 5:24 PM, Ryan Johnson wrote:
On 15/08/2013 5:14 PM, Ken Brown wrote:
On 8/15/2013 4:55 PM, Ryan Johnson wrote
On 15/08/2013 7:40 PM, Ken Brown wrote:
On 8/15/2013 7:14 PM, Ryan Johnson wrote:
On 15/08/2013 6:48 PM, Ryan Johnson wrote:
On 15/08/2013 6:02 PM, Ken Brown wrote:
On 8/15/2013 5:58 PM, Ken Brown wrote:
On 8/15/2013 5:24 PM, Ryan Johnson wrote:
On 15/08/2013 5:14 PM, Ken Brown wrote:
On 8
On 15/08/2013 10:35 PM, Ken Brown wrote:
On 8/15/2013 4:55 PM, Ryan Johnson wrote:
At this point I'm pretty confident it's memory corruption of some kind.
Consider the following semi-STC:
1. Invoke: emacs-nox -Q; echo -e att $(jobs -p)\nc
/dev/clipboard; fg
2. ^Z
3. (switch to window running
On 14/08/2013 7:59 AM, Corinna Vinschen wrote:
On Aug 14 13:33, Corinna Vinschen wrote:
On Aug 14 12:53, Corinna Vinschen wrote:
On Aug 14 06:28, Ken Brown wrote:
On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
On Aug 14 10:10, Corinna Vinschen wrote:
On Aug 13 18:00, Ken Brown wrote:
On
On 10/08/2013 2:01 PM, Ken Brown wrote:
On 8/10/2013 11:24 AM, Ryan Johnson wrote:
On 10/08/2013 9:59 AM, Ken Brown wrote:
On 8/9/2013 11:28 PM, Ryan Johnson wrote:
On 08/08/2013 2:00 PM, Ryan Johnson wrote:
On 08/08/2013 1:42 PM, Ken Brown wrote:
On 8/5/2013 11:29 AM, Ryan Johnson wrote
On 14/08/2013 10:04 AM, Ryan Johnson wrote:
After a rash of crashes where I either forgot to attach gdb or forgot
to set appropriate breakpoints, I finally managed to catch the stack
trace below. It occurred during M-x compile, while emacs parsed the
compilation's rather copious output, which
On 10/08/2013 9:59 AM, Ken Brown wrote:
On 8/9/2013 11:28 PM, Ryan Johnson wrote:
On 08/08/2013 2:00 PM, Ryan Johnson wrote:
On 08/08/2013 1:42 PM, Ken Brown wrote:
On 8/5/2013 11:29 AM, Ryan Johnson wrote:
On 05/08/2013 11:00 AM, Ken Brown wrote:
On 8/3/2013 3:05 PM, Ryan Johnson wrote
On 08/08/2013 2:00 PM, Ryan Johnson wrote:
On 08/08/2013 1:42 PM, Ken Brown wrote:
On 8/5/2013 11:29 AM, Ryan Johnson wrote:
On 05/08/2013 11:00 AM, Ken Brown wrote:
On 8/3/2013 3:05 PM, Ryan Johnson wrote:
On 02/08/2013 8:07 AM, Ryan Johnson wrote:
On 02/08/2013 7:04 AM, Ken Brown wrote
Hi all,
(no, that's not a typo in the subject line)
64-bit install, bash inside mintty, all latest packages with the
cygwin1.dll snapshot shown below...
# --- begin STC ---
$ uname -a
CYGWIN_NT-6.1 ryan-laptop-v02 1.7.23s(0.268/5/3) 20130729 19:11:42
x86_64 Cygwin
$ echo Reading
On 08/08/2013 11:48 AM, Corinna Vinschen wrote:
On Aug 8 17:32, Corinna Vinschen wrote:
On Aug 8 09:48, Ryan Johnson wrote:
Hi all,
(no, that's not a typo in the subject line)
64-bit install, bash inside mintty, all latest packages with the
cygwin1.dll snapshot shown below...
# --- begin
On 08/08/2013 1:42 PM, Ken Brown wrote:
On 8/5/2013 11:29 AM, Ryan Johnson wrote:
On 05/08/2013 11:00 AM, Ken Brown wrote:
On 8/3/2013 3:05 PM, Ryan Johnson wrote:
On 02/08/2013 8:07 AM, Ryan Johnson wrote:
On 02/08/2013 7:04 AM, Ken Brown wrote:
On 8/2/2013 4:02 AM, Corinna Vinschen wrote
On 05/08/2013 11:00 AM, Ken Brown wrote:
On 8/3/2013 3:05 PM, Ryan Johnson wrote:
On 02/08/2013 8:07 AM, Ryan Johnson wrote:
On 02/08/2013 7:04 AM, Ken Brown wrote:
On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
On Aug 1 22:46, Ryan Johnson wrote:
Here's a new one... I started a compilation
On 02/08/2013 8:07 AM, Ryan Johnson wrote:
On 02/08/2013 7:04 AM, Ken Brown wrote:
On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
On Aug 1 22:46, Ryan Johnson wrote:
Here's a new one... I started a compilation, but before it actually
invoked the command it started pegging the CPU. After ^G^G^G
On 02/08/2013 7:04 AM, Ken Brown wrote:
On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
On Aug 1 22:46, Ryan Johnson wrote:
On 26/07/2013 11:32 PM, Ryan Johnson wrote:
On 26/07/2013 10:50 PM, Ken Brown wrote:
On 7/26/2013 8:32 PM, Ryan Johnson wrote:
Hi all,
Running 64-bit cygwin 1.7.22
On 26/07/2013 11:32 PM, Ryan Johnson wrote:
On 26/07/2013 10:50 PM, Ken Brown wrote:
On 7/26/2013 8:32 PM, Ryan Johnson wrote:
Hi all,
Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
mintty 1.2-beta1-1, I keep getting seg faults and Fatal error 6:
Aborted
It happens
On 29/07/2013 3:27 PM, Ryan Johnson wrote:
On 29/07/2013 3:13 PM, Ryan Johnson wrote:
On 29/07/2013 3:11 PM, Corinna Vinschen wrote:
On Jul 29 12:01, Ryan Johnson wrote:
On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem
http://cygwin.com/acronyms/#TOFU
On 29/07/2013 8:15 AM, Ariel Burbaickij wrote:
OK, thank, you, so usual suspects. Now, removing, antivirus and stuff
will not be possible in this particular environment but adjustments in
the configuration are well possible, provided I will be able to prove
to
On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed
to reduce the issue down to an fgets call when reading a pipe.
The following code causes the issue for me if I try and debug it:
#include
On 29/07/2013 3:11 PM, Corinna Vinschen wrote:
On Jul 29 12:01, Ryan Johnson wrote:
On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed
to reduce the issue down to an fgets call when reading
On 29/07/2013 3:13 PM, Ryan Johnson wrote:
On 29/07/2013 3:11 PM, Corinna Vinschen wrote:
On Jul 29 12:01, Ryan Johnson wrote:
On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed
to reduce
On 27/07/2013 6:30 AM, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed to
reduce the issue down to an fgets call when reading a pipe.
The following code causes the issue for me if I try and debug it:
STC snipped
That STC let me get a stack trace of gdb:
Hi all,
Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
mintty 1.2-beta1-1, I keep getting seg faults and Fatal error 6: Aborted
The most recent stackdump was:
Stack trace:
FrameFunctionArgs
021F960 0018006F893 (001008C3C40, 4FFF,
Hi all,
The latest 64-bit gdb/cygwin combo chokes whenever a process it has
attached to is backgrounded (and also if it blocks on I/O, I think). To
repro with the attached STC:
1. gcc -g bug.c ./a
prints its PID
2. gdb -p PID
3. Continue gdb
4. ^Z the STC
5. STC freezes, gdb gets confused.
On 26/07/2013 10:50 PM, Ken Brown wrote:
On 7/26/2013 8:32 PM, Ryan Johnson wrote:
Hi all,
Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
mintty 1.2-beta1-1, I keep getting seg faults and Fatal error 6:
Aborted
It happens at strange times, invariably during I/O
... right now, `gcc -m32' compiles code just fine, but linking fails
miserably.
Granted, it would be pretty slick to have support for 32-bit cygwin64
apps (!= normal 32-bit cygwin apps), but that was not on the table last
I heard.
Thoughts?
Ryan
--
Problem reports:
Hi all,
I tried to install 64-bit cygwin today, but I keep encountering the
error message setup-x86_64.exe is not a valid Win32 application. I
found another message that said to clear IE's file cache and try again,
but that didn't help. Plus, downloading the executable with the wget
from
On 07/22/2013 03:27 PM, Christopher Faylor wrote:
On Tue, Jul 23, 2013 at 03:10:51PM -0400, Ryan Johnson wrote:
I tried to install 64-bit cygwin today, but I keep encountering the
error message setup-x86_64.exe is not a valid Win32 application.
Sorry about that. This problem is fixed.
Works
Hi mercurial manager,
Is an official 64-bit mercurial coming soon? Meanwhile, is there any
reason I shouldn't expect a wget/configure/make cycle to just work ?
Thanks!
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
Hi all,
If I select the gcc-4.8.1-1 package from setup-64, it downloads and
installs the gcc-4.8.1-src package, which AFAICT includes a tarball of
the gcc sources, a patch, and a cygport file:
$ for f in $(find /usr -name '*gcc*'); do echo $f: $(cygcheck -f $f); done
On 07/22/2013 05:38 PM, Yaakov (Cygwin/X) wrote:
On 2013-07-23 16:26, Ryan Johnson wrote:
If I select the gcc-4.8.1-1 package from setup-64, it downloads and
installs the gcc-4.8.1-src package
gcc is only a source-only meta-package; you want to install gcc-core,
gcc-g++, etc.
Oh, that's
On 04/07/2013 8:47 AM, Václav Zeman wrote:
Hi.
The C++ part of Clang package (I have not tested the C part) is broken
after update of GCC to 4.7.3. It cannot find standard C++ headers:
snip
ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++
ignoring nonexistent
On 02/07/2013 6:26 AM, JonY wrote:
Version 4.7.3-1 of gcc has been uploaded. Some important notes are:
* gcc-3.x is now finally removed, replaced by this version.
* This means -mno-cygwin support is also removed completely, use the
provided cross compilers to build Windows code.
* Previous
On 02/07/2013 10:50 AM, JonY wrote:
On 7/2/2013 20:00, Ryan Johnson wrote:
On 02/07/2013 6:26 AM, JonY wrote:
Version 4.7.3-1 of gcc has been uploaded. Some important notes are:
* gcc-3.x is now finally removed, replaced by this version.
* This means -mno-cygwin support is also removed
On 27/06/2013 5:35 AM, Arjen Markus wrote:
Hello,
the bug I am reporting here on behalf of Alan Irwin surfaced in the
combination wine and Cygwin (Alan summarised it here:
http://www.winehq.org/pipermail/wine-devel/2013-June/100328.html). It
has to do with the way Cygwin handles forks.
The bug
On 30/05/2013 2:37 AM, Noel Grandin wrote:
On 2013-05-29 23:23, Ryan Johnson wrote:
GNU gdb (GDB) 7.6.50.20130408-cvs (cygwin-special)
... snip...
Reading symbols from /home/Ryan/experiments/a.exe...done.
(gdb) catch throw
Catchpoint 1 (throw)
That was a mistake in the documentation
Hi all,
Compiling the following with the cygwin g++-4.5.3:
int global;
int main() {
if (global)
throw global;
return 0;
}
Crashes gdb if a catchpoint is set:
GNU gdb (GDB) 7.6.50.20130408-cvs (cygwin-special)
... snip...
Reading symbols from
On 17/05/2013 11:22 AM, Corinna Vinschen wrote:
On May 17 10:56, Christopher Faylor wrote:
On Fri, May 17, 2013 at 12:26:55PM +0200, Corinna Vinschen wrote:
On May 17 12:56, Fedin Pavel wrote:
Hello!
The reason for this behaviour has been outlined a couple of times on
this list. See
On 17/05/2013 5:28 PM, Earnie Boyd wrote:
On Fri, May 17, 2013 at 2:09 PM, Christopher Faylor wrote:
So it sounds like we may have a feline inavailability deadlock.
Is that ENOFEL or EFLOCK?
I think it's ENOPURR .
ROFLMAO.
Maybe ENOMEW would be better.
ENOFUR.
--
Problem reports:
On 14/05/2013 10:04 AM, Josef Wolf wrote:
I am trying to compile gcc on cygwin under 64bit win7
To configure gcc, I use the following command:
/var/tmp/builds/crossgcc/src/gcc-4.7.2/configure \
--prefix=/usr/local/crossgcc \
--with-gmp=/usr/x86_64-pc-cygwin/sys-root/usr \
On 08/05/2013 2:36 PM, Christopher Faylor wrote:
On Tue, May 07, 2013 at 04:22:23PM -0400, Ryan Johnson wrote:
Hi all,
Running the attached STC inside gdb hangs (zero CPU util, have to kill
gdb from Task Manager, killing a.exe doesn't cut it).
Compile line used: g++ -Wall -g -mthreads -DBUG
Hi all,
Running the attached STC inside gdb hangs (zero CPU util, have to kill
gdb from Task Manager, killing a.exe doesn't cut it).
Compile line used: g++ -Wall -g -mthreads -DBUG bug.cpp
I currently have the following package versions:
cygwin-1.7.18(0.263/5/3) 2013-04-19
mintty-1.1.3-1
On 03/05/2013 11:48 AM, Christopher Faylor wrote:
On Fri, May 03, 2013 at 09:44:19AM +0200, Csaba Raduly wrote:
Hi Piotr,
On Fri, May 3, 2013 at 8:25 AM, Piotr Cieplak wrote:
Could anyone help me with this problem?
I posted this couple of days ago, but so far there is no response.
When
On 03/05/2013 2:28 PM, Alan Thompson wrote:
P.S. I have had to run rebaseall each time I do an install or
upgrade over the past year.not sure why as this never used to be a
problem.
That's very strange, because setup.exe started running rebaseall
automatically just over a year ago [1].
On 26/04/2013 1:50 AM, Achim Gratz wrote:
Ryan Johnson ryan.johnson at cs.utoronto.ca writes:
warning: the debug information found in /usr/bin/cygwin1.dbg does
not match /usr/bin/cygwin1.dll (CRC mismatch).
If /usr/bin/cygwin1.dbg exists, it is from a former snapshot installation.
You should
On 24/04/2013 8:50 AM, Corinna Vinschen wrote:
On Apr 24 08:03, Ryan Johnson wrote:
Hi all,
I'm trying to port a linux program that uses mmap to implement a
growable array; the ideas is to mmap(PROT_NONE, MAP_NORESERVE) a
chunk of address space (corresponding to the maximum array size
Hi all,
I pulled down the latest cygwin dll and debuginfo packages today:
CYGWIN_NT-6.1-WOW64 ryan-cms-utsc 1.7.18(0.263/5/3) 2013-04-19 10:39
i686 Cygwin
... and now gdb complains:
warning: the debug information found in /usr/bin/cygwin1.dbg does
not match /usr/bin/cygwin1.dll (CRC
Hi all,
I'm trying to port a linux program that uses mmap to implement a
growable array; the ideas is to mmap(PROT_NONE, MAP_NORESERVE) a chunk
of address space (corresponding to the maximum array size) and then call
mmap(PROT_READ|PROT_WRITE, MAP_FIXED) to allocate actual memory in the
1 - 100 of 455 matches
Mail list logo
