At the end of this message is a short program. It is linked as a
windows-mode executable so when it is launched it does not have a console.
It then allocates one and uses it. The expected behaviour is that when I
run it a fresh DOS-style console appears and I can type a few chars in and
they ge
The package no longer contains the "insight" graphical
debugger. Time permitting, there will be a separate package introduced
for insight.
I try to write my code so that it never has bugs - and certainly never the
sort that need gdb. However when I have problems I find insight very much
my fav
ss outrege - merely distress! I guess my best emergency response to
this has to be to comment out places in my build where I support the
version of cygwin I am not running under.
Arthur Norman
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cyg
On a 32-bit cygwin I get
$ uname -a
CYGWIN_NT-6.1-WOW64 panamint 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin
$ find /usr -name Xlib.h -print
/usr/include/X11/Xlib.h
/usr/x86_64-pc-cygwin/sys-root/usr/include/X11/Xlib.h
/usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/Tk/pTk/Xlib.h
and
Thanks. I am building the code from reduce-algebra.sourceforge.net and in
particular updating the build system there so that anybody who fetches
will be able to build. The part that I am mostly concerned with uses
either the FOX toolkit for its GUI stuff or wxWidgets (each built from
source) so
I have a trivial C++ program, which was tested using
g++ -g hello.cpp -o hello
cgdb ./hello
break main
run
What gets displayed at that stage looks like the following where some of
the long strings of escaped have been wrapped. There are funny characters
marking "Line 5" which is whe
The attached code tried two loops each of which just calls a function that
increments an integer variable. One loop is a simple variable, the other
has the thread_local qualifier. I put in ugly annotations to prevent g++
from inlining the functions even though I compile with -O3, but in real
ca
#! /bin/bash
# When I run this on Ubuntu-x86_64, Macintosh(clang) or a Raspberry pi
# the code links and when it runs it just prints 999 - which is the behaviour
# that I expect. On both Cygwin and using x86_64-w64-mingw32-g++ (and i686)
# I get a linker diagnostic of the form
# ./tltest.sh
# /us
You appear to be running into a conflict with Cygwin managing Windows TLS, as
Cygwin does its own messing around to support Unix/Linux/POSIX/g++ semantics for
TLS and everything else under Windows. You should either use the supplied API,
or write a Windows program that allows you to control TLS wi
I notice that you are not independently compiling your source files and have no
include guard in t.h.
Could I suggest that you add the include guard to t.h and retest.
If you still have an issue, try independently compiling your source files, then
linking them as a separate step, to see if that wo
OTOH: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697#c20
Thank you again. On looking harder on gcc bugzilla I found a related case
from mid 2017 that had not been looked at yet, so I have tried adding my
report to that. And meanwhile in my own code I am using work-arounds!
The prompt r
I
can now make my scripts use this final recipe and so I can make progress
again, but this feels pretty odd and somewhat unsatisfactory... and maybe
some others will get caught by it?
So so far as I am conncerned now I have a fix this is no longer urgent,
but it is perhaps best reported.
I expect a crawling speed when running Cygwin in a ARM x86_64
emulation mode
When I tried that a while ago on a macbook air m1 I was actually quite
impressed. I ran windows-10-for-arm within UTM on the Mac. This was back
in August and at that time ar least I had some misery with networking in
I have been VERY happily pleased about how well Cygwin runs using
Prism on Windows/ARM64. I can build and test my x86_64 code there using it
despite the underlying CPU being an ARM. My genuine Windows/x86_64 machine
is not that new these days. Using a stack Macbook-m1/UTM/Windows11-ARM64
runs t
This running on Windows 10 1909 and cygwin has been updated to the latest
version. The effect was also visible on a freshly installed minimal cygwin
put on an almost fresh Windows 10 VM.
Cygwin these days seems to have a behaviour that confuses me regarding the
case of a disk name:
ln -s "/
I can't use virtualbx because what I need is to emulate
the aarch64 architecture, I don't want to use binaries compiled by
others, one of the reasons is that those binaries don't include sd-card
emulation support...
This is perhaps an off-topic response as regards compiling things on
cygwin, but
René Berber wrote
At one time it was recommended to disable a Cygwin feature, something
like this:
alias cgdb="env CYGWIN=disable_pcon cgdb"
Not sure if this is still necesary.
Thank you for the reminder about that. I had forgotten - however ion my
main Windows machine I have the CYGWIN variab
Thank you very much. Great service. And indeed I use the word "gcd" more
often that "gdb" and so that was a typo. Arthur
On Wed, 14 Apr 2021, Takashi Yano wrote:
On Tue, 13 Apr 2021 15:05:56 +0100 (GMT Summer Time)
Arthur Norman wrote:
With the latest cygwin if I go &q
18 matches
Mail list logo
