Re: BUG: bash_completion package consistently omitting critical file

2021-01-08 Thread Marco Atzeri via Cygwin

please reply to the mailing list

On 08.01.2021 09:04, matthew patton wrote:

What is the output of :     cygcheck -c bash-completion


well that's friggin' annoying. It came up blank.

So I went back to the installer and it's not selected. And yet every 
time I install Cygwin I select it and I always end up with a partial 
(broken) install that's missing that file as well as 'helpers/' but have 
a bunch of other supporting directories and a reasonably populated 
'completions/'.


look on /var/log/setup.log.full for hints



now I get '2.7-1'. Is there a package conflict during a fresh install?

I guess I need to do another clean install to see if I can duplicate.



Regards
Marco
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: problem using gcc-core for compile qemu

2021-01-08 Thread Arthur Norman via Cygwin

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 some while back I found a range of sets of instructions for 
setting up aarch64 emulation in qemu. When I had any issues running on 
Windows I just used virtualbox to give myself an x86_64 Linux world and 
installed qemu there. And after a while I could buy a Raspberry pi with a 
64-bit cpu and use that, so these days working with aarch64 (and an SD 
card) works best for me on an rpi4 not via emulation. But to find people 
who have worked on adapting and setting up qemu to support aarch64 with an 
SD card you might find it useful to follow the footsteps of those who were 
working towards rpi 64-bit support?
And I like and use cygwin for most of what I do, but when something I want 
to do is better supported by Linux then setting up an Ubuntu via 
virtualbox uses some disc space but does not add much overhead on my 
main W10 machine and lets me build, test and debug there because 
following a path that is already well trodden is often easiest!

Arthur

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


gdb doesn't print the output on the terminal

2021-01-08 Thread Gaetano Buldo via Cygwin
Hello,
I installed Cygwin for 64bit window, and the following tools in order to
build and debug c programs using eclipse.
gcc 9.3.0-2
make 4.3-1
gdb 9.2-1
It seems like the gdb program doesn't print on the terminal.
When i run gdb --version a get an empty string on the terminal
When i run gdb, i can see the programm running on the task manager, and i
can quit it writing 'q' (even if the string doesn't appear on the terminal).
gcc and make works fine. When i check the version i normally get the
expected output, and i'm also capable to build a C project.
Any suggestion?
Thanks,
Gaetano
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: gdb doesn't print the output on the terminal

2021-01-08 Thread Marco Atzeri via Cygwin

On 08.01.2021 10:20, Gaetano Buldo via Cygwin wrote:

Hello,
I installed Cygwin for 64bit window, and the following tools in order to
build and debug c programs using eclipse.
gcc 9.3.0-2


why not the version 10 ?


make 4.3-1
gdb 9.2-1
It seems like the gdb program doesn't print on the terminal.


this usually means you are missing some libraries or you have an 
incorrect version of oune of them


These commands can help to identify the issue

$ cygcheck /usr/bin/gdb

$ strace -o /tmp/gdb.strace /usr/bin/gdb --version



When i run gdb --version a get an empty string on the terminal
When i run gdb, i can see the programm running on the task manager, and i
can quit it writing 'q' (even if the string doesn't appear on the terminal).
gcc and make works fine. When i check the version i normally get the
expected output, and i'm also capable to build a C project.
Any suggestion?
Thanks,
Gaetano
--


see also here

Problem reports:  https://cygwin.com/problems.html


and provide the cygcheck.out as attachment

Regards
Marco

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] Updated: GraphicsMagick-1.3.36-1

2021-01-08 Thread Marco Atzeri via Cygwin-announce via Cygwin

Version 1.3.36-1 of
   GraphicsMagick
   libGraphicsMagick-devel
   libGraphicsMagick3
   libGraphicsMagick++12
   libGraphicsMagickWand2
   perl-Graphics-Magick

have been uploaded for cygwin

CHANGES
Upstream security and bug fixes release
http://www.graphicsmagick.org/NEWS.html#december-26-2020

DESCRIPTION
GraphicsMagick is the swiss army knife of image processing.
It provides a robust and efficient collection of tools and
libraries which support reading, writing, and manipulating an
image in over 88 major formats including important formats like
DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, and TIFF.

HOMEPAGE
http://www.graphicsmagick.org/

Regards

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Limitation of setenv for tcsh: Too many arguments

2021-01-08 Thread KAVALAGIOS Panagiotis (EEAS-EXT)
Dear all,

There is a limitation for tcsh (setenv: Too many arguments) to set the PATH 
environmental variable as you can see in the attached file with the steps to 
reproduce it. It probably looks like tcsh limitation and not Cygwin. The "set 
path=( ${HOME}/bin $path)" is not complaining and sets the path, but it also 
interprets the space in the paths as a separator. The only Cygwin related issue 
is probably the /usr/bin that it is added twice. Any workarounds?

Panos

Application Architect
CONSULIAT (under contract with the EEAS)
BA.BS.3.IS
Office: EEAS B100 Floor 5 Area 048
Rue Belliard 100, 1000 Brussels
Phone: +32 2 584 6017

kavalpa@BELBRU-L1903777 ~
$ echo $PATH
/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/Program 
Files/Java/jdk/bin:/cygdrive/c/Program Files/Npm:/cygdrive/c/Program Files 
(x86)/Common 
Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program
 Files (x86)/Webex/Webex/Applications:/cygdrive/c/Program Files/Oracle/Instant 
Client:/cygdrive/c/Program Files/PuTTY:/cygdrive/c/Program 
Files/Apache/apache-ant/bin:/cygdrive/c/Program 
Files/Apache/apache-maven/bin:/cygdrive/c/Program 
Files/Apache/apache-httpd/bin:/cygdrive/c/Program Files (x86)/Bitvise SSH 
Client:/cygdrive/c/Program Files/MySQL/MySQL Server/bin:/cygdrive/c/Program 
Files/Node.js:/cygdrive/c/Program Files (x86)/SAP 
BusinessObjects/sqlanywhere/BIN64:/cygdrive/c/Program Files (x86)/SAP 
BusinessObjects/sqlanywhere/BIN32:/cygdrive/c/Program 
Files/Sysinternals:/cygdrive/c/Program 
Files/DIGIT/WLST-API/bin:/cygdrive/c/Program Files (x86)/Oracle/Instant 
Client:/cygdrive/c/Program Files/Oracle/TNSPing:/cygdrive/c/Program 
Files/ZeroTurnaround/JRebel/bin:/cygdrive/c/DEV/PHP/php:/cygdrive/c/Program 
Files/PHP/composer/bin:/usr/bin:/cygdrive/c/Users/kavalpa/AppData/Local/Microsoft/WindowsApps

kavalpa@BELBRU-L1903777 ~
$ tcsh
kavalpa@BELBRU-L1903777:[19] ~ > echo $PATH
/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/Program 
Files/Java/jdk/bin:/cygdrive/c/Program Files/Npm:/cygdrive/c/Program Files 
(x86)/Common 
Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program
 Files (x86)/Webex/Webex/Applications:/cygdrive/c/Program Files/Oracle/Instant 
Client:/cygdrive/c/Program Files/PuTTY:/cygdrive/c/Program 
Files/Apache/apache-ant/bin:/cygdrive/c/Program 
Files/Apache/apache-maven/bin:/cygdrive/c/Program 
Files/Apache/apache-httpd/bin:/cygdrive/c/Program Files (x86)/Bitvise SSH 
Client:/cygdrive/c/Program Files/MySQL/MySQL Server/bin:/cygdrive/c/Program 
Files/Node.js:/cygdrive/c/Program Files (x86)/SAP 
BusinessObjects/sqlanywhere/BIN64:/cygdrive/c/Program Files (x86)/SAP 
BusinessObjects/sqlanywhere/BIN32:/cygdrive/c/Program 
Files/Sysinternals:/cygdrive/c/Program 
Files/DIGIT/WLST-API/bin:/cygdrive/c/Program Files (x86)/Oracle/Instant 
Client:/cygdrive/c/Program Files/Oracle/TNSPing:/cygdrive/c/Program 
Files/ZeroTurnaround/JRebel/bin:/cygdrive/c/DEV/PHP/php:/cygdrive/c/Program 
Files/PHP/composer/bin:/usr/bin:/cygdrive/c/Users/kavalpa/AppData/Local/Microsoft/WindowsApps
kavalpa@BELBRU-L1903777:[20] ~ > setenv PATH ${HOME}/bin:${PATH}
setenv: Too many arguments.
kavalpa@BELBRU-L1903777:[21] ~ > exit
exit

kavalpa@BELBRU-L1903777 ~
$ export PATH=${HOME}/bin:${PATH}

kavalpa@BELBRU-L1903777 ~
$ echo $PATH
/home/kavalpa/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Program 
Files/Git/cmd:/cygdrive/c/Program Files/Java/jdk/bin:/cygdrive/c/Program 
Files/Npm:/cygdrive/c/Program Files (x86)/Common 
Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program
 Files (x86)/Webex/Webex/Applications:/cygdrive/c/Program Files/Oracle/Instant 
Client:/cygdrive/c/Program Files/PuTTY:/cygdrive/c/Program 
Files/Apache/apache-ant/bin:/cygdrive/c/Program 
Files/Apache/apache-maven/bin:/cygdrive/c/Program 
Files/Apache/apache-httpd/bin:/cygdrive/c/Program Files (x86)/Bitvise SSH 
Client:/cygdrive/c/Program Files/MySQL/MySQL Server/bin:/cygdrive/c/Program 
Files/Node.js:/cygdrive/c/Program Files (x86)/SAP 
BusinessObjects/sqlanywhere/BIN64:/cygdrive/c/Program Files (x86)/SAP 
BusinessObjects/sqlanywhere/BIN32:/cygdrive/c/Program 
Files/Sysinternals:/cygdrive/c/Program 
Files/DIGIT/WLST-API/bin:/cygdrive/c/Program Files (x86)/Oracle/Instant 
Client:/cygdrive/c/Program Files/Oracle/TNSPing:/cygdrive/c/Program 
Files/ZeroTurnaround/JRebel/bin:/cygdrive/c/DEV/PHP/php:/cygdrive/c/Program 
Files/PHP/composer/bin:/usr/bin:/cygdrive/c/Users/kavalpa/AppData/Local/Microsoft/WindowsApps

kavalpa@BELBRU-L1903777 ~
$ tcsh
kavalpa@BELBRU-L19037

Re: misterious GIT failure

2021-01-08 Thread Adam Dinwoodie
On Friday 08 January 2021 at 02:13 am +, matthew patton via Cygwin wrote:
> I've been using cygwin since like 20 years ago and do everything in
> it. A couple days ago my Git program mysteriously stopped working. I
> can see (GIT_TRACE=1) it invoke SSH and HTTPS connections just fine
> but it fails with a short-read/write when it's time for pack or
> unpack. Baffled I uninstalled Cygwin and blew away the Repo and
> started over. Git worked fine for a few hours and then BAM same
> problem. I've tried all three versions of git available in the repos.
> Short of deleting Cygwin entirely and starting over, nothing brings it
> back.
> 
> I use Github, Bitbucket, and CodeCommit (amazon) for various
> repositories and once Git stops working it won't work on any of them.
> (I briefly thought maybe there was some badly behaved backends)
> 
> Here's an example output. Anyone have a notion as to what the dickens is 
> going on?
> 
> 21:04:24.233957 git.c:444               trace: built-in: git fetch
> 21:04:24.238648 run-command.c:664       trace: run_command: unset GIT_PREFIX; 
> GIT_PROTOCOL=version=2 ssh -o SendEnv=GIT_PROTOCOL g...@github.com 
> 'git-upload-pack '\''tb3088/shell-environment.git'\'''
> remote: Enumerating objects: 34, done.
> remote: Counting objects: 100% (34/34), done.
> remote: Compressing objects: 100% (25/25), done.
> 21:04:25.119943 run-command.c:664       trace: run_command: git index-pack 
> --stdin -v --fix-thin '--keep=fetch-pack 1011 on SOHO-GP4D633' 
> --pack_header=2,1635
> fatal: index-pack failed

This looks like some sort of problem writing to disk to me.  Where are
you storing your Git repositories?  Is it on a regular NTFS disk, or a
file share, or something more esorteric?  And does that drive have
plenty of free space?

Can you please provide the cygcheck output per
https://cygwin.com/problems.html?

If neither of these points at an obvious problem, I expect the next step
will be either (a) looking at Cygwin strace output to get a more
detailed view of what's happening when things go wrong, or (b) having
you build and run the full Git test suite with a view to using that to
narrow down what steps are going wrong.

Adam
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: Limitation of setenv for tcsh: Too many arguments

2021-01-08 Thread ASSI
KAVALAGIOS Panagiotis (EEAS-EXT) writes:
> There is a limitation for tcsh (setenv: Too many arguments) to set the
> PATH environmental variable as you can see in the attached file with
> the steps to reproduce it. It probably looks like tcsh limitation and
> not Cygwin. The "set path=( ${HOME}/bin $path)" is not complaining and
> sets the path, but it also interprets the space in the paths as a
> separator. The only Cygwin related issue is probably the /usr/bin that
> it is added twice. Any workarounds?

Both problems are a failure on your part to quote the arguments
correctly.  Consult the documentation for the respective shell to find
enlightenment.

As an aside, it is highly unlikely that you'd actually want to set up
your PATH like that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


RE: Limitation of setenv for tcsh: Too many arguments

2021-01-08 Thread KAVALAGIOS Panagiotis (EEAS-EXT)
> -Original Message-
> From: Cygwin  On Behalf Of ASSI
> Sent: 08 January 2021 11:39
> 
> KAVALAGIOS Panagiotis (EEAS-EXT) writes:
> > There is a limitation for tcsh (setenv: Too many arguments) to set the
> > PATH environmental variable as you can see in the attached file with
> > the steps to reproduce it. It probably looks like tcsh limitation and
> > not Cygwin. The "set path=( ${HOME}/bin $path)" is not complaining and
> > sets the path, but it also interprets the space in the paths as a
> > separator. The only Cygwin related issue is probably the /usr/bin that
> > it is added twice. Any workarounds?
> 
> Both problems are a failure on your part to quote the arguments correctly.
> Consult the documentation for the respective shell to find enlightenment.

Indeed, I forgot the double quotes. That works:

setenv PATH "${HOME}/bin:${PATH}"

I confused the message like a length limitation and not for the number of input 
arguments.

Why do you say both? I don't add /usr/bin anywhere.

> As an aside, it is highly unlikely that you'd actually want to set up your 
> PATH
> like that.

Care to explain? How else can I add in the path custom personal commands?

Panos

Application Architect
CONSULIAT (under contract with the EEAS)
BA.BS.3.IS
Office: EEAS B100 Floor 5 Area 048
Rue Belliard 100, 1000 Brussels
Phone: +32 2 584 6017

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: gdb doesn't print the output on the terminal

2021-01-08 Thread Marco Atzeri via Cygwin

On 08.01.2021 12:46, Gaetano Buldo wrote:

Hi Marco,
i attach the files.
I a first moment I installed the last versions of all the tools, after 
that i tried install other version.

That's why my current version of gcc is 9.3.0-2.
I removed  some sensitive info, i putted .
Thanks,
Gaetano



the strace shows a normal exit.

What terminal are you using ?
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: problem using gcc-core for compile qemu

2021-01-08 Thread Eliot Moss

On 1/8/2021 3:42 AM, Arthur Norman via Cygwin wrote:
>> 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 some while back I
> found a range of sets of instructions for setting up aarch64 emulation in 
qemu. When I had any
> issues running on Windows I just used virtualbox to give myself an x86_64 
Linux world and installed
> qemu there. And after a while I could buy a Raspberry pi with a 64-bit cpu 
and use that, so these
> days working with aarch64 (and an SD card) works best for me on an rpi4 not 
via emulation. But to
> find people who have worked on adapting and setting up qemu to support 
aarch64 with an SD card you
> might find it useful to follow the footsteps of those who were working 
towards rpi 64-bit support?
> And I like and use cygwin for most of what I do, but when something I want to 
do is better supported
> by Linux then setting up an Ubuntu via virtualbox uses some disc space but 
does not add much
> overhead on my main W10 machine and lets me build, test and debug there 
because following a path
> that is already well trodden is often easiest!
> Arthur

I want to second some of that.  My research regularly involves development for
ARM targets (more commonly 32 bit, but also 64).  I happen to use VirtualBox
and there cross-compile from x86 to ARM.  This works for building even a whole
OS from scratch.  After that I am using gem5, not qemu, but the principle
would be the same.  I also spent less than $100 to set myself up with a
Raspberry Pi and SD card.  (I still need gem5 because I am emulating some
additional hardware that does not physically exist (yet, anyway).)

If you need to cross-compile to an ARM target, you could download the Cygwin
gcc package source and build the cross compiler to aarch 64, along with the
other cross tools from bin utils (I am thinking of nm, objdump, etc.).  Then
you can build binaries for ARM using Cygwin, if you like.  I am not aware of
already existing Cygwin packages for ARM targets, but somebody may have built
them.

One advantage of VirtualBox is that Ubuntu packages fo cross compiling to ARM
already exist so I just install and run them.

Best wishes - Eliot Moss
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: problem using gcc-core for compile qemu

2021-01-08 Thread Marco Atzeri via Cygwin

On 08.01.2021 14:06, Eliot Moss wrote:

On 1/8/2021 3:42 AM, Arthur Norman via Cygwin wrote:
 >> 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 




I want to second some of that.

One advantage of VirtualBox is that Ubuntu packages fo cross compiling 
to ARM

already exist so I just install and run them.




building a cross compiler in Cygwin is extremely time consuming.
Better use the Virtual box

Regards
Marco

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: Limitation of setenv for tcsh: Too many arguments

2021-01-08 Thread Eliot Moss

On 1/8/2021 5:13 AM, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
> Dear all,
>
> There is a limitation for tcsh (setenv: Too many arguments) to set the PATH environmental 
variable as you can see in the attached file with the steps to reproduce it. It probably looks like 
tcsh limitation and not Cygwin. The "set path=( ${HOME}/bin $path)" is not complaining and sets the 
path, but it also interprets the space in the paths as a separator. The only Cygwin related issue is 
probably the /usr/bin that it is added twice. Any workarounds?


I saw another response, but will add that I typically do something more like:

set PATH="${HOME}/bin:${PATH}"

THat takes care of quoting.  However, you want to avoid duplicate entries.
Something like this helps with that:

[ -z "${PATH##*${HOME}/bin:*}" ] || {
  PATH="${HOME}/bin:${PATH}"
}

I suppose it is slightly dangerous in that it would also match
/foo/${HOME}/bin, but ${HOME} is absolute and such a match seems unlikely.
Still, you could do:

[ -z "${PATH##${HOME}/bin:*}" ]

to check if it is first on the path, and

[ -z "${PATH##*:${HOME}/bin:*}" ]

to see if it is in the middle, and

[ -z "${PATH##*:${HOME}/bin}" ]

to see if it as at the end.  This leads to:

[ -z "${PATH##${HOME}/bin:*}" ] || [ -z "${PATH##*:${HOME}/bin:*}" ] || [ -z 
"${PATH##*:${HOME}/bin}" ] || {

  PATH="${HOME}/bin:$PATH}"
}

Because of the three first/middle/end possibilities, this is what comes to
mind.  _Maybe_ you could get a more elegant solution using bash arrays, but
this is not that long as a piece of bash code.

Regards - Eliot Moss
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


FW: NoMa: Service 311-ntp on host trastratumts1.musgravegroup.net is UNKNOWN

2021-01-08 Thread Bourke, Richard (SCM)



-Original Message-
From: g...@gwkmon.musgravegroup.net 
Sent: Friday 8 January 2021 14:04
To: SCM Team 
Subject: NoMa: Service 311-ntp on host trastratumts1.musgravegroup.net is 
UNKNOWN

* NoMa *

ID: 146297
Notification Type: PROBLEM
Service: 311-ntp
Host: trastratumts1.musgravegroup.net
Host Alias: trastratumts1.musgravegroup.net
State: UNKNOWN
Address: TRASTRATUMTS1.musgravegroup.net
Link: 
https://gwkmon.musgravegroup.net/portal-statusviewer/urlmap?host=trastratumts1.musgravegroup.net&service=311-ntp
Info: 3 [main] check_ntp_time 48656 find_fast_cwd: WARNING: Couldnt compute 
FAST_CWD pointer.  Please report this problem to/the public mailing list 
cygwin@cygwin.com/  24258 [main] check_ntp_time 48656 exception::handle: 
Exception: STATUS_ACCESS_VIOLATION/  30586 [main] check_ntp_time 48656 
open_stackdumpfile: Dumping stack trace to check_ntp_time.exe.stackdump


Date/Time: Fri Jan  8 14:04:05 2021
This e-mail and any attachment transmitted with it is confidential and is 
intended solely for the person or entity to whom it is addressed. The 
unauthorized use, disclosure, copying or alteration of this message is strictly 
forbidden. If you are not an intended recipient of this email, you must not 
use, disclose, copy, distribute or retain this message or any part of it. If 
you have received this email in error, please notify me immediately and delete 
all copies of this email from your computer system(s). Any views expressed in 
this e-mail are those of the individual sender and do not necessarily reflect 
the views of Musgrave Group. Please note that Musgrave Group reserves the right 
to monitor e-mail communications which are sent through or hosted on its 
networks at all times. www.musgrave.ie The holding company of the Musgrave 
Group is Musgrave Group plc Registered in Ireland No 105820. Registered office: 
Ballycurreen, Airport Road, Cork
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: FW: NoMa: Service 311-ntp on host trastratumts1.musgravegroup.net is UNKNOWN

2021-01-08 Thread cygwinautoreply--- via Cygwin



>-Original Message-
>From: g...@gwkmon.musgravegroup.net 
>Sent: Friday 8 January 2021 14:04
>To: SCM Team 
>Subject: NoMa: Service 311-ntp on host trastratumts1.musgravegroup.net is 
>UNKNOWN

>* NoMa *

>ID: 146297
>Notification Type: PROBLEM
>Service: 311-ntp
>Host: trastratumts1.musgravegroup.net
>Host Alias: trastratumts1.musgravegroup.net
>State: UNKNOWN
>Address: TRASTRATUMTS1.musgravegroup.net
>Link: 
>https://gwkmon.musgravegroup.net/portal-statusviewer/urlmap?host=trastratumts1.musgravegroup.net&service=311-ntp
>Info: 3 [main] check_ntp_time 48656 find_fast_cwd: WARNING: Couldnt compute 
>FAST_CWD pointer.  Please report this problem to/the public mailing list 
>cygwin@cygwin.com/  24258 [main] check_ntp_time 48656 exception::handle: 
>Exception: STATUS_ACCESS_VIOLATION/  30586 [main] check_ntp_time 48656 
>open_stackdumpfile: Dumping stack trace to check_ntp_time.exe.stackdump


>Date/Time: Fri Jan  8 14:04:05 2021
>This e-mail and any attachment transmitted with it is confidential and is 
>intended solely for the person or entity to whom it is addressed. The 
>unauthorized use, disclosure, copying or alteration of this message is 
>strictly forbidden. If you are not an intended recipient of this email, you 
>must not use, disclose, copy, distribute or retain this message or any part of 
>it. If you have received this email in error, please notify me immediately and 
>delete all copies of this email from your computer system(s). Any views 
>expressed in this e-mail are those of the individual sender and do not 
>necessarily reflect the views of Musgrave Group. Please note that Musgrave 
>Group reserves the right to monitor e-mail communications which are sent 
>through or hosted on its networks at all times. www.musgrave.ie The holding 
>company of the Musgrave Group is Musgrave Group plc Registered in Ireland No 
>105820. Registered office: Ballycurreen, Airport Road, Cork

https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: gdb doesn't print the output on the terminal

2021-01-08 Thread Gaetano Buldo via Cygwin
I used cygwin64 terminal (C:\cygwin64\bin\mintty.exe) to generate these
files.
I tried gdb on both  cygwin64 terminal and window command prompt.
I don't get any output on both of them

Il giorno ven 8 gen 2021 alle ore 14:04 Marco Atzeri 
ha scritto:

> On 08.01.2021 12:46, Gaetano Buldo wrote:
> > Hi Marco,
> > i attach the files.
> > I a first moment I installed the last versions of all the tools, after
> > that i tried install other version.
> > That's why my current version of gcc is 9.3.0-2.
> > I removed  some sensitive info, i putted .
> > Thanks,
> > Gaetano
> >
>
> the strace shows a normal exit.
>
> What terminal are you using ?
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] [ANNOUNCEMENT] Stable: wxWidgets3.0 3.0.5.1-1

2021-01-08 Thread Hamish McIntyre-Bhatty via Cygwin-announce via Cygwin
Version 3.0.5.1-1 of "wxWidgets3.0" has been marked as stable.

wxWidgets3.0 is a cross-platform GUI toolkit for GTK written in C++.

This update provides the following packages:

- wxWidgets3.0 (source package).

- wxWidgets3.0-debuginfo

- wxWidgets3.0-doc

- libwx_baseu3.0_0

- libwx_baseu3.0-devel

- libwx_gtk2u3.0_0

- libwx_gtk2u3.0-devel

- libwx_gtk2u3.0-doc (obsolete)

- libwx_gtk3u3.0_0

- libwx_gtk3u3.0-devel

This update brings a newer, less buggy version of wxWidgets 3.0, and the
following changes have been made since the last version:

- Updated to wxWidgets 3.0.5.1 from 3.0.4.

- Added build dependencies.

- Evaluated lots of new patches (over 80), and found that nearly none of
them were needed (already patched in new source), so we only have a few
new patches.

- Updated the wxGTK collision patch for wxwidgets 3.0.5.1 as the old one
wouldn't apply.

- Use pushd and popd instead of cd in the cygport file.

- Enable automated unit tests in the cygport file (these currently do
work so I tested manually).

- Enable and test wxwebview with webkit (works fine in all configurations).

- Split BUILD_REQUIRES across two lines for definitely build time and
probably only runtime deps.

- Use system regex library explicitly.

- Removed obsolete --without-gnomeprint option.

- Use gnomevfs (old bug no longer seems to apply).

The git repository at
https://cygwin.org/git-cygwin-packages/?p=git/cygwin-packages/wxWidgets3.0.git;a=summary
has also been updated.

Cheers,

Hamish


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

https://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
















--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] [ANNOUNCEMENT] Stable: python3-wx-4.0.7.post2-4

2021-01-08 Thread Hamish McIntyre-Bhatty via Cygwin-announce via Cygwin
Version 4.0.7.post2-4 of "python3-wx" has been marked as stable.

python3-wx is the Python 3 version of the cross-platform GUI toolkit,
wxPython.

This is the fourth revision, and it provides the following packages:

python3-wx (the source package)

python3-wx-common (common files)

python3-wx-debuginfo

python36-wx (wxPython built for Python 3.6)

python37-wx (wxPython built for Python 3.7)

python38-wx (wxPython built for Python 3.8).

This update is a rebuild against wxWidgets3.0-3.0.5.1, as several things
such as webview are now enabled, and new patches have been used.

The git repository at
https://cygwin.org/git-cygwin-packages/?p=git/cygwin-packages/python3-wx.git;a=summary
has also been updated.

There are quite a lot of changes here, and I have had to test manually,
so I would very much like feedback if anyone finds any problems with
these packages.

Cheers,
Hamish

   *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

https://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
















--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] [ANNOUNCEMENT] Stable: python-wx-3.0.2.0-6

2021-01-08 Thread Hamish McIntyre-Bhatty via Cygwin-announce via Cygwin
Version 3.0.2.0-6 of "python-wx" has been marked as stable.

python-wx is the Python 2 version of the cross-platform GUI toolkit,
wxPython.

This is the sixth revision, and it provides the following packages:

python-wx (the source package)

python2-wx (obsolete)

python2-wxversion

python2-wx3.0

python2-wx-debuginfo

python2-wx-devel

python2-wx-tools

python-wxversion

This update is a rebuild against wxWidgets3.0-3.0.5.1, as several things
such as webview are now enabled, and new patches have been used.

The git repository at
https://cygwin.org/git-cygwin-packages/?p=git/cygwin-packages/python-wx.git;a=summary
has also been updated.

There are quite a lot of changes here, and I have had to test manually,
so I would very much like feedback if anyone finds any problems with
these packages.

Cheers,
Hamish

   *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

https://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.


















--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: misterious GIT failure

2021-01-08 Thread Achim Gratz
matthew patton via Cygwin writes:
> I've been using cygwin since like 20 years ago and do everything in
> it. A couple days ago my Git program mysteriously stopped working. I
> can see (GIT_TRACE=1) it invoke SSH and HTTPS connections just fine
> but it fails with a short-read/write when it's time for pack or
> unpack. Baffled I uninstalled Cygwin and blew away the Repo and
> started over. Git worked fine for a few hours and then BAM same
> problem.

That seems to indicate some sort of behavioral based firewalling or IDS
rather than a problem in Cygwin.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: Limitation of setenv for tcsh: Too many arguments

2021-01-08 Thread Achim Gratz
KAVALAGIOS Panagiotis (EEAS-EXT) writes:
> Why do you say both? I don't add /usr/bin anywhere.

Your other example with the $path csh variable doesn't quote $path,
which you must do with the quote modifier rather than actual quotes, so
$path:q because it is an wordlist var.  Also see the -f / -l option for
the set builtin of tcsh if you want to strip out duplicates and take
note of some subtle differences in the default quoting between tcsh and
csh if you are trying to be portable.

>> As an aside, it is highly unlikely that you'd actually want to set up your 
>> PATH
>> like that.
>
> Care to explain? How else can I add in the path custom personal commands?

I just don't think it's a good idea to have all that stuff in PATH,
especially since PATH in Windows determines library search order and
there is a high propensity for libraries with the same name getting
reachable via PATH for your example.  I tend to stay within Cygwin as
much as possible and have wrapper scripts setting up the environment for
all other commands.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: Limitation of setenv for tcsh: Too many arguments

2021-01-08 Thread Brian Inglis via Cygwin

On 2021-01-08 06:21, Eliot Moss wrote:

On 1/8/2021 5:13 AM, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
 > Dear all,
 >
 > There is a limitation for tcsh (setenv: Too many arguments) to set the PATH 
environmental variable as you can see in the attached file with the steps to 
reproduce it. It probably looks like tcsh limitation and not Cygwin. The "set 
path=( ${HOME}/bin $path)" is not complaining and sets the path, but it also 
interprets the space in the paths as a separator. The only Cygwin related issue 
is probably the /usr/bin that it is added twice. Any workarounds?


I saw another response, but will add that I typically do something more like:

set PATH="${HOME}/bin:${PATH}"

THat takes care of quoting.  However, you want to avoid duplicate entries.
Something like this helps with that:

[ -z "${PATH##*${HOME}/bin:*}" ] || {
   PATH="${HOME}/bin:${PATH}"
}

I suppose it is slightly dangerous in that it would also match
/foo/${HOME}/bin, but ${HOME} is absolute and such a match seems unlikely.
Still, you could do:

[ -z "${PATH##${HOME}/bin:*}" ]

to check if it is first on the path, and

[ -z "${PATH##*:${HOME}/bin:*}" ]

to see if it is in the middle, and

[ -z "${PATH##*:${HOME}/bin}" ]

to see if it as at the end.  This leads to:

[ -z "${PATH##${HOME}/bin:*}" ] || [ -z "${PATH##*:${HOME}/bin:*}" ] || [ -z 
"${PATH##*:${HOME}/bin}" ] || {

   PATH="${HOME}/bin:$PATH}"
}

Because of the three first/middle/end possibilities, this is what comes to
mind.  _Maybe_ you could get a more elegant solution using bash arrays, but
this is not that long as a piece of bash code.


Please consider the subject line - he is using tcsh in which path is an array - 
Achim followed up with hints on handling the issues under that shell! ;^>


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: problem using gcc-core for compile qemu

2021-01-08 Thread juan carlos rebate rodriguez via Cygwin
El vie, 08-01-2021 a las 08:42 +, Arthur Norman escribió:
> > 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 some while back I found a range of sets of instructions
> for 
> setting up aarch64 emulation in qemu. When I had any issues running
> on 
> Windows I just used virtualbox to give myself an x86_64 Linux world
> and 
> installed qemu there. And after a while I could buy a Raspberry pi
> with a 
> 64-bit cpu and use that, so these days working with aarch64 (and an
> SD 
> card) works best for me on an rpi4 not via emulation. But to find
> people 
> who have worked on adapting and setting up qemu to support aarch64
> with an 
> SD card you might find it useful to follow the footsteps of those who
> were 
> working towards rpi 64-bit support?
> And I like and use cygwin for most of what I do, but when something I
> want 
> to do is better supported by Linux then setting up an Ubuntu via 
> virtualbox uses some disc space but does not add much overhead on my 
> main W10 machine and lets me build, test and debug there because 
> following a path that is already well trodden is often easiest!
> Arthur
> 

I think I expressed myself incorrectly or I am not able to be
understood, no matter what package I choose. gcc-core does not compile
using the cygwin dll, the one that compiles for that library is cygwin-
gcc.
now I will try to explain my case better,
1 when I use the gcc-core package if it is able to detect the whole
set, the only thing that happens is that the script does not recognize
cygwin nt as a valid operating system.
2 when I use the mingw64-x86_64-gcc package it is not able to compile
without add-ons.
for example when I compile with gcc-core if it is able to detect the
libcaca-devel library, this is the library that qemu asks me for sd-
card support,
However, when I use the package mingw64-x86_64-gcc it is not able to
find it in the system because it is not in its set, for this it is
mandatory to use the gcc-core package (not cygwin-gcc), I do not want
to use linux, I want to keep him as far away from my team as possible,
just because I work for him doesn't mean I want him

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: problem using gcc-core for compile qemu

2021-01-08 Thread Lee via Cygwin
On 1/8/21, juan carlos rebate rodriguez via Cygwin  wrote:
>
> I think I expressed myself incorrectly or I am not able to be
> understood, no matter what package I choose. gcc-core does not compile
> using the cygwin dll, the one that compiles for that library is cygwin-
> gcc.
> now I will try to explain my case better,
> 1 when I use the gcc-core package if it is able to detect the whole
> set, the only thing that happens is that the script does not recognize
> cygwin nt as a valid operating system.
> 2 when I use the mingw64-x86_64-gcc package it is not able to compile
> without add-ons.
> for example when I compile with gcc-core if it is able to detect the
> libcaca-devel library, this is the library that qemu asks me for sd-
> card support,
> However, when I use the package mingw64-x86_64-gcc it is not able to
> find it in the system because it is not in its set,

If you use the mingw cross compiler you'll also need some cross compiler tools.
Take a look at
  https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libcaca&arch=x86_64

You probably need to install
mingw64-x86_64-libcaca-0.99.beta19-1 - mingw64-x86_64-libcaca: Color
ASCII art library for Win64 toolchain

Regards,
Lee
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: problem using gcc-core for compile qemu

2021-01-08 Thread Brian Inglis

On 2021-01-08 13:54, juan carlos rebate rodriguez via Cygwin wrote:

El vie, 08-01-2021 a las 08:42 +, Arthur Norman escribió:
I can't use virtualbox 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 some while back I found a range of sets of instructions for 
setting up aarch64 emulation in qemu. When I had any issues running on 
Windows I just used virtualbox to give myself an x86_64 Linux world and 
installed qemu there. And after a while I could buy a Raspberry pi with a 
64-bit cpu and use that, so these days working with aarch64 (and an SD 
card) works best for me on an rpi4 not via emulation. But to find people 
who have worked on adapting and setting up qemu to support aarch64 with an 
SD card you might find it useful to follow the footsteps of those who were 
working towards rpi 64-bit support?
And I like and use cygwin for most of what I do, but when something I want 
to do is better supported by Linux then setting up an Ubuntu via virtualbox

uses some disc space but does not add much overhead on my main W10 machine
and lets me build, test and debug there because following a path that is
already well trodden is often easiest!



I think I expressed myself incorrectly or I am not able to be
understood, no matter what package I choose. gcc-core does not compile
using the cygwin dll, the one that compiles for that library is cygwin-
gcc.


Packages gcc-core/g++ are the Cygwin native compilers for the architecture you 
are running the compiler on and uses the Cygwin native DLL.
Packages cygwin32/64-gcc-core/g++ are the Cygwin cross-compilers for the 
architecture you are not running the compiler on and uses the Cygwin DLL for the 
other architecture.
Packages mingw64-i686/x86_64-gcc-core/g++ are the Cygwin cross-compilers for 
each of the Windows architecture runtimes and use only 
mingw64-i686/x86_64-lib... libraries and Windows native DLLs including msvcrt.dll.



now I will try to explain my case better,
1 when I use the gcc-core package if it is able to detect the whole
set, the only thing that happens is that the script does not recognize
cygwin nt as a valid operating system.
2 when I use the mingw64-x86_64-gcc package it is not able to compile
without add-ons.


Most complex packages have dependencies on (many) libraries: Cygwin supports 402 
mingw64 development library packages for each architecture, which are used to 
build its own Windows native utilities such as setup-x86/_64, cygcheck, 
cygwin-console-helper, ldh, strace, and the cygwin1.dll itself, which do not 
depend on any Cygwin DLLs e.g.


$ cygcheck `cygpath -m /setup`
C:\...\setup-x86_64.exe
  C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
  C:\Windows\system32\ntdll.dll
  C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\SECHOST.dll
  C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\COMCTL32.dll
C:\Windows\system32\GDI32.dll
  C:\Windows\system32\win32u.dll
C:\Windows\system32\USER32.dll
  C:\Windows\system32\ole32.dll
C:\Windows\system32\combase.dll
  C:\Windows\system32\bcryptPrimitives.dll
  C:\Windows\system32\PSAPI.DLL
  C:\Windows\system32\SHELL32.dll
  C:\Windows\system32\SHLWAPI.dll
  C:\Windows\system32\WININET.dll
  C:\Windows\system32\WS2_32.dll
$ cygcheck cygcheck
Found: C:\...\cygwin64\bin\cygcheck.exe
C:\...\cygwin64\bin\cygcheck.exe
  C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
  C:\Windows\system32\ntdll.dll
  C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\SECHOST.dll
  C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\PSAPI.DLL
  C:\Windows\system32\USER32.dll
C:\Windows\system32\win32u.dll
C:\Windows\system32\GDI32.dll
  C:\Windows\system32\WININET.dll


for example when I compile with gcc-core if it is able to detect the
libcaca-devel library, this is the library that qemu asks me for sd-
card support,


I don't think that is the required library for that function:

$ cygcheck -p libcaca-devel
Found 3 matches for libcaca-devel
libcaca-devel-0.99beta19-?: Color ASCII art library (C development) (installed 
binaries and support files)

...

SD card support requires a hardware device driver and typically a filesystem 
driver in the OS e.g. for FAT, NTFS, CD/DVD, or as utilities for foreign 
filesystems e.g. /usr/sbin/mke2fs, resize2fs, tune2fs, dumpe2fs, e2freefrag, 
e2image, e2fsck, etc. in packages e2fsprogs and e2fsimage.


Cygwin lib...-devel packages are for Cygwin native development with the Cygwin 
native libraries, toolchain, and utilities.



However, when I use the package mingw64-x86_64-gcc it is not able to
find it in the system because it is not in its set, for this it is
mand

error running linker

2021-01-08 Thread Richard Morgan via Cygwin

Hi,

While running an ant build cc task (cpptasks: Compile tasks for Apache 
Ant - cc (sourceforge.net) 
), when 
it reached the Link step I received the following output:


Starting Link

    1 [main] 5672 find_fast_cwd: WARNING: Couldn’t compute 
FAST_CWD pointer.  Please report this problem to the public mailing list 
cygwin@cygwin.com 


    link: extra operand ‘/DLL’

I don’t know if the extra operand is the problem, I don’t supply it, it 
is likely generated by the “outtype=’shared’” parameter of the cc task, 
so I don’t have an easy means to experiment with changing that since I 
need a shared library to be generated.


If you need any other info let me know.

Regards,

Rick Morgan
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: error running linker

2021-01-08 Thread cygwinautoreply--- via Cygwin
>Hi,

>While running an ant build cc task (cpptasks: Compile tasks for Apache 
>Ant - cc (sourceforge.net) 
>), when 
>it reached the Link step I received the following output:

>Starting Link

>                 1 [main] 5672 find_fast_cwd: WARNING: 
> Couldn’t compute 
>FAST_CWD pointer.  Please report this problem to the public mailing list 
>cygwin@cygwin.com 

>                 link: extra operand ‘/DLL’

>I don’t know if the extra operand is the problem, I don’t supply it, it 
>is likely generated by the “outtype=’shared’” parameter of the cc 
>task, 
>so I don’t have an easy means to experiment with changing that since I 
>need a shared library to be generated.

>If you need any other info let me know.

>Regards,

>Rick Morgan

https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: error running linker

2021-01-08 Thread Tres Finocchiaro via Cygwin
If this command is getting its parameter from a previous command, make
sure to sanitize the stderr that comes from Cygwin.  Normally, this
isn't a problem, but ant specifically included stderr and stdout
together when parsing a command.

https://github.com/java-native-access/jna/commit/2714a017c9fada761e3d175d1e03f1d3bccaa14f

This above example is using ant's "apply", but any ant executed output
can suffer from this problem where stderr is mixed with stdout.  It's
not a cygwin bug, but rather a nuance with ant that surfaces with
Cygwin.

- tres.finocchi...@gmail.com

On Fri, Jan 8, 2021 at 5:50 PM cygwinautoreply--- via Cygwin
 wrote:
>
> >Hi,
>
> >While running an ant build cc task (cpptasks: Compile tasks for Apache
> >Ant - cc (sourceforge.net)
> >), when
> >it reached the Link step I received the following output:
>
> >Starting Link
>
> > 1 [main] 5672 find_fast_cwd: WARNING: Couldn’t compute
> >FAST_CWD pointer.  Please report this problem to the public mailing list
> >cygwin@cygwin.com 
>
> > link: extra operand ‘/DLL’
>
> >I don’t know if the extra operand is the problem, I don’t supply it, it
> >is likely generated by the “outtype=’shared’” parameter of the cc task,
> >so I don’t have an easy means to experiment with changing that since I
> >need a shared library to be generated.
>
> >If you need any other info let me know.
>
> >Regards,
>
> >Rick Morgan
>
> https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: misterious GIT failure

2021-01-08 Thread Andrey Repin
Greetings, matthew patton!

> Adam Dinwoodie wrote:
>> This looks like some sort of problem writing to disk to me.  Where are
>> you storing your Git repositories?  Is it on a regular NTFS disk

> plain NTFS (win10 exterprise) with hundreds of GB free. I blew away
> contents of /tmp just to make sure it wasn't something silly going on there.
> It's git pack/unpack aborting the read/write from the pipe which causes SSH
> to then close and tear down the connection. SSH client helpfully provides
> stats on how many packets transferred up/down.

> Achim Gratz wrote:
>> That seems to indicate some sort of behavioral based firewalling or IDS

> I thought it could be that too. Tried with and without corporate VPN. But
> it's worked for over a year with this config and nary a hiccup. And anyway
> if I immediately switch to my WSL (Ubuntu) window or Git-Bash and issue the
> Git commands they run perfectly. Yes my Cygwin and WSL and Git-Bash share
> the exact same repository directories.
> If I blow away the entire Cygwin installation (c:\cygwin64) and re-install
> Cygwin Git it will resume working and do so for a while. Like I mentioned
> previously re-installing Git does not solve the issue. And yes my SSH
> sessions while Git is "broken" continue to work like a champ, so it's not SSH.
> I've attached cygcheck. Before I even posted I went looking for strace() to
> no avail. I also even did a manual connection attempt like this:   

>>> ssh blah | git index-pack --stdin -v --fix-thin '--keep=fetch-pack 1011 on 
>>> SOHO-GP4D633' --pack_header=2,1635

> and it would fail in the same manner as when it had been invoked "normally".

1. Try rebasing your Cygwin install.
2. See if your antivirus is interfering.


-- 
With best regards,
Andrey Repin
Saturday, January 9, 2021 5:22:54

Sorry for my terrible english...
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple