On Tue, Apr 27, 2021 at 3:14 PM Takashi Yano
wrote:
> On Tue, 27 Apr 2021 09:58:01 -0400
> "William M. \(Mike\) Miller via Cygwin" wrote:
> > I refreshed my Cygwin installation over the weekend, and ever since I
> have
> > not been able to run gdb under emacs as I
n cygwin or in mintty. Maybe this is something that
> Thomas Wolff (mintty author) or Takashi Yano (pseudo-console support
> expert) would want to look at.
>
That seems like useful information. However, my experience is a bit
different; I get the popup regardless of whether the CY
> > Thanks for your reply; unfortunately, yes, it does. I had refreshed
> > the installation fairly recently, and running the installer only updated
> a
> > few things, not cygwin.dll and not gcc; my installation is the same as
> > yours. I've tried it with three diffe
On Sat, Nov 14, 2020 at 10:26 AM Lemures Lemniscati via Cygwin <
cygwin@cygwin.com> wrote:
> On Sat, 14 Nov 2020 09:12:11 -0500, William M. (Mike) Miller
> > On Sat, Nov 14, 2020 at 12:39 AM Lemures Lemniscati via Cygwin <
> > cygwin@cygwin.com> wrote:
> >
> &g
C) 10.2.0
> > CYGWIN_NT-10.0 XXX 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> > mintty 3.4.1 (x86_64-pc-cygwin)
> >
> > - André Bleau
>
> It works fine for me.
> Can you check 'gcc -M assert.cpp' ?
> My result is:
>
> $ gcc -M assert.cpp
> as
, it does. I had refreshed
the installation fairly recently, and running the installer only updated a
few things, not cygwin.dll and not gcc; my installation is the same as
yours. I've tried it with three different shells (tcsh, bash, mksh) and
with both gcc and clang, and all have the sa
as desired with no dialog box.
Is there an environment setting or compiler command-line option I can give
to suppress the dialog box and always just write a message to stderr and
abort? Thanks for any insights.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
t didn't appear to work.
>
> I've verified that setting the CYGWIN variable globally to "disable_pcon"
> has resolved the problem.
>
This is what I did as well to address the problem of M-x gdb not working in
emacs in a new Cygwin installation. I don't know what I
On Thu, Mar 5, 2020 at 5:40 AM Takashi Yano
wrote:
> On Wed, 4 Mar 2020 10:39:11 -0500
> "William M. (Mike) Miller" wrote:
> > On Wed, Mar 4, 2020 at 9:58 AM Ken Brown wrote:
> >
> > > On 3/4/2020 9:44 AM, William M. (Mike) Miller wrote:
> > > >
On Wed, Mar 4, 2020 at 9:58 AM Ken Brown wrote:
> On 3/4/2020 9:44 AM, William M. (Mike) Miller wrote:
> > I installed Cygwin on a new computer last weekend. On my previous
> computer,
> > I used gud with gdb in emacs (M-x gdb) for debugging. However, on the new
> > compu
to the right of the
last character of the previous line instead of beginning in column 0, as it
did on the old computer.
Any suggestions for how to diagnose or fix the problem would be most
appreciated.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
Problem
On Wed, Oct 19, 2016 at 12:54 PM, Corinna Vinschen
wrote:
> On Oct 19 12:46, Rockefeller, Harry wrote:
>> >-Original Message-
>> >From: cygwin-ow...@cygwin.com [mailto:cygwin->ow...@cygwin.com] On Behalf
>> >Of William M. (Mike) Miller
>> >
1-1 but not gdb-7.10.1-1.
>>(I tested on x86_64, since gdb-7.10.1-1 is broken on x86.)
>>It also fails with M-x gdb instead of M-x gud-gdb, but with a different error
>>message:
>>Failed to resume program execution (ContinueDebugEvent failed, error 87)
>>Ken
>
&
elcome to have a fully-working gud again.
Just one update on that original report: item #3 has been fixed by
recent versions of gdb and is no longer a problem.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
Problem reports: http://cygwin.com/problem
'*' category, reduces
the time for ls in one of my (local) large directories from over one
second to 0.04 seconds.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cyg
On Thu, Jan 14, 2016 at 6:33 PM, Jon Turney wrote:
> On 14/01/2016 15:53, William M. (Mike) Miller wrote:
>>
>> On Thu, Jan 14, 2016 at 10:11 AM, Jon Turney
>> wrote:
>>>
>>>
>>> The following package has been updated in the Cygwin distribution:
the fix that was discussed here a few months
ago for gdb arbitrarily starting extra threads, preventing stepping,
continuing, etc.? (See the discussion containing
https://cygwin.com/ml/cygwin/2015-06/msg00321.html for context.)
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@g
lem on Cygwin. (I already
> verified that the native MinGW debugging is fixed by that patch.)
Any estimate on when a gdb release containing this patch might make it
to Cygwin? It's not in the most recent version in setup (7.9.1-1).
--
William M. (Mike) Miller | Edison Design Group
lem on Cygwin. (I already
> verified that the native MinGW debugging is fixed by that patch.)
Any prognosis for if/when a version of gdb containing this patch might
make it to Cygwin?
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
Problem reports: http://cyg
On Sun, Jun 21, 2015 at 3:29 PM, Ken Brown wrote:
> On 6/20/2015 4:51 PM, William M. (Mike) Miller wrote:
>>
>> On Sat, Jun 20, 2015 at 4:42 PM, Ken Brown wrote:
>>>
>>> On 6/20/2015 4:02 PM, William M. (Mike) Miller wrote:
>>>>
>>>>
&g
On Sat, Jun 20, 2015 at 4:42 PM, Ken Brown wrote:
> On 6/20/2015 4:02 PM, William M. (Mike) Miller wrote:
>>
>> Thanks for the reply. My concern, however, isn't that new threads are
>> being created; it's that when gdb does this, it sets the state of all
>>
On Sat, Jun 20, 2015 at 2:47 PM, Corinna Vinschen
wrote:
> On Jun 20 09:29, William M. (Mike) Miller wrote:
>> I have a single-threaded executable that has a number of debug-print
>> routines that can be called interactively in the debugger to display
>> data structures to s
735ad1f in ntdll!RtlInitializeExceptionChain () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#7 0x7735acea in ntdll!RtlInitializeExceptionChain () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#8 0x in ?? ()
Any ideas on what I can do to avoid this annoying behavior or to
regain control of my debugging session af
On Thu, Jun 18, 2015 at 10:29 AM, Ken Brown wrote:
> On 6/18/2015 8:09 AM, William M. (Mike) Miller wrote:
>>
>> On Thu, Jun 18, 2015 at 7:53 AM, Jon TURNEY
>> wrote:
>>>
>>> On 17/06/2015 15:53, William M. (Mike) Miller wrote:
>>>>
>>
On Thu, Jun 18, 2015 at 7:53 AM, Jon TURNEY wrote:
> On 17/06/2015 15:53, William M. (Mike) Miller wrote:
>>
>> I'm having numerous problems recently running gdb inside emacs (both
>> -w32 and -X11):
>
> [...]
>>
>> All of these things used to wor
ion for quite a
while. My current installation has gdb 7.9.1-1 and emacs 24.5-1.
Any thoughts on what the problem might be and how to fix it would be
appreciated.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
Problem reports: http://cygwin.com/problems.htm
On Thu, Dec 12, 2013 at 5:20 PM, Ken Brown wrote:
> On 12/12/2013 3:42 PM, William M. (Mike) Miller wrote:
>>
>> On Thu, Dec 12, 2013 at 2:54 PM, Christopher Faylor wrote:
>>>
>>> On Thu, Dec 12, 2013 at 02:45:27PM -0500, Ken Brown wrote:
>>>>
>>
QasYpFDUHeWGdsQ0RlWkk5Wm8/edit?usp=sharing
I was watching this in Task Manager; the emacs-X11 process got up to
around 400+ MB before dying with a segfault.
BTW, I am beginning to think that the link with Windows Update is a
red herring; I uninstalled all the updates from this morning, one by
on
On Thu, Dec 12, 2013 at 11:29 AM, Ken Brown wrote:
> On 12/12/2013 11:17 AM, William M. (Mike) Miller wrote:
>>
>> On Thu, Dec 12, 2013 at 11:04 AM, Ken Brown wrote:
>>>
>>> On 12/12/2013 10:13 AM, William M. (Mike) Miller wrote:
>>>>
>>>>
On Thu, Dec 12, 2013 at 11:04 AM, Ken Brown wrote:
> On 12/12/2013 10:13 AM, William M. (Mike) Miller wrote:
>>
>> I'm running Windows 8.1 (cygcheck.out attached) and did a Windows
>> update this morning. Since then I cannot run emacs-X11. Sometimes
>> the me
On 5/11/05, Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Wed, May 11, 2005 at 07:01:07AM -0400, William M. (Mike) Miller wrote:
> >The order of destruction of static objects should be the inverse of
> >their order of construction, regardless of whether they are global or
i); }
};
A a(1);
void f() {
static A a(3);
}
main () {
static A a(2);
printf("main\n");
f();
exit(0);
}
This now prints
A::A(1)
A::A(2)
main
A::A(3)
A::~A for 1
A::~A for 3
A::~A for 2
"A::~A for 1&quo
A::A(2)
main
A::A(3)
A::~A for 1
A::~A for 3
A::~A for 2
The destructors should print 3, 2, 1 instead of 1, 3, 2.
--
William M. (Mike) Miller
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://
On 5/10/05, Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Tue, May 10, 2005 at 03:27:02PM -0400, William M. (Mike) Miller wrote:
> >On 5/10/05, Christopher Faylor <[EMAIL PROTECTED]> wrote:
> >> Previous to 1.5.16, static destructors were always called via a
>
tic
destructors. According to cygcheck, I now have cygwin 1.5.15-1
installed, but I still don't see the static destructor output. Is there
something else I need to revert while waiting for the fix?
Thanks again.
--
William M. (Mike) Miller
[EMAIL PROTECTED]
--
Unsubscribe info: http
On 5/10/05, Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Tue, May 10, 2005 at 11:54:45AM -0400, William M. (Mike) Miller wrote:
> >Yes, the output does appear when I call exit instead of returning
> >from main(). Unfortunately, that's not an option. For one thi
On 5/10/05, Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Tue, May 10, 2005 at 09:06:36AM -0400, William M. (Mike) Miller wrote:
> >I'm still left with the problem of figuring out what changed to cause
> >this result. Until I ran the "setup" application
2.1.6-1
libxml2 2.6.16-2
libxslt 1.1.12-2
login1.9-7
m4 1.4.3-1
make 3.80-1
man 1.5p-1
mingw-runtime3.7-1
minires 1.00-1
mktemp 1.5-3
more 2.11o-1
ncu
On 5/9/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> Original Message
> >From: William M. (Mike) Miller
> > The output "In dtor." is missing.
>
> That's because stdout is already closed by the time your dtor runs. I
> stepped right into it, it d
0040822-1
gcc-mingw-g7720040822-1
gcc-mingw-java 20040822-1
mingw-runtime3.7-1
Anyone have any idea how I managed to do this to myself and,
more importantly, how I can undo it?
Thanks!
--
William M. (Mike) Miller
[EMAIL PROTECTED]
--
Unsubscribe info: htt
William M. (Mike) Miller wrote:
The definitions of isfinite() (and fpclassify(), on which isfinite()
depends) from math.h are as follows:
#define fpclassify(x) \
(__extension__ ({__typeof__(x) __x = (x); \
(sizeof (__x) == sizeof (float)) ?
__fpclassifyf
Christopher Faylor wrote:
On Wed, Feb 02, 2005 at 03:56:43PM -0500, William M. (Mike) Miller wrote:
There was a thread about this problem a few months ago
(http://sources.redhat.com/ml/cygwin/2004-08/msg00128.html). The
OP at that time was referred to the newlib mailing list, but I
can't
on my Linux system uses three functions -- __finitef(),
__finite(), and __finitel() -- for implementing isfinite(), while
the Cygwin math.h only uses __fpclassifyf() and __fpclassifyd(),
omitting a version for long double. This could give false
positives for infinities if the long double value overflo
43 matches
Mail list logo
