Newer Python? (was: Updated: python 3.8/3.9 packages)

[Michael Cook via Cygwin]

On Sat Dec 23 03:54:54 GMT 2023 Marco Atzeri wrote:
> Python 3.12 will be in the near future introduced and we will skip 3.10 and
3.11.

Is there a place where I can find the latest status of this effort?
And how can I help?

Michael

-- 
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

Additional odd behavior after my upgrade to the latest CYGWIN64 version

[Michael Goldshteyn via Cygwin]

Cygwin handles (filename) case insensitivity in a very weird way at the
Windows command prompt:
--
c:\Users\Michael>set CYGWIN=

c:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
a A a A a A

REM OK, so far so good, but, now:
c:\Users\Michael>set CYGWIN=glob:ignorecase

C:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
a a a a a A

REM So, if I don't put a command line arg into any sort of quotes, it gets
lower-cased for cygwin apps (from the Windows command line).
REM I should also add that there is no file named 'a' or 'A' in the current
working directory.

REM This behavior, of course, doesn't happen in Cygwin bash:
------
C:\Users\Michael>bash
Michael@lambda /cygdrive/c/Users/Michael
$ echo "$CYGWIN"
glob:ignorecase
Michael@lambda /cygdrive/c/Users/Michael
$ printf "%q " 'a' 'A' "a" "A" a A
a A a A a A
$ # Output looks correct, quoted or not
--
The unsolicited conversion of case for quoted string is very odd, to say
the least. If you remove the glob:ignorecase from the CYGWIN env var
definition, use of filenames on Windows with Cygwin tools becomes
completely case sensitive, which is very undesirable when compared to the
fact that other Windows tools do not care about file case (i.e., case
insensitive, but preserving, as MS puts it).

-- 
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

The grep 3.11 application when used in perl-regexp mode appears to now be broken

[Michael Goldshteyn via Cygwin]

I just updated my Cygwin64 installation, which includes the grep
utility and its behavior has changed. It no longer works like it used to
for Perl reg-ex matching, as demonstrated below:

Simple test cases:
==
$ ls -l a
-rwxr-xr-x 1 Michael None 6 Mar 16 12:15 a

$ hexdump -C a
  31 30 30 30 0d 0a |1000..|
0006

# Notice the CR/LF encoding after the "1000" text, as is the case for DOS
text files

# Now let's test grep regular match
$ grep --version
grep (GNU grep) 3.11
Packaged by Cygwin (3.11-1)
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others; see
<https://git.savannah.gnu.org/cgit/grep.git/tree/AUTHORS>.

grep -P uses PCRE2 10.43 2024-02-16

$ grep '000' a
1000

# Match using pcre2
$ grep -P '000' a
1000

# OK, so far so good
$ grep -P '000$' a
# No match

# Put another way
$ grep -c -P '000$' a
0

# Now you may be thinking, OK, it's because of the CR/LF line ending
# But, I present the following
$ pcre2grep --version
pcre2grep version 10.43 2024-02-16

$ pcre2grep '000$' a
1000

# As a further cross-check, the same version of the cygpcre2-8-0.Dll is
used for both grep.exe and pcre2grep.exe, as shown below with an "=>"
annotation added by me to direct you to the Dll in question:

$ ldd grep.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffa87d5)
KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL
(0x7ffa8770)
KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll
(0x7ffa8557)
cygwin1.dll => /usr/bin/cygwin1.dll (0x7ff9c84d)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x5ee2d)
=>cygpcre2-8-0.dll => /usr/bin/cygpcre2-8-0.dll (0x5ec2b)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3dff1)

$ ldd pcre2grep.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffa87d5)
KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL
(0x7ffa8770)
KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll
(0x7ffa8557)
=>cygpcre2-8-0.dll => /usr/bin/cygpcre2-8-0.dll (0x5ec2b)
cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3ed56)
cygwin1.dll => /usr/bin/cygwin1.dll (0x7ff9c84d)
cygz.dll => /usr/bin/cygz.dll (0x5ebb1)

# For what it's worth, I also checked into what versions of libintl8 and
libiconv-2 I have, and these are as follows:
# libintl8 0.22.4-1
# libiconv2 1.17-1

# And as an addition cross-check, I will include the following "complete
hack":
$ strings cygintl-8.dll | pcre2grep '^\d\.\d\d'
0.22.4
0.22.4

$ strings cygiconv-2.dll | pcre2grep '^\d\.\d\d'
1.17
1.17

# For completeness, here is my CYGWIN environment variable setting and some
other info:
$ echo "$CYGWIN"
glob:ignorecase winsymlinks:native pipe_byte
$ echo "$CYGWIN64_DIR"
c:\cygwin64
$ which grep
/usr/bin/grep
$ which pcre2grep
/usr/bin/pcre2grep
# No aliases are set up for these, either
$ alias grep pcre2grep
bash: alias: grep: not found
bash: alias: pcre2grep: not found
==
Further comments:
I do not know with which version of grep.exe this misbehavior (or at least
misaligned behavior with respect to grep2pcre) of the '-P' switch began. I
discovered it after updating my Cygwin64 install to use the latest grep
version, which likely also picked up the latest version of PCRE2 and
other dependencies along the way.

Thank you for looking into this and/or providing constructive comments on
the source of the issue,

Michael Goldshteyn

-- 
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: Updated: setup (2.930)

[Michael Soegtrop via Cygwin]

Hi Jon,


Thanks for reporting this.

For the time being, I've reverted the URL to point to the previous 
32-bit build, while I investigate.


Thanks for the quick action! I can confirm that this fixed my CI (at 
least it starts to install Cygwin).


Best regards,

Michael

--
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: Updated: setup (2.930)

[Michael Soegtrop via Cygwin]

Hi Jon,

> A new version of Setup (2.930) has been uploaded to:
>
>   https://cygwin.com/setup-x86_64.exe  (64 bit version)
>   https://cygwin.com/setup-x86.exe (32 bit version)

apparently this update broke the 32 bit install of cygwin. I am still 
having this in my nightly CI (Coq Platform) and it broke the night 7th 
to 8th. I checked locally and apparently the list of mirrors is empty 
and giving any mirror on the command line leads to an exit of setup 
without any error message. I tried e.g.:


"C:\bin\cygwin_cache\setup-x86.exe" --proxy " " --site 
"https://mirrors.kernel.org/sourceware/cygwin"; --root 
"C:\bin\cygw32_coq_platform" --local-package-dir "C:\bin\cygwin_cache" 
--no-shortcuts --allow-unsupported-windows -q --no-admin


I checked the specific mirror I gave and the x86 packages appear to be 
still there.


This is 100% reproducible locally and in GitHub CI

Best regards,

Michael

--
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: Recent update of libgpg-error0 and libassuan0 break curl and Opam (OCaml package manager)

[Michael Soegtrop via Cygwin]

Hi Marco,


I just rolled back the libgpg-error0 as fast term solution,
it will need some hours to propagate to the various mirrors


thank you for the quick action! I can confirm that our nightly Windows 
CI with latest cygwin runs through fine again.



Sorry for the inconvenience


Nothing to say sorry for - cygwin is in my experience stability wise 
better than major Linux distros. Thank you for the good work!


Best regards,

Michael

--
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: Recent update of libgpg-error0 and libassuan0 break curl and Opam (OCaml package manager)

[Michael Soegtrop via Cygwin]

Dear Cygwin Team & Users,


Looks like this problem converges on the libgpg-error update, gpg2 also
segfaults with this library installed.


I can confirm that just downgrading:

  libgpg-error0-1.47-1 -> libgpg-error0-1.37-1

and keeping the update of libassuan0:

  libassuan0-2.5.5-1   -> libassuan0-2.5.6-1

fixes the issue with curl and opam.

Since there seem to be various issues with this update of libgpg-error0, 
can we please have a roll-back?


Best regards,

Michael

--
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

Recent update of libgpg-error0 and libassuan0 break curl and Opam (OCaml package manager)

[Michael Soegtrop via Cygwin]

Dear Cygwin Team,

my daily CI of Coq Platform indicates that this update:

libassuan0-2.5.5-1   -> libassuan0-2.5.6-1
libgpg-error0-1.47-1 -> libgpg-error0-1.37-1

breaks Opam, the OCaml package manager, via a failed call to curl as can 
be seen by executing these commands:


$ wget 
https://github.com/fdopen/opam-repository-mingw/releases/download/0.0.0.2/opam64.tar.xz 
-O "opam64.tar.xz"

$ tar -xf "opam64.tar.xz"
$ bash opam64/install.sh --prefix "/usr/$(uname 
-m)-w64-mingw32/sys-root/mingw"
$ opam init --bare --shell-setup --enable-shell-hook --enable-completion 
'default' 'https://opam.ocaml.org' --disable-sandboxing


Replacing the DLLs of libassuan0 and libgpg-error0 with the previous 
versions listed above (just replace the DLLs) fixes this.


I had a look at what happens with Procmon. In the end a call to cygwn 
curl (from a MinGW app) fails. In Procmon I can see that curl 
successfully downloads the file and crashes immediately after closing 
the output file. With the old versions of libassuan0 and libgpg-error0, 
curl succeeds. That this download as such is successful shows that this 
is not a temporary network hickup (I also tested it at least 10 times 
either way).


Usual usages of curl seem to work - I couldn't reduce the failure 
reproduction beyond the above 4 lines and couldn't figure out what is so 
special about the curl call of opam.


This is quite painful for me - I was in the middle of a release of Coq 
Platform (a widely used distribution of the Coq proof assistant), when 
my Windows CI (which does a cygwin based MinGW cross compilation of 
OCaml and Coq) failed. Especially painful is that there is no easy way 
to install older package versions from the command line.


I would appreciate a fast roll back. Otherwise I have to find a way to 
install the older versions without user interaction.


Btw.: I do a daily build test of Coq Platform with a fresh cygwin since 
about 6 years and this is only the fourth failure! I really appreciate 
the stability of cygwin - excellent work!


Best regards,

Michael

--
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

Errors in setup.log around ca-certificates and openssl (seems to work anyway)

[Michael Soegtrop via Cygwin]

Dear Cygwin Team,

since a while I have these errors in the setup log file of new cygwin 
installations


C:\bin\cygwin\var\log\setup.log.full:

running: C:\bin\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/ca-certificates.sh"
/usr/bin/ln: failed to create symbolic link 
'/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': 
Permission denied

abnormal exit: exit code=1

running: C:\bin\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/openssl.sh"

can't run /etc/postinstall/openssl.sh: No such file

Things like HTTPS downloads with curl seem to work anyway so these 
errors might be benign, but they are still not nice.


Best regards,

Michael


--
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: portaudio: only OSS host API available since version 19.20210406-2

[Michael Panzlaff via Cygwin]

Hi,


In my environment, portaudio with MME support generates choppy sound
for the suggestedOutputLatency of less that 60 ms. 70 ms seems to
work. In this case, hostBufferCount=8 and hostBufferSizeFrams=480
if the sample rate is 48 kHz. So, total buffer length is 3840 samples.
Therefore, the resulted  latency is 80 ms.


interesting. I've now did some experiments with a self compiled 
portaudio with MME and WASAPI and both worked flawless on my machine 
with a suggestedLatency of 10ms. Perhaps this is dependend on the sound 
card used in the computer. The callbacks are called with framesPerBuffer 
of 480.



OSS implementation in cygwin 3.4.9 always uses the buffer size of
125 ms. So, even if hostBufferCount=2 (current value of portaidio
with OSS support), the latency is 250 ms. This might not be acceptable
for some applications.


I wouldn't mind using OSS if it supports lower hostBufferSizes so that I 
don't get callbacks with a buffer size of 6000. Apparently 
suggestedLatency has no influence on that.

Unfortunately, OSS and MME/DSound/WASAPI can be exclusively enabled.
I am currently considering whether to rollback portaudio to MME/
DSound/WASAPI until cygwin 3.5.0 is released.


I guess it would be possible but would probably require a patched 
configure script.


Either way if you change it away from OSS or now, I hope I could provide 
some useful feedback.


Best regards,
Michael

--
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: portaudio: only OSS host API available since version 19.20210406-2

[Michael Panzlaff via Cygwin]

Hi,

thank you for the quick reply. I checked my program again and there was 
indeed a bug which prevent OSS from working. Though, it's not really OSS 
what was the problem. The problem was the huge buffer size that OSS causes.


I set a suggested latency of 0.008 (which is what I obtain from 
defaultLowOutputLatency) and the audio callback get's a framesPerBuffer 
size of 6000! At 48 kHz that is more than 100 ms of latency. I'm not 
suggesting that MME is the best solution, but it was able to get 
something below 50 ms (not sure what defaultLowOutputLatency was with that).


Is there a difference when building portaudio for Cygwin instead of 
native Windows? Is there a specific reason why MME, DirectSound, WASAPI 
are not available? Do they cause maintenance overhead?


Am 29.09.2023 um 12:04 schrieb Takashi Yano:

On Fri, 29 Sep 2023 02:12:51 +0200
Michael Panzlaff rote:

Hi,

I got the right mailing list by not writing to cygwin-apps.
Since my last cygwin update (which upgraded portaudio
to 19.20210406-2) the library does not function properly anymore an no
sound playback is possible.

Usually you query portaudio for the various host APIs for and then open
a stream. In the past Cygwin's portaudio at least supported output via
MME. In the latest version 19.20210406-2 this doesn't work anymore. The
only available host API that is reported is OSS, but that doesn't really
exist on Windows I assume. My best guess is that the package isn't
configured correctly and isn't compiled with the correct support for all
the APIs.

I'd be very welcome to get back support for MME. My application is
currently unsuable on Cygwin because the library doesn't work. If it's
just a matter of correctly configuring the package, I'd be interested in
also getting support for the other host APIs that portaudio usually
supports on native Windows, but that's entirely optional for me :)

Now that I checked, even downgrading to an older version of portaudio
from the Cygwin installer doesn't fix the problem. So perhaps it's not
caused by portaudio but from something else in Cygwin. Does anybody have
any ideas?

Best regards
Michael Panzlaff

PS: Here is a sample C code which queries the host APIs and which should
list MME and definitely not OSS:


OSS is implemented in cygwin and it works. 19.20210406-2 switches it backend
to OSS rather than win32apis.

Are there any reason to stick to MME backend?




--
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

portaudio: only OSS host API available since version 19.20210406-2

[Michael Panzlaff via Cygwin]

Hi,

I got the right mailing list by not writing to cygwin-apps.
Since my last cygwin update (which upgraded portaudio
to 19.20210406-2) the library does not function properly anymore an no 
sound playback is possible.


Usually you query portaudio for the various host APIs for and then open 
a stream. In the past Cygwin's portaudio at least supported output via 
MME. In the latest version 19.20210406-2 this doesn't work anymore. The 
only available host API that is reported is OSS, but that doesn't really 
exist on Windows I assume. My best guess is that the package isn't 
configured correctly and isn't compiled with the correct support for all 
the APIs.


I'd be very welcome to get back support for MME. My application is 
currently unsuable on Cygwin because the library doesn't work. If it's 
just a matter of correctly configuring the package, I'd be interested in 
also getting support for the other host APIs that portaudio usually 
supports on native Windows, but that's entirely optional for me :)


Now that I checked, even downgrading to an older version of portaudio 
from the Cygwin installer doesn't fix the problem. So perhaps it's not 
caused by portaudio but from something else in Cygwin. Does anybody have 
any ideas?


Best regards
Michael Panzlaff

PS: Here is a sample C code which queries the host APIs and which should 
list MME and definitely not OSS:


#include 

#include 

int main(void) {
printf("Pa_Initialize() = %d\n", Pa_Initialize());
PaHostApiIndex count = Pa_GetHostApiCount();
printf("%d host APIs available:\n", count);

for (int i = 0; i < count; i++) {
const PaHostApiInfo *info = Pa_GetHostApiInfo(i);
printf("%s\n", info->name);
}
}

--
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: Add single package without installation update

[Michael Lemke via Cygwin]

On Mon, 19 Jun 2023 13:04:06 +0200, Jon Turney  
wrote:


On 18/06/2023 20:58, Michael Lemke via Cygwin wrote:

I just wanted to install a package which I hadn't installed before but
since I haven't updated my installation in a while I get a huge list of
stuff to update. Is there a way in setup to install just the new package
without having to click on every package in the list? Updating
everything is just not convenient at the moment.


Select 'keep' mode in the radio buttons in the upper right of the
package chooser.  Then select your new package for installation.



Thank you, that did the trick.

--
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

Add single package without installation update

[Michael Lemke via Cygwin]

I just wanted to install a package which I hadn't installed before but since I 
haven't updated my installation in a while I get a huge list of stuff to 
update. Is there a way in setup to install just the new package without having 
to click on every package in the list? Updating everything is just not 
convenient at the moment.

--
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: Creating the sqlite3.exe stand-alone w/o cygwin dependency

[Michael Soegtrop via Cygwin]

Hi José,

Yes, I did. I think you missed one of my emails. But, here is what I did:

$ ldd sqlite3.exe
 ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffc1d6f)
 ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x778c)
 wow64.dll => /cygdrive/c/Windows/System32/wow64.dll (0x7ffc1c83)
 wow64win.dll => /cygdrive/c/Windows/System32/wow64win.dll 
(0x7ffc1d54)


Ah, you compiled a 32 bit executable - I guess on a 64 bit install of 
cygwin.


Try

./configure --host=x86_64-w64-mingw32 CFLAGS=-shared CFLAGS=-static-libgcc

instead of

./configure --host=i686-w64-mingw32 CFLAGS=-shared CFLAGS=-static-libgcc

Of course you need to install the corresponding tool chain in cygwin.

As far as I can tell compiling 32 bit apps on 64 bit cygwin did never 
work (easily). Afair the reason is that certain DLLs like 
SYSTEM32/ntdll.dll have 2 copies under the same file name, a 32 bit and 
a 64 bit variant (a Windows file system hack). Which one you get depends 
on if the calling process is 32 bit or 64 bit. Now if you try to link a 
32 bit executable with a 64 bit linker, it gets the wrong DLL, so your 
32 bit app ends up being linked to a 64 bit DLL.


One could only compile 32 bit Windows apps with 32 bit cygwin - since 
this is no longer supported, I would say 32 bit MinGW is neither. There 
are hacks around this (use a 32 bit executable to copy the DLLs from 
System32 somewhere else and redirect the linker to these files). But the 
better choice is to stop compiling for 32 bit.


Best regards,

Michael


--
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: Creating the sqlite3.exe stand-alone w/o cygwin dependency

[Michael Soegtrop via Cygwin]

Hi José,

did you try copying the MinGW DLLs as I suggested?

You find them in folder 
"\usr\x86_64-w64-mingw32\sys-root\mingw\bin" and as I said 
"ldd" will tell you which ones you need. As a test you can also simply 
copy all of them to your bin folder, but it might be many (I have 85 
DLLs in this folder, it depends on which MinGW libraries you installed 
in cygwin).


I didn't do this for sqlite, but for quite a number of open source 
executables and this always worked since years. I would say this is the 
recommended way of doing it.


Static linking is also an option, but typically not well supported by 
the build systems. Also note that the distribution of a statically 
linked executable in many cases violates open source licenses, but doing 
this just for yourself is OK.


Best regards,

Michael


--
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: Creating the sqlite3.exe stand-alone w/o cygwin dependency

[Michael Soegtrop via Cygwin]

> The problem happens after I move that sqlite3.exe to C:\bin directory.

very likely quite a few of the MinGW shared libraries supplied by cygwin 
are missing - you need to copy these as well. You can use the `ldd` tool 
on the .exe and the .dll to find out which these are. You need to copy 
sqlite.dll and all MinGW shared libraries required by both to the bin 
folder. A typical example is the C runtime shared library-


I have no idea about sqlite, but I maintain a project which compiles 
MinGW executables using shared libraries and create relocatable 
installers from that. The shell script which finds the shared library 
dependencies is here:


https://github.com/coq/platform/blob/cb1646593beb42629d660e22323a3fe9e3779435/windows/create_installer_windows.sh#L107

It should explain how to do this.

Best regards,

Michael


--
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: [EXTERNAL] [BULK] Re: Internal Server Error running perl script in browser

[Michael Lascuola via Cygwin]

Thanks for the response!  Forgive me, as I am SQL Server DBA.  Is there another 
way I should check this?

$ perl -v

This is perl 5, version 32, subversion 1 (v5.32.1) built for 
x86_64-cygwin-threads-multi
(with 7 registered patches, see perl -V for more detail)

Copyright 1987-2021, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.


$ which perl
/usr/local/bin/perl

-Original Message-
From: Cygwin  On Behalf Of René 
Berber
Sent: Thursday, November 17, 2022 11:52 AM
To: cygwin@cygwin.com
Subject: [EXTERNAL] [BULK] Re: Internal Server Error running perl script in 
browser

WARNING: This email originated outside of the Salina Regional Health Center 
email system.
DO NOT CLICK links or attachments unless you recognize the sender and know the 
content is safe.


On 11/17/2022 10:22 AM, Michael Lascuola via Cygwin wrote:
> Good day!
>
> I have an issue where I receive "Internal Server Error" when running perl 
> scripts in the browser.  Here's an example script that works OK when running 
> from the Cygwin Terminal:
>
> #!/usr/local/bin/perl

That is not Cygwin perl.

If you build it, or installed it from somewhere else... then its your problem, 
not a Cygwin problem.

[snip]


--
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
IMPORTANT NOTICE AND DISCLAIMER: The information contained in this e-mail, 
including any attachments, is privileged, strictly confidential, and is 
intended only for the use of the addressee(s) indicated above. If you are not 
an intended recipient of this e-mail, you are strictly prohibited from reading, 
reviewing, using, disclosing, printing, copying or disseminating this e-mail, 
and are asked to (a) notify the sender only of your receipt of this e-mail, and 
(b) permanently delete this e-mail immediately. Thank you.


-- 
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

Internal Server Error running perl script in browser

[Michael Lascuola via Cygwin]

Good day!

I have an issue where I receive "Internal Server Error" when running perl 
scripts in the browser.  Here's an example script that works OK when running 
from the Cygwin Terminal:

#!/usr/local/bin/perl
use DBI;
my @ary = DBI->available_drivers();
print @ary;

print "Content-type:text/html\n\n";
print "My First Script\n\n";
print "\n";
print "Hello from mpl.pl\n";
print "";


Here are the results:

$ perl  mpl.pl
DBMExamplePFileGoferMemODBCProxySpongeContent-type:text/html

My First Script


Hello from mpl.pl



/var/log/httpd/error_log shows:

[Wed Nov 16 19:49:40.191277 2022] [cgi:error] [pid 26397] [client 
192.168.220.164:59271] AH01215: Can't locate loadable object for module DBI in 
@INC (@INC contains: /usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads 
/usr/local/share/perl5/site_perl/5.32 
/usr/lib/perl5/vendor_perl/5.32/x86_64-cygwin-threads 
/usr/share/perl5/vendor_perl/5.32 /usr/lib/perl5/5.32/x86_64-cygwin-threads 
/usr/share/perl5/5.32) at /usr/share/perl5/5.32/DBI.pm line 284.: 
/srv/www/cgi-bin/mpl.pl
[Wed Nov 16 19:49:40.191798 2022] [cgi:error] [pid 26397] [client 
192.168.220.164:59271] AH01215: BEGIN failed--compilation aborted at 
/usr/share/perl5/5.32/DBI.pm line 284.: /srv/www/cgi-bin/mpl.pl
[Wed Nov 16 19:49:40.192094 2022] [cgi:error] [pid 26397] [client 
192.168.220.164:59271] AH01215: Compilation failed in require at 
/srv/www/cgi-bin/mpl.pl line 2.: /srv/www/cgi-bin/mpl.pl
[Wed Nov 16 19:49:40.192408 2022] [cgi:error] [pid 26397] [client 
192.168.220.164:59271] AH01215: BEGIN failed--compilation aborted at 
/srv/www/cgi-bin/mpl.pl line 2.: /srv/www/cgi-bin/mpl.pl
[Wed Nov 16 19:49:40.192495 2022] [cgi:error] [pid 26397] [client 
192.168.220.164:59271] End of script output before headers: mpl.pl

DBI.pm is in at least 2 of the locations listed in @INC
$ ll /usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads/DBI.pm
-rwxr-xr-x 1 svc_dpa_sql Domain Users 318199 Nov 17 10:18 
/usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads/DBI.pm*

I have reinstalled DBI, but the symptoms remain.

Enclosed is the output from cygcheck -s -v -r -h > cygcheck_output.txt and 
httpd.conf, if they help.

Where would you look next?

Thanks!!

IMPORTANT NOTICE AND DISCLAIMER: The information contained in this e-mail, 
including any attachments, is privileged, strictly confidential, and is 
intended only for the use of the addressee(s) indicated above. If you are not 
an intended recipient of this e-mail, you are strictly prohibited from reading, 
reviewing, using, disclosing, printing, copying or disseminating this e-mail, 
and are asked to (a) notify the sender only of your receipt of this e-mail, and 
(b) permanently delete this e-mail immediately. Thank you.
# cygcheck -s -v -r -h > cygcheck_output.txt

Cygwin Configuration Diagnostics
Current System Time: Wed Nov 16 19:20:14 2022

Windows 2016 Server Standard Ver 10.0 Build 14393 

Running in Terminal Service session

Path:   C:\cygwin64\home\svc_dpa_sql\perl5\bin
C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Strawberry\c\bin
C:\Strawberry\perl\site\bin
C:\Strawberry\perl\bin
C:\Program Files\PowerShell\7
C:\Users\svc_dpa_sql\AppData\Local\Microsoft\WindowsApps
.
C:\cygwin64\opt\dbamon\bin
C:\cygwin64\usr\sbin
C:\cygwin64\home\svc_dpa_sql\bin

Output from C:\cygwin64\bin\id.exe
UID: 1122295(svc_dpa_sql)
GID: 1049089(Domain Users)
1049089(Domain Users)
544(Administrators)
555(Remote Desktop Users)
545(Users)
14(REMOTE INTERACTIVE LOGON)
4(INTERACTIVE)
11(Authenticated Users)
15(This Organization)
4095(CurrentSession)
66048(LOCAL)
1094623(exactACCESS Users)
1104417(CTRX File Explorer)
1101140(SQL SA)
1105935(CTRX SRHC Users)
1078627(Citrix Users)
1095766(hciDevUsers)
1104415(CTRX HealthStream web app)
70145(Authentication authority asserted identity)
405504(High Mandatory Level)

SysDir: C:\Windows\system32
WinDir: C:\Windows

Here's some environment variables that may affect cygwin:
USER = 'svc_dpa_sql'
PWD = '/home/svc_dpa_sql'
HOME = '/home/svc_dpa_sql'

Here's the rest of your environment variables:
USERDOMAIN = 'SRHC'
OS = 'Windows_NT'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
PROCESSOR_LEVEL = '6'
PSModulePath = 'C:\Program 
Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules'
CommonProgramW6432 = 'C:\Program Files\Common Files'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
TZ = 'America/Chicago'
POWERSHELL_DISTRIBUTION_CHANNEL = 'MSI:Windows Server 2016 Standard'
HOSTNAME = 'IT-SQL-DBA'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/opt/dbamon/adm/instances_test'
PERL_MB_OPT = '--install_base "/home/svc_dpa_sql/perl5"'
USERNAME = 'svc_dpa_sql'
LOGONSERVER = '\\MHS-DC1'
PROCESSOR_ARCHITECTURE = 'AMD64'
PLOTICUS_PREFABS = '/usr/share/ploticus/prefabs'

Re: [ANNOUNCEMENT] Updated: curl, libcurl{4, -devel, -doc}, mingw64-{x86_64, i686}-curl 7.86

[Michael Soegtrop via Cygwin]

Adding to the note by Lem regarding a missing dependency of curl since 
this update, I want to note that in a standard installation of cygwin 
curl fails since this update with:


    the following programs are not installed properly:

    curl curl

Best regards,

Michael


--
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: When only rsync will do .. or maybe not

[Lemke, Michael SF/HZA-ZE2E]

On October 14, 2022 3:36 PM Cyrille Lefevre wrote:
>Le 12/10/2022 à 12:55, Fergus Daly a écrit :
>> Requirement: to move some selected files and folders under /folder1/ to 
>> /folder2/, preserving full pathnames.
>> 
>> Using cp with the switch --parents (taking care over syntax and importantly 
>> location $PWD) it is possible to _copy_ the
>> Required content across from /folder1/ to /folder2/ but there does not seem 
>> to be a matching switch for mv that would
>> achieve the same purpose.
>> 
>> One solution would be (i) to copy the required content to /folder2/ and then 
>> (ii) delete the identical content under /folder1/;
>> but this is expensive (one might not even have the disk space to do it) and 
>> it seems seriously unsatisfactory and not without risk
>> to have to copy folders and files (possibly huge) when all one wants to do 
>> is to change the {pathname} to them.
>> 
>> Question 1
>> Would the command (or something like it, again with care over syntax and 
>> $PWD)
>> $ rsync -axuv --progress {pathto}/folder1/{content} {pathto}/folder2/
>> do the trick? Or is the very existence of the switch
>> $ rsync -axuv --remove-source-files --progress {pathto}/folder1/{content} 
>> {pathto}/folder2/
>> indicative that here too the "move" is achieved through a two-stage 
>> "copy-then-delete" operation?
>> 
>> Question 2
>> If rsync can provide a genuine "move" capability then is installing the 
>> rsync package adequate to the purpose;
>> or would librsync-devel and/or librsync2 packages need to be installed also?
>> 
>> Question 3
>> If not rsync, is there any operation for which "move" can be achieved 
>> without involving "copy-then-delete"?
>> 
>> Thank you for any assistance.
>> 
>> 
>
>Hi,
>
>how about find /source | cpio -pdml /target
>alternative, cp -alu --parent /source /target
>then purge /source
>

Another idea: instead of copies create hardlinks in /folder2 (ln without -s) 
and then use 'find /folder1 -links 2 ...' to remove the originals. Exact syntax 
left as an exercise to the reader. Method is a little fragile if hardlinks 
exist in /folder1. Use with caution. Additional space required is just the 
directory entries.

Michael

-- 
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: Generating Linux Compatible binaries

[Michael Enright]

On Fri, Dec 3, 2021 at 8:51 AM Goswami-EXT, Himanshu
 wrote:
>
> Hi,
>
> I want to generate the Linux compatible binaries on Windows System.
> Cygwin is a cross compiler which offers POSIX environment.
> But I could not find any Unix libraries to generate the Linux compatible 
> binaries.
> Could you please advice any steps that I can follow?
>

Eliot Moss recommends a VM and that's a good option.

Another option is to use Cygwin to host a cross compiler. I  have used
Cygwin to build and install cross compilers that ran on Cygwin and
built code for my Raspberry Pi 2. There are many tutorials on building
and creating cross compilers and I won't try to equal them. But this
is a versatile method. If the target Linux was one that runs on a
different processor and a virtual machine would be inefficient or lack
the resources to carry out the build, then running a cross compiler on
your Windows machine, under Cygwin or otherwise, might be an option to
consider.

-- 
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: possible snprintf() regression in 3.3.2

[Lemke, Michael SF/HZA-ZI2E]

On Wednesday, November 24, 2021 10:28 AM Corinna Vinschen wrote:
> On Nov 24 18:14, Takashi Yano via Cygwin wrote:
> > On Wed, 24 Nov 2021 17:52:04 +0900
> > Takashi Yano wrote:
> > > The printed value is still something wrong...
> > > sqrt(2)*1e70 should be an integer value.
> > 
> > I mean...
> > 
> > sqrt(2)*1e70 is actually not an integer, however, double has mantissa
> > of only 52 bit. So, (double value)*(5^70*2^70) should be an integer.
> 
> The conversion is a bit inexact, I guess, but that's another problem
> of this old ldto, right?

Just in case you didn't notice: Only the first 16 digits of both of
Takashi's long numbers are correct. Floating point accuracy?

Michael

-- 
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: [Bug] tmux 3.2-0

[Michael Wild via Cygwin]

> > [...]
> > As I said in the original posting, the test suite for mosh makes use of
> > control mode.
> > [...]

I just uploaded a patched test version 3.2-1 (yeah, I know, I'm off by
one with the release number...). Can you give it a go and see whether
the mosh test suite runs through with it?

Cheers

Michael

-- 
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: [Bug] tmux 3.2-0

[Michael Wild via Cygwin]

On Mon, May 31, 2021 at 8:30 PM Achim Gratz wrote:
>
> Michael Wild via Cygwin writes:
> > Just out of curiosity: is this a critical feature for you? E.g. are
> > you automating tmux with it? Because as far as I understand control
> > mode is intended for integration with terminal emulators. And so far,
> > iTerm2 on Mac is the only one implementing the protocol.
>
> As I said in the original posting, the test suite for mosh makes use of
> control mode.  Besides the terminal integration (that is non-existing on
> Cygwin AFAIK) this sort of controlling terminals from scripts/automation
> is probably uncommon.  GNU parallel might be using control mode too,
> although I've not tried that mode and it has no official Cygwin package
> either (but I use it on Cygwin).  OTOH, it is surprising that control
> mode suddenly stopped working in Cygwin.

I opened an issue with upstream: https://github.com/tmux/tmux/issues/2725.

It appears that the problem is not a simple #ifdef missing. Tmux is
now passing the file handle for stdout from the client to the server
processes, something that Cygwin doesn't support (see
https://sourceware.org/legacy-ml/cygwin/2004-01/msg00060.html). The
upstream author mentioned a potential workaround. Maybe there's
someone with the necessary skills here on the mailing list who has the
time to lend him a hand?

Regards

Michael

-- 
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: [Bug] tmux 3.2-0

[Michael Wild via Cygwin]

On Wed, May 26, 2021 at 12:08 PM ASSI wrote:
>
> Michael Wild via Cygwin writes:
> > Sorry for the mistake with the release number. Should that be a sanity
> > check in calm?
>
> I personally don't think so, if you want to do a test / pre-release then
> starting with a "0" seems netural to me.
>
> > As for the problem with the control mode: Is there anything I can do?
>
> Since it's clearly a regression (on cygwin), it would be a start to
> check if any new warnings have popped up during compilation.
>
> > Like forwarding the problem to upstream? Or do you consider it to be
> > "unfixable" until Cygwin implements the control mode properly?
>
> I don't know, I haven't looked beyond the fact that
>
> tmux -C new
>
> doesn't give you any of the expected output and indefinitely hangs
> (although it seems to process at least some commands that you enter).  I
> still hope it might just be a misguided #ifdef targeting Cygwin or some
> simarly silly mistake.
>
>
> Regards,
> Achim.

I just tried the following:

Terminal 1:
$ tmux new -s mysession

Terminal 2:
$ tmux -C attach -t mysession
split-window
split-window -h

And as expected, in Terminal 1 the window got split first vertically,
then horizontally. However, in version 3.1b Terminal 2 was echoing the
commands from Terminal 1. This doesn't happen with version 3.2
anymore. I verified by building 3.2 in WSL 2 (Ubuntu 20.04) and there
the echoing does work.

Just out of curiosity: is this a critical feature for you? E.g. are
you automating tmux with it? Because as far as I understand control
mode is intended for integration with terminal emulators. And so far,
iTerm2 on Mac is the only one implementing the protocol.

Regards

Michael

-- 
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: [Bug] tmux 3.2-0

[Michael Wild via Cygwin]

On Tue, May 25, 2021 at 11:02 PM Achim Gratz wrote:
>
> Achim Gratz writes:
> > Michael Wild via Cygwin-announce via Cygwin writes:
> >> The following packages have been uploaded to the Cygwin distribution:
> >>
> >> * tmux-3.2-0
> >
> > [nit]
> > General releases should be numbered starting with 1.
> >
> > Is the control mode working as intended and if yes, is there a way to
> > get the old behaviour back that did send the output block to stdout and
> > then terminated?
>
> Control mode isn't working correctly in Cygwin (compared to the same
> version of tmux in Linux).  The expected output never makes it to the
> control mode client.

Hi Achim

Sorry for the mistake with the release number. Should that be a sanity
check in calm?

As for the problem with the control mode: Is there anything I can do?
Like forwarding the problem to upstream? Or do you consider it to be
"unfixable" until Cygwin implements the control mode properly?

Michael

-- 
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] tmux 3.2-0

[Michael Wild via Cygwin-announce via Cygwin]

The following packages have been uploaded to the Cygwin distribution:

* tmux-3.2-0

tmux enables a number of terminals (or windows) to be accessed and
controlled from a single terminal like screen. tmux runs as a server-client
system. A server is created automatically when necessary and holds a number of
sessions, each of which may have a number of windows linked to it. Any number
of clients may connect to a session, or the server may be controlled by issuing
commands with tmux. Communication takes place through a socket, by default
placed in /tmp. Moreover tmux provides a consistent and well-documented command
interface, with the same syntax whether used interactively, as a key binding,
or from the shell. It offers a choice of vim or Emacs key layouts.

-- 
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] python-paramiko 2.7.2-0

[Michael Wild via Cygwin-announce via Cygwin]

The following packages have been uploaded to the Cygwin distribution:

* python36-paramiko-2.7.2-0
* python37-paramiko-2.7.2-0
* python38-paramiko-2.7.2-0

This is a library for making SSH2 connections (client or server).
Emphasis is on using SSH2 as an alternative to SSL for making secure
connections between python scripts. All major ciphers and hash methods
are supported. SFTP client and server mode are both supported too.

-- 
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: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win

[Lemke, Michael SF/HZA-ZIC2]

On April 7, 2021 8:47 PM Achim Gratz wrote:
>L A Walsh writes:
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?
>
>Windows never had "focus follows mouse" in any version I can remember.
>

It has had it since Windows95 or so and it is my default setting on 
any PC I use. Attached is a little program I wrote a long time ago that 
turns the feature on or off. Compile with `gcc xmouse.c` or mingw.

Something like this was included in the Windows PowerToys as xmouse.exe.

Michael
#define WINVER 0x0500
#include 
#include 
 
/* gcc -mno-cygwin -mwindows  ... */
 
void ErrorExit(LPTSTR lpszFunction, DWORD dw) 
{ 
LPVOID lpMsgBuf;
LPVOID lpDisplayBuf;
//DWORD dw = GetLastError(); 
 
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER | 
FORMAT_MESSAGE_FROM_SYSTEM,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0, NULL );
 
lpDisplayBuf = LocalAlloc(LMEM_ZEROINIT, 
strlen(lpMsgBuf)+strlen(lpszFunction)+40); 
wsprintf(lpDisplayBuf, 
"%s failed with error %d: %s", 
lpszFunction, dw, lpMsgBuf); 
MessageBox(NULL, lpDisplayBuf, "Error", MB_OK); 
 
LocalFree(lpMsgBuf);
LocalFree(lpDisplayBuf);
ExitProcess(dw); 
}
 
 
 
int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) {
//int main (void) {
 
   BOOL xmouse = FALSE;
 
   DWORD status;
 
   if( !(status=SystemParametersInfo( SPI_GETACTIVEWINDOWTRACKING,
  0,
  &xmouse,
  0
 )) ) {
  ErrorExit("Get mouse status",status);
   }

   if( !(status=SystemParametersInfo( SPI_SETACTIVEWNDTRKZORDER,
  0,
  (PVOID)FALSE,
  SPIF_UPDATEINIFILE || 
SPIF_SENDWININICHANGE
)) ) {
  ErrorExit("Set mouse status",status);
   }

   if( !(status=SystemParametersInfo( SPI_SETACTIVEWNDTRKTIMEOUT,
  0,
  (PVOID)100,
  SPIF_UPDATEINIFILE || 
SPIF_SENDWININICHANGE
)) ) {
  ErrorExit("Set mouse status",status);
   }

   xmouse = !xmouse;
   if( !(status=SystemParametersInfo( SPI_SETACTIVEWINDOWTRACKING,
  0,
  (PVOID)xmouse,
  SPIF_UPDATEINIFILE || 
SPIF_SENDWININICHANGE
)) ) {
  ErrorExit("Set mouse status",status);
   }
   printf( "X mouse is now %s.\n", xmouse ? "on" : "off" );
 
   return 0;
}
--
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: Sv: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

I think you can download pre-released builds from:

https://cygwin.com/snapshots/

As mentioned already, the fix here is not actually support of AF_UNIX 
sockets natively. My understanding is that they are implemented over 
loopback TCP in cygwin, but the fix allows native AF_UNIX sockets to be 
handled (eg deleted) as regular files through regular cygwin commands.


Michael.


On 16/03/2021 11:06, Kristian Ivarsson via Cygwin wrote:

Hi all

Does anyone know the status of these fixes ?

I saw an announcement for cygwin-3.2.0-0.1 that seemed to contain some
AF_UNIX-related fixes but I fail to find out where that distribution exists
(if it is supposed to be publicly accessible?), but I tried out the
2021-03-01 snapshot and perhaps they are similar ?

We bumped into some AF_UNIX-related issues when trying the 2021-03-01
-snapshot though. It might be some flaws in our code base but the same code
works in quite a few Linux-distros

We're more than willing to help out with testing this and/or trying to
narrow down any possible cygwin issues, but first we'd be glad if someone
could give us some kind of status report of this (so no one is doing any
unnecessary work)


Best regards,
Kristian

p.s.
I tried to build the topic/af_unix -branch according to the FAQ, but
there was some issues
d.s.




Hi Ken, Corinna

Sorry for the delay in responding. I have just tested the fix and it
works great. Thank you very much for looking into it.

When do you think it would be available in a form that regular users
would be able to update/install?

Corinna decides when to make a new Cygwin release.  My best guess is
"pretty soon".


Also, one observation FYI, is that the "ls -l" command on Unix
normally indicates sockets with an "s" as the first character of the
output: eg

srwxr-xr-x  1 Michael None 0 Feb  7 11:19 foo.sock

Currently, what is shown on Cygwin is

-rwxr-xr-x  1 Michael None 0 Feb  7 11:19 foo.sock

indicating a regular file.

Right.  From Cygwin's point of view, it is a regular file.  There might
come a time when Cygwin's AF_UNIX implementation makes use of native
Windows AF_UNIX sockets on systems that support them.  But that time is
not currently in sight.

Ken
--
Problem reports:  
https://urldefense.com/v3/__https://cygwin.com/problems.html__;!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJM8jmPtbA$
FAQ:  
https://urldefense.com/v3/__https://cygwin.com/faq/__;!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJMQE63Mlg$
Documentation:
https://urldefense.com/v3/__https://cygwin.com/docs.html__;!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJMRgFcrHA$
Unsubscribe info: 
https://urldefense.com/v3/__https://cygwin.com/ml/*unsubscribe-simple__;Iw!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJPOK0x2gw$

--
Problem reports:  
https://urldefense.com/v3/__https://cygwin.com/problems.html__;!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJM8jmPtbA$
FAQ:  
https://urldefense.com/v3/__https://cygwin.com/faq/__;!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJMQE63Mlg$
Documentation:
https://urldefense.com/v3/__https://cygwin.com/docs.html__;!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJMRgFcrHA$
Unsubscribe info: 
https://urldefense.com/v3/__https://cygwin.com/ml/*unsubscribe-simple__;Iw!!GqivPVa7Brio!OrhjUwBgvLe4_I38uHpiucq3-_xiQDxazv5s7XuBkOmzXTgGhz9Vb3GrB2RYCJPOK0x2gw$

--
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: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

Hi Ken, Corinna

Sorry for the delay in responding. I have just tested the fix and it 
works great. Thank you very much for looking into it.


When do you think it would be available in a form that regular users 
would be able to update/install?


Also, one observation FYI, is that the "ls -l" command on Unix normally 
indicates sockets with an "s" as the first character of the output: eg


srwxr-xr-x  1 Michael None 0 Feb  7 11:19 foo.sock

Currently, what is shown on Cygwin is

-rwxr-xr-x  1 Michael None 0 Feb  7 11:19 foo.sock

indicating a regular file.

All the best,

Michael.

On 01/02/2021 15:10, Corinna Vinschen via Cygwin wrote:

On Feb  1 10:04, Ken Brown via Cygwin wrote:

On 1/31/2021 6:30 PM, Michael McMahon wrote:

Thanks for taking this up again. While I had thought it was a Windows
bug, and it is arguable, but at least there is a reasonable workaround
for it. I'd be happy to test an update you have for it.

This should now be fixed.  As soon as Corinna has a chance to build new
snapshots, you'll be able to test it by installing a snapshot of cygwin1.dll
from

   
https://urldefense.com/v3/__https://cygwin.com/snapshots/__;!!GqivPVa7Brio!O47H_hw3AhLkrYlQii6UDqGK080PqYYal57b0lCpdErLSUCxWxepfI6N4dDuRAwTH0K4xA$

Available now.


Corinna
--
Problem reports:  
https://urldefense.com/v3/__https://cygwin.com/problems.html__;!!GqivPVa7Brio!O47H_hw3AhLkrYlQii6UDqGK080PqYYal57b0lCpdErLSUCxWxepfI6N4dDuRAwIKtlIwg$
FAQ:  
https://urldefense.com/v3/__https://cygwin.com/faq/__;!!GqivPVa7Brio!O47H_hw3AhLkrYlQii6UDqGK080PqYYal57b0lCpdErLSUCxWxepfI6N4dDuRAwMz06BeA$
Documentation:
https://urldefense.com/v3/__https://cygwin.com/docs.html__;!!GqivPVa7Brio!O47H_hw3AhLkrYlQii6UDqGK080PqYYal57b0lCpdErLSUCxWxepfI6N4dDuRAxsFrAxfg$
Unsubscribe info: 
https://urldefense.com/v3/__https://cygwin.com/ml/*unsubscribe-simple__;Iw!!GqivPVa7Brio!O47H_hw3AhLkrYlQii6UDqGK080PqYYal57b0lCpdErLSUCxWxepfI6N4dDuRAyiCIzNxQ$

--
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: Cygwin GDB won't start or hangs at startup

[Lemke, Michael SF/HZA-ZIC2]

On Friday, February 5, 2021 4:18 PM Takashi Yano wrote:
>On Fri, 5 Feb 2021 10:07:46 +0100
>Marco Atzeri wrote:
>> On 05.02.2021 08:55, Daniel Röhrborn via Cygwin wrote:
>> >> On 04.02.2021 13:13, Daniel Röhrborn via Cygwin wrote:
>> 
>> > 
>> > Hi Marco,
>> > it seems stacked and when blindly typing "quit" it responds with exiting. 
>> > So it seems like the output is invisible.
>> > Tested it with Win7_32bit, GDB version 9.2-1 with Cygwin/bin in PATH 
>> > (since the beginning).
>> > 
>> > Regards
>> > Daniel
>> 
>> I can not fully replicate on my W10,
>> 
>> but I notice that running from CMD there is a small difference
>> between the working instance
>> 
>> 
>> Marco@LAPTOP-82F08ILC /proc/3072/fd
>> i686 $ ls -l
>> total 0
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 0 -> /dev/cons1
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 1 -> /dev/cons1
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 10 -> pipe:[21474850180]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 2 -> /dev/cons1
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 3 -> pipe:[8589948292]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 4 -> pipe:[8589948292]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 5 -> pipe:[12884915588]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 6 -> pipe:[12884915588]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 7 -> pipe:[17179882884]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 8 -> pipe:[17179882884]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 9 -> pipe:[21474850180]
>> 
>> and a not working one
>> 
>> Marco@LAPTOP-82F08ILC /proc/3055/fd
>> i686 $ ls -l
>> total 0
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 0 -> /dev/cons0
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 1 -> pipe:[4294988268]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 10 -> pipe:[17179890156]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 11 -> pipe:[21474857452]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 12 -> pipe:[21474857452]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 2 -> pipe:[4294988268]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 3 -> pipe:[8589955564]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 4 -> pipe:[8589955564]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 5 -> /dev/cons0
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 6 -> /dev/cons0
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 7 -> pipe:[12884922860]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 8 -> pipe:[12884922860]
>> lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 9 -> pipe:[17179890156]
>> 
>> it is like the file descriptor of outputs are misaligned,
>> and I see two more of them
>> 
>> Maybe Takashi or Jon can provide hints on the matter.
>
>I looked into this problem and found this issue causes if iconv
>cannot be found in the search path.
>
>Installing libiconv package should solve the issue, I guess.

I can confirm that installing libiconv solves the problem. So it
was not a case of BLODA here.

>
>It seems that the GDB package should set a dependency on libiconv.
>

I had libiconv2 installed. Is that somehow related?


--
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: Cygwin GDB won't start or hangs at startup

[Lemke, Michael SF/HZA-ZIC2]

On Friday, February 5, 2021 3:08 PM Lemke, Michael SF/HZA-ZIC2 wrote:
>On Friday, February 5, 2021 10:08 AM Marco Atzeri wrote:
>>On 05.02.2021 08:55, Daniel RÃhrborn via Cygwin wrote:
>>>> On 04.02.2021 13:13, Daniel RÃhrborn via Cygwin wrote:
>>
>>> 
>>> Hi Marco,
>>> it seems stacked and when blindly typing "quit" it responds with exiting. 
>>> So it seems like the output is invisible.
>>> Tested it with Win7_32bit, GDB version 9.2-1 with Cygwin/bin in PATH (since 
>>> the beginning).
>>> 
>>> Regards
>>> Daniel
>>
>>I can not fully replicate on my W10,
>>
>>but I notice that running from CMD there is a small difference
>>between the working instance
>
>Remember I reported something similar on Jan 15, 2021. I just tried again 
>and can fully confirm these messed up file descriptors. My gdb just sits
>there without any output but does quit when I type quit. The file descriptors
>look exactly what Marco posts here for working and non-working version.

P.S. The strange file descriptors start to appear with gdb 7.12.1-2.

>
>>
>>Marco@LAPTOP-82F08ILC /proc/3072/fd
>>i686 $ ls -l
>>total 0
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 0 -> /dev/cons1
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 1 -> /dev/cons1
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 10 -> pipe:[21474850180]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 2 -> /dev/cons1
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 3 -> pipe:[8589948292]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 4 -> pipe:[8589948292]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 5 -> pipe:[12884915588]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 6 -> pipe:[12884915588]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 7 -> pipe:[17179882884]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 8 -> pipe:[17179882884]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 9 -> pipe:[21474850180]
>>
>>and a not working one
>>
>>Marco@LAPTOP-82F08ILC /proc/3055/fd
>>i686 $ ls -l
>>total 0
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 0 -> /dev/cons0
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 1 -> pipe:[4294988268]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 10 -> pipe:[17179890156]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 11 -> pipe:[21474857452]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 12 -> pipe:[21474857452]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 2 -> pipe:[4294988268]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 3 -> pipe:[8589955564]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 4 -> pipe:[8589955564]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 5 -> /dev/cons0
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 6 -> /dev/cons0
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 7 -> pipe:[12884922860]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 8 -> pipe:[12884922860]
>>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 9 -> pipe:[17179890156]
>>
>>it is like the file descriptor of outputs are misaligned,
>>and I see two more of them
>
>Exactly what I see in mintty.
>
>--
>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: Cygwin GDB won't start or hangs at startup

[Lemke, Michael SF/HZA-ZIC2]

On Friday, February 5, 2021 10:08 AM Marco Atzeri wrote:
>On 05.02.2021 08:55, Daniel Röhrborn via Cygwin wrote:
>>> On 04.02.2021 13:13, Daniel Röhrborn via Cygwin wrote:
>
>> 
>> Hi Marco,
>> it seems stacked and when blindly typing "quit" it responds with exiting. So 
>> it seems like the output is invisible.
>> Tested it with Win7_32bit, GDB version 9.2-1 with Cygwin/bin in PATH (since 
>> the beginning).
>> 
>> Regards
>> Daniel
>
>I can not fully replicate on my W10,
>
>but I notice that running from CMD there is a small difference
>between the working instance

Remember I reported something similar on Jan 15, 2021. I just tried again 
and can fully confirm these messed up file descriptors. My gdb just sits
there without any output but does quit when I type quit. The file descriptors
look exactly what Marco posts here for working and non-working version.

>
>Marco@LAPTOP-82F08ILC /proc/3072/fd
>i686 $ ls -l
>total 0
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 0 -> /dev/cons1
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 1 -> /dev/cons1
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 10 -> pipe:[21474850180]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 2 -> /dev/cons1
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 3 -> pipe:[8589948292]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 4 -> pipe:[8589948292]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 5 -> pipe:[12884915588]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 6 -> pipe:[12884915588]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 7 -> pipe:[17179882884]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 8 -> pipe:[17179882884]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:59 9 -> pipe:[21474850180]
>
>and a not working one
>
>Marco@LAPTOP-82F08ILC /proc/3055/fd
>i686 $ ls -l
>total 0
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 0 -> /dev/cons0
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 1 -> pipe:[4294988268]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 10 -> pipe:[17179890156]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 11 -> pipe:[21474857452]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 12 -> pipe:[21474857452]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 2 -> pipe:[4294988268]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 3 -> pipe:[8589955564]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 4 -> pipe:[8589955564]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 5 -> /dev/cons0
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 6 -> /dev/cons0
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 7 -> pipe:[12884922860]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 8 -> pipe:[12884922860]
>lrwxrwxrwx 1 Marco Kein 0 Feb  5 09:57 9 -> pipe:[17179890156]
>
>it is like the file descriptor of outputs are misaligned,
>and I see two more of them

Exactly what I see in mintty.

--
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: Cygwin GDB won't start or hangs at startup

[Lemke, Michael SF/HZA-ZIC2]

On Thursday, February 4, 2021 1:13 PM Daniel Röhrborn wrote:
>I have this issue on three different PCs (Win7_32bit, 2x Win10_64bit) with the 
>latest Cygwin installer.
>I installed Cygwin gcc/g++/gdb. Compiler works but gdb doesn't output anything 
>when started. It seems to have blocked right after start. What could cause 
>this behaviour?
>
>When I downgrade to gdb version 7.10.1-1 it works normally and outputs its 
>startup message.
>But with any higher version (7.12.1-2, 8.0.1-1, 8.1.1-1, 8.2.1-1, 8.3.1-1, 
>9.2-1, 10.1-1) I get no output at all. The process hangs forever. Running GDB 
>from the Cygwin Terminal also doesn't help.
>Since nobody else seems to have similar problems, I think it could be a 
>configuration problem.

I had a similar problem recently. Anything newer than 7.10.1-1 doesn't work for 
me with very similar results as yours. gdb -v doesn't output anything. The 
hypothesis was it is BLODA related but I can't test that. I cannot deactivate 
any McAfee stuff here. I just live with 7.10.1-1 as it is currently good enough 
for my purposes. Check the archive of about two or three weeks ago.
--
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: python sys.executable inconsistency if called from cmd

[Lemke, Michael SF/HZA-ZIC2]

On Wednesday, February 3, 2021 4:28 PM Andrey Repin wrote:
>Greetings, Lemke, Michael  SF/HZA-ZIC2!
>
>> I don't know anything about python but want to use cygwin's
>> python from nodejs npm with node-gyp. The node-gyp module is trying to
>> find the python executable path from sys.executable and fails.
>
>If that's true, then it should be fixed upstream.

Good to know but I doubt that they will. For those who need this -
here is a workaround for node-gyp v5.1.0 I just found:

cygwin> mkdir /c/Python37
cygwin> ln `which python3.6m` /c/Python37/python.exe

I aware of the version clash here but c:\Python37 is one of a
few explicit locations this node-gyp looks at. Doesn't seem
confused if the versions don't match. The file you link to 
must be the actual Cygwin executable not any of the python 
links in /bin.

>
>> While investigating this I found this to me quite inconsistent
>> behavior:
>
>> cygwin> /bin/python3.6m.exe -c 'import sys; print(sys.executable);'
>> /bin/python3.6m
>
>> cygwin> python3.6m -c 'import sys; print(sys.executable);'
>> /usr/bin/python3.6m
>
>> cygwin> python3.6 -c 'import sys; print(sys.executable);'
>> /usr/bin/python3.6
>
>> cygwin> python3.6m.exe -c 'import sys; print(sys.executable);'
>> /usr/bin/python3.6m
>
>
>> cmd> c:/MyStuff/NCygwin64/bin/python3.6m.exe -c 'import sys; 
>> print(sys.executable);'
>> /usr/bin/python3.6m
>
>> cmd> rem add cygwin path to Windows:
>> cmd> path %PATH%;c:\MYSTUFF\ncygwin64\bin
>
>> cmd> python3.6m.exe -c 'import sys; print(sys.executable);'
>> /c/MYSTUFF/ncygwin64/bin/python3.6m
>
>> With CMD I'll never get an executable that actually works from cmd.
>> Is this expected?
>
>Yes. This is Cygwin, not Windows CMD.

Sure but python seems to start just fine under cmd and it does do
some gyrations with sys.executable dependent on calling environment.
So this looks somewhat fishy to me.

>
>> Is there a way around to make this work?
>
>Yes, write scripts correctly, correctly translate paths.

See above.
--
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

python sys.executable inconsistency if called from cmd

[Lemke, Michael SF/HZA-ZIC2]

I don't know anything about python but want to use cygwin's
python from nodejs with npm-gyp. The npm-gyp module is trying to
find the python executable path from sys.executable and fails.
While investigating this I found this to me quite inconsistent
behavior:

cygwin> /bin/python3.6m.exe -c 'import sys; print(sys.executable);'
/bin/python3.6m

cygwin> python3.6m -c 'import sys; print(sys.executable);'
/usr/bin/python3.6m

cygwin> python3.6 -c 'import sys; print(sys.executable);'
/usr/bin/python3.6

cygwin> python3.6m.exe -c 'import sys; print(sys.executable);'
/usr/bin/python3.6m


cmd> c:/MyStuff/NCygwin64/bin/python3.6m.exe -c 'import sys; 
print(sys.executable);'
/usr/bin/python3.6m

cmd> rem add cygwin path to Windows:
cmd> path %PATH%;c:\MYSTUFF\ncygwin64\bin

cmd> python3.6m.exe -c 'import sys; print(sys.executable);'
/c/MYSTUFF/ncygwin64/bin/python3.6m

With CMD I'll never get an executable that actually works from cmd.
Is this expected? Is there a way around to make this work?
--
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: Random assembler errors after update mingw64-x86_64-binutils-2.35.2-1

[Michael Soegtrop via Cygwin]

An update on this:

I reverted to the previous version of MinGW 64 binutils in our CI and 
didn't have issues since then.


Best regards,

Michael

Am 01/02/2021 um 10:25 schrieb Michael Soegtrop:

Hi Achim,

I have some evidence that this update leads to random assembler 
errors. I have 3 CI failures (out of 5 runs) since the update in an 
open source project I maintain. The failure is always an error from 
the MinGW 64 assembler and the errors are random - that is if I rerun 
the same CI test the error went away in one of one tested case and in 
the failing cases the error happened compiling different files.


I haven't seen anything like this before the update.

Here are links to one failing and one good case:

Fail run package version:
https://github.com/coq/platform/runs/1803203762?check_suite_focus=true#step:4:164 



Fail run error message:
https://github.com/coq/platform/runs/1803203762?check_suite_focus=true#step:4:1664 



Good run package version:
https://github.com/coq/platform/runs/1799374171?check_suite_focus=true#step:4:164 



I will revert to the old version of the package and see if the errors 
go away.


The 32 bit version seems fine do far.

Best regards,

Michael

--
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

Random assembler errors after update mingw64-x86_64-binutils-2.35.2-1

[Michael Soegtrop via Cygwin]

Hi Achim,

I have some evidence that this update leads to random assembler errors. 
I have 3 CI failures (out of 5 runs) since the update in an open source 
project I maintain. The failure is always an error from the MinGW 64 
assembler and the errors are random - that is if I rerun the same CI 
test the error went away in one of one tested case and in the failing 
cases the error happened compiling different files.


I haven't seen anything like this before the update.

Here are links to one failing and one good case:

Fail run package version:
https://github.com/coq/platform/runs/1803203762?check_suite_focus=true#step:4:164

Fail run error message:
https://github.com/coq/platform/runs/1803203762?check_suite_focus=true#step:4:1664

Good run package version:
https://github.com/coq/platform/runs/1799374171?check_suite_focus=true#step:4:164

I will revert to the old version of the package and see if the errors go 
away.


The 32 bit version seems fine do far.

Best regards,

Michael
--
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: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

On 30/01/2021 16:00, Ken Brown wrote:

On 9/28/2020 7:03 AM, Michael McMahon wrote:



On 26/09/2020 08:30, Michael McMahon via Cygwin wrote:



On 25/09/2020 21:30, Ken Brown wrote:

On 9/25/2020 2:50 PM, Ken Brown via Cygwin wrote:

On 9/25/2020 10:29 AM, Michael McMahon wrote:



On 25/09/2020 14:19, Ken Brown wrote:

On 9/24/2020 8:01 AM, Michael McMahon wrote:



On 24/09/2020 12:26, Ken Brown wrote:

On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote:

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain
sockets (a recent feature in Windows 10 and 2019 server) and
Cygwin. I think I possibly know the cause since I had to
investigate a similar looking issue on another platform built
on Windows.

The problem is that cygwin commands don't seem to recognise
native Unix domain sockets correctly. For example, the socket
"foo.sock" should have the same ownership and similar
permissions to other files in the example below:

$ ls -lrt total 2181303

-rw-r--r--  1 mimcmah  None 1259   Sep 23
10:22 test.c -rwxr-xr-x  1 mimcmah None 3680
Sep 23 10:22 test.obj -rwxr-xr-x  1 mimcmah None
121344 Sep 23 10:22 test.exe -rw-r-  1 Unknown+User
Unknown+Group 0 Sep 23 10:23 foo.sock -rw-r--r--  1
mimcmah  None 144356 Sep 23 10:27 check.ot

A bigger problem is that foo.sock can't be deleted with the
cygwin "rm" command.

$ rm -f foo.sock rm: cannot remove 'foo.sock': Permission
denied

$ chmod 777 foo.sock chmod: changing permissions of
'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example
shows.

I think the problem may relate to the way native Unix domain
sockets are implemented in Windows and the resulting special
handling required. They are implemented as NTFS reparse
points and when opening them with CreateFile, you need to
specify the FILE_FLAG_OPEN_REPARSE_POINT flag. Otherwise, you
get an ERROR_CANT_ACCESS_FILE. There are other complications
unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code
snippet which creates foo.sock in the current directory.
Obviously, this only works on recent versions of Windows 10
and 2019 server.


Cygwin doesn't currently support native Windows AF_UNIX
sockets, as you've discovered.  See

https://urldefense.com/v3/__https://cygwin.com/pipermail/cygwin/2020-June/245088.html__;!!GqivPVa7Brio!P7lIFI4rYAtWh8_DtCbRCxT-M_E4vwQ0qwzQ0p656T73BpJ0jbUkLI_bXdA6mmSL9lJcSQ$ 




for the current state of AF_UNIX sockets on Cygwin, including
the possibility of using native Windows AF_UNIX sockets on
systems that support them.

If all you want is for Cygwin to recognize such sockets and
allow you to apply rm, chmod, etc., I don't think it would be
hard to add that capability.  But I doubt if that's all you
want.

Further discussion of this will have to wait until Corinna is
available.



Thanks for the info. It's mainly about recognition of sockets
for regular commands. Since these objects can exist on Windows
filesystems now, potentially created by any kind of Windows
application, it would be great if Cygwin could handle them,
irrespective of whether the Cygwin development environment does.
Though that sounds like a good idea too.


I think this has a simple fix (attached), but I can't easily test
it because your test program doesn't compile for me. First, I got

$ gcc -o native_unix_socket native_unix_socket.c 
native_unix_socket.c:5:10: fatal error: WS2tcpip.h: No such file or
directory 5 | #include  | ^~~~ compilation 
terminated.


I fixed this by making the include file name lower case.  (My
system is case sensitive, so it matters.)

Next:

$ gcc -o native_unix_socket native_unix_socket.c 
native_unix_socket.c:8:10: fatal error: afunix.h: No such file or

directory 8 | #include  | ^~ compilation
terminated.

There's no file afunix.h in the Cygwin distribution, but I located
it online and pasted in the contents.  The program now compiles but
fails to link:

$ gcc -o native_unix_socket native_unix_socket.c 
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 


 /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): undefined
reference to `__imp_WSAStartup' 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): relocation

truncated to fit: R_X86_64_PC32 against undefined symbol
`__imp_WSAStartup' 
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 


 /tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): undefined
reference to `__imp_WSAGetLastError' 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): relocation

truncated to fit: R_X86_64_PC32 against undefined symbol
`__imp_WSAGetLastError' 
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 


 /tmp/cc74urPr.o:native_unix_s

Re: tar 1.33 symlinks : Cannot change mode to...

[Michael Soegtrop]

have you tried the Cygwin snapshot as suggested in:

https://sourceware.org/pipermail/cygwin/2021-January/247418.html


The snapshot is hard to use in headless CI systems because the provided 
archive contains a cygwin dll, so it cannot be patched from within 
cygwin and my experience with doing such things in PowerShell is limited.


Instead I am now restoring the old version using:

wget 
http://mirrors.kernel.org/sourceware/cygwin/x86/release/tar/tar-1.32-2.tar.xz 
-O /tmp/tar-1.32-2.tar.xz

tar xvf /tmp/tar-1.32-2.tar.xz -C /

which can be run from the cygwin console to restore the previous tar 
after cygwin setup.


I will try the snapshot later locally.

Best regards,

Michael
--
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: tar 1.33 symlinks : Cannot change mode to...

[Michael Soegtrop]

Hi Marco,


have you tried the Cygwin snapshot as suggested in:

https://sourceware.org/pipermail/cygwin/2021-January/247418.html


sorry, I somehow missed this message. I will try this and report if it 
works.


Thanks!

Best regards,

Michael
--
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: tar 1.33 symlinks : Cannot change mode to...

[Michael Soegtrop via Cygwin]

Dear Cygwin Team,

is there an update on this? Apparently tar is broken on Cygwin 32 since 
the latest update (it works fine on 64 bit Cygwin) and afaik there is no 
way to install specific package versions from the command line as would 
be possible via the Setup UI, so I can't easily roll back to the 
previous version of tar. IMHO this is a very severe issue - tar is 
ubiquitous.


Best regards,

Michael
--
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: GLX and libX11

[Michael Enright]

On Sun, Jan 24, 2021 at 5:38 AM Marco Atzeri via Cygwin
 wrote:
>
>
> Have you started the program from inside a XTerm  with a running
> XServer ?
>

I compiled and ran the program in a mintty window, while X server was
started and the environment variable DISPLAY was set. It ran
perfectly. I don't have XTerm installed, it would probably have taken
care of the DISPLAY variable.

I started a second mintty window and started the program from there
without setting DISPLAY, and the program complained "cannot connect to
X server".

I think Rafał started the program from a shell which had DISPLAY set,
but @Rafał if you could confirm that it would help a bit. I think some
Cygwin X components may be missing. The reason I think this is the
message that says the Windows DRI extension is missing, which I guess
is awfully specific.

It occurs to me that starting XTerm would be a useful diagnostic, but
if "Windows DRI" is missing, XServer probably can't start, never mind
"Windows DRI extension"
--
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 not working

[Lemke, Michael SF/HZA-ZIC2]

On Monday, January 18, 2021 6:42 PM Ken Brown wrote:
>On 1/18/2021 12:35 PM, Lemke, Michael SF/HZA-ZIC2 wrote:
>> On Monday, January 18, 2021 5:53 PM Ken Brown wrote:
>>> I was asking for the strace output.  It might just show the same DLL loading
>>> issues that Marco noticed, or it might show something more.
>>>
>> 
>> Ok, here are the first 100 lines, the whole thing is over 2MB. To me this
>> looks strange already (cygstdc++-6.dll).
>[...]
>> --- Process 32204 loaded C:\Program Files\Common 
>> Files\McAfee\SystemCore\mfehcthe.dll at 52b5
>> --- Process 32204 loaded C:\Program Files\McAfee\Endpoint Security\Adaptive 
>> Threat Protection\mfedeeprem64.dll at 7fffcc70
>
>This could be the culprit.  Can you exclude your Cygwin directory from McAfee?

Unfortunately not. It is managed centrally. But then good to know I can't use 
gdb here. I feel safe now...

Thanks for all your help.

Michael
--
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 not working

[Lemke, Michael SF/HZA-ZIC2]

On Monday, January 18, 2021 5:53 PM Ken Brown wrote:
>
>[Resending.  Accidentally sent to OP instead of list.]

{Happens here too. Reply All or Reply (in Outlook) both send to OP instead of 
list.]

>
>On 1/18/2021 8:08 AM, Lemke, Michael SF/HZA-ZIC2 wrote:
>> On Friday, January 15, 2021 9:02 PM Ken Brown wrote:
>>> On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote:
>>>> On Friday, January 15, 2021 4:45 PM Jon Turney wrote:
>>>>> On 15/01/2021 12:28, Lemke, Michael wrote:
>>>>>> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
>>>>>> However, gdb does not produce any output.
>>>>>>
>>>>>> Installing gdb versions 7.9.1-1 and 7.10.1-1 work, anything newer 
>>>>>> doesn't.
>>>>>> Any ideas why?
>>>>> [...]
>>>>>
>>>>>> Install gdb 7.12.1-2
>>>>>> pc> gdb -v
>>>>>> Install gdb 8.0.1-1
>>>>>> pc> gdb -v
>>>>>> pc> cygcheck -c gdb
>>>>>> Cygwin Package Information
>>>>>> Package  VersionStatus
>>>>>> gdb  8.0.1-1OK
>>>>>
>>>>> You might try 'strace gdb' and see if that sheds any light on what's
>>>>> failing.
>>>>
>>>> I tried that but I couldn't see anything strange.
>>>
>>> No error code?  Please show the output.
>> 
>>   pc> gdb -v
>>   pc> echo $?
>> 0
>
>I was asking for the strace output.  It might just show the same DLL loading 
>issues that Marco noticed, or it might show something more.
>

Ok, here are the first 100 lines, the whole thing is over 2MB. To me this
looks strange already (cygstdc++-6.dll).

--- Process 32204 created
--- Process 32204 loaded C:\Windows\System32\ntdll.dll at 7fffde2c
--- Process 32204 loaded C:\Windows\System32\kernel32.dll at 7fffdce4
--- Process 32204 loaded C:\Windows\System32\KernelBase.dll at 7fffdb57
--- Process 32204 thread 13420 created
--- Process 32204 thread 32700 created
--- Process 32204 thread 25220 created
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygwin1.dll at 
00018004
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygintl-8.dll at 
0003fbff
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygiconv-2.dll at 
0003fe77
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygncursesw-10.dll at 
0003fbd7
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygexpat-1.dll at 
0003fe90
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cyglzma-5.dll at 
0003f9e6
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygmpfr-6.dll at 
0003f9aa
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygz.dll at 0003f7b0
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\libpython3.6m.dll at 
0003f75c
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygreadline7.dll at 
0003f8dc
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cyggcc_s-seh-1.dll at 
0003fdf6
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygsource-highlight-4.dll at 
0003f896
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygstdc++-6.dll at 
0003f853
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cyggmp-10.dll at 
0003fd72
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygboost_regex-1_66.dll at 
0003ff52
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygstdc++-6.dll at 
034d
--- Process 32204 unloaded DLL at 034d
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicui18n61.dll at 
0003fc22
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicuuc61.dll at 
0003fc08
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicudata61.dll at 
0003fa3c
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicuuc61.dll at 
034d
--- Process 32204 unloaded DLL at 034d
3   3 [main] gdb (32204) **
  654 657 [main] gdb (32204) Program name: C:\MyStuff\NCygwin64\bin\gdb.exe 
(windows pid 32204)
  180 837 [main] gdb (32204) OS version:   Windows NT-10.0
  141 978 [main] gdb (32204) **
--- Process 32204 loaded C:\Windows\System32\advapi32.dll at 7fffdd70
--- Process 32204 loaded C:\Windows\System32\msvcrt.dll at 7fffdc5a
--- Process 32204 loaded C:\Windows\System32\sechost.dll at 7fffdc6f
--- Process 32204 loaded C:\Windows\System32\rpcrt4.dll at 7fffdd7b
--- Process 32204 loaded C:\Windows\System32\cryptbase.dll at 7fffdab8
--- Process 32204 loaded C:\Windows\System32\bcryptpr

RE: gdb not working

[Lemke, Michael SF/HZA-ZIC2]

On Monday, January 18, 2021 2:54 PM Lemke, Michael SF/HZA-ZIC2 wrote:
>On Monday, January 18, 2021 2:23 PM Marco Atzeri wrote:
>On 18.01.2021 14:08, Lemke, Michael SF/HZA-ZIC2 wrote:
>> On Friday, January 15, 2021 9:02 PM Ken Brown wrote:
>>> On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote:
>>>> On Friday, January 15, 2021 4:45 PM Jon Turney wrote:
>>>>> On 15/01/2021 12:28, Lemke, Michael wrote:
>>>>>> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
>>>>>> However, gdb does not produce any output.
>>>>>>
>> 
>>>
>>>> Also ldd `which gdb` is
>>>> fine.
>>>
>>> Please show the output.
>> 
>> pc> ldd `which gdb`
>
>>  cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
>>  cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884)
>
>>  cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17)
>this is very low 
>>  cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360)
>
>>  cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24)
>>  cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360)
>
>
>I do not see duplicate entries on my system. it seems a BLODA
>is interfering with dll's loading
>

It might very well be. I also noticed the output of ldd is not reproducible.
It shows different duplicate entries when run repeatedly and the load 
address you marked is also a duplicate:

 pc> ldd `which gdb`|grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0xa)

Hm, is gdb dependent on gcc? I just noticed my gcc is apparently broken:
 pc> cygcheck -c gcc
Cygwin Package Information
Package  VersionStatus
 pc>


P.S.:
 pc> cygcheck -c gcc
Cygwin Package Information
Package  VersionStatus
 pc> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/10/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0/configure 
--srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0 --prefix=/usr 
--exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc 
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C 
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin 
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib 
--with-gcc-major-version-only --enable-shared --enable-shared-libgcc 
--enable-static --enable-version-specific-runtime-libs --enable-bootstrap 
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic 
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite 
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath 
--enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers 
--with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl 
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-l
 inker-build-id --with-default-libstdcxx-abi=gcc4-compatible 
--enable-libstdcxx-filesystem-ts
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

And I can compile C programs.
--
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 not working

[Lemke, Michael SF/HZA-ZIC2]

On Monday, January 18, 2021 2:23 PM Marco Atzeri wrote:
>On 18.01.2021 14:08, Lemke, Michael SF/HZA-ZIC2 wrote:
>> On Friday, January 15, 2021 9:02 PM Ken Brown wrote:
>>> On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote:
>>>> On Friday, January 15, 2021 4:45 PM Jon Turney wrote:
>>>>> On 15/01/2021 12:28, Lemke, Michael wrote:
>>>>>> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
>>>>>> However, gdb does not produce any output.
>>>>>>
>> 
>>>
>>>> Also ldd `which gdb` is
>>>> fine.
>>>
>>> Please show the output.
>> 
>> pc> ldd `which gdb`
>
>>  cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
>>  cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884)
>
>>  cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17)
>this is very low 
>>  cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360)
>
>>  cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24)
>>  cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360)
>
>
>I do not see duplicate entries on my system. it seems a BLODA
>is interfering with dll's loading
>

It might very well be. I also noticed the output of ldd is not reproducible.
It shows different duplicate entries when run repeatedly and the load 
address you marked is also a duplicate:

 pc> ldd `which gdb`|grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
 pc> ldd `which gdb` | grep --color gcc
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0xa)

Hm, is gdb dependent on gcc? I just noticed my gcc is apparently broken:
 pc> cygcheck -c gcc
Cygwin Package Information
Package  VersionStatus
 pc>

Other than going through the published BLODA list is there a way I could
test and find out what is interfering? I ask because we have a lot of 
stuff installed for teleworking, especially on the network side.
--
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 not working

[Lemke, Michael SF/HZA-ZIC2]

On Friday, January 15, 2021 9:02 PM Ken Brown wrote:
>On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote:
>> On Friday, January 15, 2021 4:45 PM Jon Turney wrote:
>>> On 15/01/2021 12:28, Lemke, Michael wrote:
>>>> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
>>>> However, gdb does not produce any output.
>>>>
>>>> Installing gdb versions 7.9.1-1 and 7.10.1-1 work, anything newer doesn't.
>>>> Any ideas why?
>>> [...]
>>>
>>>> Install gdb 7.12.1-2
>>>>pc> gdb -v
>>>> Install gdb 8.0.1-1
>>>>pc> gdb -v
>>>>pc> cygcheck -c gdb
>>>> Cygwin Package Information
>>>> Package  VersionStatus
>>>> gdb  8.0.1-1OK
>>>
>>> You might try 'strace gdb' and see if that sheds any light on what's
>>> failing.
>> 
>> I tried that but I couldn't see anything strange.
>
>No error code?  Please show the output.

 pc> gdb -v
 pc> echo $?
0

>
>> Also ldd `which gdb` is
>> fine.
>
>Please show the output.

pc> ldd `which gdb`
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffde2c)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffdce4)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fffdb57)
cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x3fe90)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3fc1b)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3fe77)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
cygmpfr-6.dll => /usr/bin/cygmpfr-6.dll (0x3f9db)
cyglzma-5.dll => /usr/bin/cyglzma-5.dll (0x3fa16)
libpython3.6m.dll => /usr/bin/libpython3.6m.dll (0x3f78d)
cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x3fbd7)
cygreadline7.dll => /usr/bin/cygreadline7.dll (0x3f90d)
cygz.dll => /usr/bin/cygz.dll (0x3f7e1)
cygsource-highlight-4.dll => /usr/bin/cygsource-highlight-4.dll 
(0x3f8c7)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6)
cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884)
cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3fd8e)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17)
cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360)
cygboost_regex-1_66.dll => /usr/bin/cygboost_regex-1_66.dll 
(0x3ff52)
cygicui18n61.dll => /usr/bin/cygicui18n61.dll (0x3fc3e)
cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24)
cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360)
cygicudata61.dll => /usr/bin/cygicudata61.dll (0x3fa3c)

>
>> I tried the cygcheck Marco Atzeri suggested. I am not comfortable to send
>> the result to the list but I checked it.
>
>Can you remove the sensitive parts and then send it?  It's hard for anyone on 
>the list to help you if you don't provide information about your installation.

I'll see what I can do.

>
>> As a result I cleaned up my path to just /bin which removed some duplicate
>> entries in cygcheck.out but gdb still doesn't work.
>> 
>> The only strange part I see in cygcheck.out is a slight mess up with my
>> installation, a result of my moving /c/cygwin64 to /c/mystuff/ncygwin64
>> after my first run of setup.exe, see below.  So what has changed between
>> gdb 7.10.1-1 and gdb 7.12.1-2?
>
>Dependencies may have changed.  Have you checked that you have all 
>dependencies 
>of whatever version you're trying to run?  Just re-running setup should take 
>care of that if that's the problem.

I've always installed every version with setup so the dependencies should have
been taken care of. And

 pc> cygcheck -c gdb
Cygwin Package Information
Package  VersionStatus
gdb  9.2-1  OK

And one more:
 pc> gdb -v >& blah
 pc> cat blah
 pc>

i.e. empty file blah.
--
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 not working

[Lemke, Michael SF/HZA-ZIC2]

On Friday, January 15, 2021 4:45 PM Jon Turney wrote:
>On 15/01/2021 12:28, Lemke, Michael wrote:
>> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
>> However, gdb does not produce any output.
>> 
>> Installing gdb versions 7.9.1-1 and 7.10.1-1 work, anything newer doesn't.
>> Any ideas why?
>[...]
>
>> Install gdb 7.12.1-2
>>   pc> gdb -v
>> Install gdb 8.0.1-1
>>   pc> gdb -v
>>   pc> cygcheck -c gdb
>> Cygwin Package Information
>> Package  VersionStatus
>> gdb  8.0.1-1OK
>
>You might try 'strace gdb' and see if that sheds any light on what's 
>failing.

I tried that but I couldn't see anything strange. Also ldd `which gdb` is
fine.

I tried the cygcheck Marco Atzeri suggested. I am not comfortable to send
the result to the list but I checked it.

As a result I cleaned up my path to just /bin which removed some duplicate
entries in cygcheck.out but gdb still doesn't work.

The only strange part I see in cygcheck.out is a slight mess up with my
installation, a result of my moving /c/cygwin64 to /c/mystuff/ncygwin64
after my first run of setup.exe, see below.  So what has changed between 
gdb 7.10.1-1 and gdb 7.12.1-2? 

Excerpt from cygcheck.out:

HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
  (default) = '\??\C:\cygwin64'
  d5bac59bf2204d69 = '\??\C:\MyStuff\NCygwin64'
  c0a8879476f177eb = '\??\C:\MyStuff\NCygwin'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
  (default) = '\??\C:\cygwin64'
  d5bac59bf2204d69 = '\??\C:\MyStuff\NCygwin64'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'C:\MyStuff\NCygwin64'

obcaseinsensitive set to 1

Cygwin installations found in the registry:
  System: Key: e022582115c10879 Path: C:\cygwin64 (ORPHANED)
  System: Key: d5bac59bf2204d69 Path: C:\MyStuff\NCygwin64
  User:   Key: e022582115c10879 Path: C:\cygwin64 (ORPHANED)
  User:   Key: d5bac59bf2204d69 Path: C:\MyStuff\NCygwin64
  User:   Key: c0a8879476f177eb Path: C:\MyStuff\NCygwin

c:  hd  NTFS486732Mb  27% CP CS UN PA FCQU  Windows
u:  net NTFS   4300668Mb  91% CP CS UN PA FCQU  USERS-10

C:\MyStuff\NCygwin\home   /home userbinary
C:\MyStuff\NCygwin64  / system  binary,auto
C:\MyStuff\NCygwin64\bin  /usr/bin  system  binary,auto
C:\MyStuff\NCygwin64\lib  /usr/lib  system  binary,auto
cygdrive prefix   / userbinary,posix=0,auto

Found: C:\MyStuff\NCygwin64\bin\awk
 -> C:\MyStuff\NCygwin64\bin\gawk.exe
Found: C:\MyStuff\NCygwin64\bin\bash.exe
Found: C:\MyStuff\NCygwin64\bin\cat.exe
Not Found: certutil
Not Found: clinfo
Not Found: comp
Found: C:\MyStuff\NCygwin64\bin\convert
 -> C:\MyStuff\NCygwin64\bin\magick.exe
Found: C:\MyStuff\NCygwin64\bin\cp.exe
Found: C:\MyStuff\NCygwin64\bin\cpp.exe
Not Found: crontab
Found: C:\MyStuff\NCygwin64\bin\curl.exe
Found: C:\MyStuff\NCygwin64\bin\expand.exe
Found: C:\MyStuff\NCygwin64\bin\find.exe
Found: C:\MyStuff\NCygwin64\bin\ftp.exe
Found: C:\MyStuff\NCygwin64\bin\gcc.exe
Found: C:\MyStuff\NCygwin64\bin\gdb.exe
Found: C:\MyStuff\NCygwin64\bin\grep.exe
Found: C:\MyStuff\NCygwin64\bin\hostname.exe
Found: C:\MyStuff\NCygwin64\bin\kill.exe
Not Found: klist
Found: C:\MyStuff\NCygwin64\bin\ld.exe
Found: C:\MyStuff\NCygwin64\bin\ls.exe
Found: C:\MyStuff\NCygwin64\bin\make.exe
Found: C:\MyStuff\NCygwin64\bin\mv.exe
Not Found: nslookup
Not Found: patch
Found: C:\MyStuff\NCygwin64\bin\perl.exe
Not Found: replace
Found: C:\MyStuff\NCygwin64\bin\rm.exe
Found: C:\MyStuff\NCygwin64\bin\sed.exe
Found: C:\MyStuff\NCygwin64\bin\sh.exe
Not Found: shutdown
Found: C:\MyStuff\NCygwin64\bin\sort.exe
Found: C:\MyStuff\NCygwin64\bin\ssh.exe
Found: C:\MyStuff\NCygwin64\bin\tar.exe
Found: C:\MyStuff\NCygwin64\bin\test.exe
Found: C:\MyStuff\NCygwin64\bin\timeout.exe
Found: C:\MyStuff\NCygwin64\bin\vi.exe
Found: C:\MyStuff\NCygwin64\bin\vim.exe
Found: C:\MyStuff\NCygwin64\bin\whoami.exe
--
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 not working

[Lemke, Michael SF/HZA-ZIC2]

I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
However, gdb does not produce any output.

Installing gdb versions 7.9.1-1 and 7.10.1-1 work, anything newer doesn't.
Any ideas why?

pc> gdb -v
GNU gdb (GDB) Cygwin 7.9.1-1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".

Install gdb 7.10.1-1
 pc> gdb -v
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".

Install gdb 7.12.1-2
 pc> gdb -v
Install gdb 8.0.1-1
 pc> gdb -v
 pc> cygcheck -c gdb
Cygwin Package Information
Package  VersionStatus
gdb  8.0.1-1OK
 pc> uname -a
CYGWIN_NT-10.0 pc 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin

--
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: Package "python" removed from default package selection

[Michael Soegtrop via Cygwin]

Dear Cygwin Team,

sorry - I was too quick. Actually the packages are the other way around:

New is:

python python-2.7.18-1.tar.bz2 0
python-pip-wheel python-pip-wheel-19.2.3-1.tar.bz2 0
python-setuptools-wheel python-setuptools-wheel-41.2.0-1.tar.bz2 0
python2 python2-2.7.18-2.tar.bz2 0
python27 python27-2.7.18-2.tar.bz2 0
python27-pip python27-pip-20.2.2-1.tar.bz2 0
python27-setuptools python27-setuptools-41.2.0-1.tar.bz2 0
python3 python3-3.8.6-1.tar.bz2 0
python36 python36-3.6.10-1.tar.bz2 0
python38 python38-3.8.3-1.tar.bz2 0

$ which python
which: no python in 
(/build/bin_special:/usr/local/bin:/usr/bin:/usr/x86_64-w64-mingw32/sys-root/mingw/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/usr/i686-pc-cygwin/sys-root/usr/bin)


Old is:

python-pip-wheel python-pip-wheel-19.2.3-1.tar.bz2 0
python-setuptools-wheel python-setuptools-wheel-41.2.0-1.tar.bz2 0
python2 python2-2.7.18-1.tar.bz2 0
python27 python27-2.7.18-1.tar.bz2 0
python3 python3-3.6.8-1.tar.bz2 0
python36 python36-3.6.10-1.tar.bz2 0

$ which python
/usr/bin/python

So I don't see an easy fix for this - short of creating the symlink 
manually.


Best regards,

Michael

--
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

Package "python" removed from default package selection

[Michael Soegtrop via Cygwin]

Dear Cygwin Team,

as far as I can tell the package "python" which drags in some python and 
creates a symlink like


/usr/bin/python -> python2.7.exe

has been removed recently (in the last 3 days or so) from the default 
package selection. This has the effect that calls to just "python" fail. 
Is this an intended change? I didn't see an announcement for this change 
here.


I hope, I can easily fix this by installing the package manually ...

Bets regards,

Michael

Package selection a few days ago (with no python package explicitly 
selected):


python python-2.7.18-1.tar.bz2 0
python-pip-wheel python-pip-wheel-19.2.3-1.tar.bz2 0
python-setuptools-wheel python-setuptools-wheel-41.2.0-1.tar.bz2 0
python2 python2-2.7.18-2.tar.bz2 0
python27 python27-2.7.18-2.tar.bz2 0
python27-pip python27-pip-20.2.2-1.tar.bz2 0
python27-setuptools python27-setuptools-41.2.0-1.tar.bz2 0
python3 python3-3.8.6-1.tar.bz2 0
python36 python36-3.6.10-1.tar.bz2 0
python38 python38-3.8.3-1.tar.bz2 0

Package selection today:

python-pip-wheel python-pip-wheel-19.2.3-1.tar.bz2 0
python-setuptools-wheel python-setuptools-wheel-41.2.0-1.tar.bz2 0
python2 python2-2.7.18-1.tar.bz2 0
python27 python27-2.7.18-1.tar.bz2 0
python3 python3-3.6.8-1.tar.bz2 0
python36 python36-3.6.10-1.tar.bz2 0
--
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: Strange paths in NTFS reparse points created by Cygwin Setup for e.g. TTF fonts

[Michael Soegtrop via Cygwin]

Hi Ken, L A Walsh,

> But you can change this if you don't like it, as I said in my reply 
to your earlier message about this:


I don't know if I like it yet - I am still in the process of 
understanding what is going on.


I maintain the Windows build of a large open source project and we also 
deliver scripts to setup cygwin on our user's machines. I need to 
understand what is going on before I make changes to settings. I am 
afraid that using non standard settings in the end will lead to more 
confusion than good - especially if people have several cygwin 
installations. Also I need to be able to support our users in case they 
have issues with this.


The interesting point is that in our CI we do several 100 cygwin 
installations (sometimes more than 1000) per month. For 95%..99% the 
removal with "rm -rf" from another cygwin installation works well, in 
about 1%..5% of the case about 250 symlinks / reparse points remain. 
This happens all on the same machines with identical scripts.


With my manual installations of cygwin it is about the same ratio. I had 
two cases where removing a cygwin installation from Windows explorer 
with "shift+delete" did not work cause of these about 250 symlinks - I 
would say I did roughly 100 installations in this time frame.


What I don't understand is why it does work sometimes and sometimes not. 
I always use the same scripts to install and remove cygwin on the same 
machines and then do pretty much the same thing with this cygwin (build 
our open source software) before I delete it.


It is unlikely that the issue is that the target files are open as L A 
Welsh suggested because always either all symlinks or none at all 
remain. The number is always the same (with recent versions afair 258).


@ L A Walsh: you wrote "1) if you try to delete the file in cygwin"

Why shouldn't I be able to remove symlinks with rm -rf from within a 
cygwin? As far as I understand the standard behavior of "rm" is to 
remove the symlink and not its target. What I do when I remove a cygwin 
installation in our CI is an "rm -rf" from a different cygwin 
installation. As I said in most cases this works but rarely it doesn't.


In case it doesn't work the symlinks are quite hard to get rid of. 
FSUTIL REPARSEPOINT DELETE is the only method which works I found so 
far. Even after a reboot, resetting the ACLs in various ways, ... no 
usual method to remove these files works.


I understand that the contents / path of the symlink is as expected, so 
I am looking out for other oddities which could explain this behavior.


Best regards,

Michael

--
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

Strange paths in NTFS reparse points created by Cygwin Setup for e.g. TTF fonts

[Michael Soegtrop via Cygwin]

Dear Cyhwin Users and Team,

since a while I have issues removing cygwin installations, especially 
the symlinks to true type fonts in /usr/share/fonts/microsoft.


Looking at these links with Windows tools I get:

C:\bin\cygwin\usr\share\fonts\microsoft>fsutil reparsepoint query 
wingding.ttf

Reparse Tag Value : 0xa01d
Tag value: Microsoft
Tag value: Name Surrogate

Reparse Data Length: 0x0025
Reparse Data:
:  02 00 00 00 2f 6d 6e 74  2f 63 2f 57 69 6e 64 6f  /mnt/c/Windo
0010:  77 73 2f 46 6f 6e 74 73  2f 77 69 6e 67 64 69 6e  ws/Fonts/wingdin
0020:  67 2e 74 74 66g.ttf

I wonder if the path "/mnt/c/Windows/Fonts/wingding.ttf" is something 
which should be written into a NTFS reparse point by cygwin setup. 
Probably not - it looks like a cygwin path and it is understandable that 
this confuses NTFS.




Btw.: I meanwhile managed to reliably remove cygwin install folders with 
the below command sequence ($1 being the cygwin folder name) - sorry an 
ugly mix of bash and DOS tools:



PATH_WINFMT="$(cygpath -w -a $1)"

rm -rf "$1" && { echo "first removal run successful"; exit; }

TAKEOWN /F "$PATH_WINFMT" /R /D Y

ICACLS "$PATH_WINFMT" /grant :F /T

CMD /C "DIR /AL /S /B $PATH_WINFMT" | sed 's|\\||g' | tr -d "\r" | 
while read f; do echo removing reparsepoint "$f"; FSUTIL REPARSEPOINT 
DELETE "$f"; done


rm -rfv "$1"


Best regards,

Michael
--
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: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

On 26/09/2020 08:30, Michael McMahon via Cygwin wrote:



On 25/09/2020 21:30, Ken Brown wrote:

On 9/25/2020 2:50 PM, Ken Brown via Cygwin wrote:

On 9/25/2020 10:29 AM, Michael McMahon wrote:



On 25/09/2020 14:19, Ken Brown wrote:

On 9/24/2020 8:01 AM, Michael McMahon wrote:



On 24/09/2020 12:26, Ken Brown wrote:

On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote:

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain sockets
(a recent feature in Windows 10 and 2019 server) and Cygwin.
I think I possibly know the cause since I had to investigate a 
similar

looking issue on another platform built on Windows.

The problem is that cygwin commands don't seem to recognise 
native Unix

domain sockets correctly. For example, the socket "foo.sock" should
have the same ownership and similar permissions to other files
in the example below:

$ ls -lrt
total 2181303

-rw-r--r--  1 mimcmah  None 1259   Sep 23 10:22 
test.c
-rwxr-xr-x  1 mimcmah  None 3680   Sep 23 10:22 
test.obj
-rwxr-xr-x  1 mimcmah  None 121344 Sep 23 10:22 
test.exe
-rw-r-  1 Unknown+User Unknown+Group 0 Sep 23 10:23 
foo.sock
-rw-r--r--  1 mimcmah  None 144356 Sep 23 10:27 
check.ot


A bigger problem is that foo.sock can't be deleted with the 
cygwin "rm"

command.

$ rm -f foo.sock
rm: cannot remove 'foo.sock': Permission denied

$ chmod 777 foo.sock
chmod: changing permissions of 'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example shows.

I think the problem may relate to the way native Unix domain 
sockets are

implemented in Windows and the resulting special handling required.
They are implemented as NTFS reparse points and when opening them
with CreateFile, you need to specify the 
FILE_FLAG_OPEN_REPARSE_POINT

flag. Otherwise, you get an ERROR_CANT_ACCESS_FILE. There are other
complications unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code snippet
which creates foo.sock in the current directory. Obviously, this
only works on recent versions of Windows 10 and 2019 server.


Cygwin doesn't currently support native Windows AF_UNIX sockets, 
as you've discovered.  See


https://urldefense.com/v3/__https://cygwin.com/pipermail/cygwin/2020-June/245088.html__;!!GqivPVa7Brio!P7lIFI4rYAtWh8_DtCbRCxT-M_E4vwQ0qwzQ0p656T73BpJ0jbUkLI_bXdA6mmSL9lJcSQ$ 

for the current state of AF_UNIX sockets on Cygwin, including the 
possibility of using native Windows AF_UNIX sockets on systems 
that support them.


If all you want is for Cygwin to recognize such sockets and allow 
you to apply rm, chmod, etc., I don't think it would be hard to 
add that capability.  But I doubt if that's all you want.


Further discussion of this will have to wait until Corinna is 
available.




Thanks for the info. It's mainly about recognition of sockets for
regular commands. Since these objects can exist on Windows 
filesystems

now, potentially created by any kind of Windows application,
it would be great if Cygwin could handle them, irrespective of 
whether

the Cygwin development environment does. Though that sounds like a
good idea too.


I think this has a simple fix (attached), but I can't easily test 
it because your test program doesn't compile for me.  First, I got


$ gcc -o native_unix_socket native_unix_socket.c
native_unix_socket.c:5:10: fatal error: WS2tcpip.h: No such file or 
directory

 5 | #include 
   |  ^~~~
compilation terminated.

I fixed this by making the include file name lower case.  (My 
system is case sensitive, so it matters.)


Next:

$ gcc -o native_unix_socket native_unix_socket.c
native_unix_socket.c:8:10: fatal error: afunix.h: No such file or 
directory

 8 | #include 
   |  ^~
compilation terminated.

There's no file afunix.h in the Cygwin distribution, but I located 
it online and pasted in the contents.  The program now compiles but 
fails to link:


$ gcc -o native_unix_socket native_unix_socket.c
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): undefined 
reference to `__imp_WSAStartup'
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): relocation 
truncated to fit: R_X86_64_PC32 against undefined symbol 
`__imp_WSAStartup'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): undefined 
reference to `__imp_WSAGetLastError'
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): relocation 
truncated to fit: R_X86_64_PC32 against undefined symbol 
`__imp_WSAGetLastError'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
/tmp/cc74urPr.o:

Re: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

On 25/09/2020 21:30, Ken Brown wrote:

On 9/25/2020 2:50 PM, Ken Brown via Cygwin wrote:

On 9/25/2020 10:29 AM, Michael McMahon wrote:



On 25/09/2020 14:19, Ken Brown wrote:

On 9/24/2020 8:01 AM, Michael McMahon wrote:



On 24/09/2020 12:26, Ken Brown wrote:

On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote:

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain sockets
(a recent feature in Windows 10 and 2019 server) and Cygwin.
I think I possibly know the cause since I had to investigate a 
similar

looking issue on another platform built on Windows.

The problem is that cygwin commands don't seem to recognise 
native Unix

domain sockets correctly. For example, the socket "foo.sock" should
have the same ownership and similar permissions to other files
in the example below:

$ ls -lrt
total 2181303

-rw-r--r--  1 mimcmah  None 1259   Sep 23 10:22 
test.c
-rwxr-xr-x  1 mimcmah  None 3680   Sep 23 10:22 
test.obj
-rwxr-xr-x  1 mimcmah  None 121344 Sep 23 10:22 
test.exe
-rw-r-  1 Unknown+User Unknown+Group 0 Sep 23 10:23 
foo.sock
-rw-r--r--  1 mimcmah  None 144356 Sep 23 10:27 
check.ot


A bigger problem is that foo.sock can't be deleted with the 
cygwin "rm"

command.

$ rm -f foo.sock
rm: cannot remove 'foo.sock': Permission denied

$ chmod 777 foo.sock
chmod: changing permissions of 'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example shows.

I think the problem may relate to the way native Unix domain 
sockets are

implemented in Windows and the resulting special handling required.
They are implemented as NTFS reparse points and when opening them
with CreateFile, you need to specify the 
FILE_FLAG_OPEN_REPARSE_POINT

flag. Otherwise, you get an ERROR_CANT_ACCESS_FILE. There are other
complications unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code snippet
which creates foo.sock in the current directory. Obviously, this
only works on recent versions of Windows 10 and 2019 server.


Cygwin doesn't currently support native Windows AF_UNIX sockets, 
as you've discovered.  See


https://urldefense.com/v3/__https://cygwin.com/pipermail/cygwin/2020-June/245088.html__;!!GqivPVa7Brio!P7lIFI4rYAtWh8_DtCbRCxT-M_E4vwQ0qwzQ0p656T73BpJ0jbUkLI_bXdA6mmSL9lJcSQ$ 

for the current state of AF_UNIX sockets on Cygwin, including the 
possibility of using native Windows AF_UNIX sockets on systems 
that support them.


If all you want is for Cygwin to recognize such sockets and allow 
you to apply rm, chmod, etc., I don't think it would be hard to 
add that capability.  But I doubt if that's all you want.


Further discussion of this will have to wait until Corinna is 
available.




Thanks for the info. It's mainly about recognition of sockets for
regular commands. Since these objects can exist on Windows filesystems
now, potentially created by any kind of Windows application,
it would be great if Cygwin could handle them, irrespective of whether
the Cygwin development environment does. Though that sounds like a
good idea too.


I think this has a simple fix (attached), but I can't easily test it 
because your test program doesn't compile for me.  First, I got


$ gcc -o native_unix_socket native_unix_socket.c
native_unix_socket.c:5:10: fatal error: WS2tcpip.h: No such file or 
directory

 5 | #include 
   |  ^~~~
compilation terminated.

I fixed this by making the include file name lower case.  (My system 
is case sensitive, so it matters.)


Next:

$ gcc -o native_unix_socket native_unix_socket.c
native_unix_socket.c:8:10: fatal error: afunix.h: No such file or 
directory

 8 | #include 
   |  ^~
compilation terminated.

There's no file afunix.h in the Cygwin distribution, but I located 
it online and pasted in the contents.  The program now compiles but 
fails to link:


$ gcc -o native_unix_socket native_unix_socket.c
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): 
undefined reference to `__imp_WSAStartup'
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): relocation 
truncated to fit: R_X86_64_PC32 against undefined symbol 
`__imp_WSAStartup'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): 
undefined reference to `__imp_WSAGetLastError'
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): relocation 
truncated to fit: R_X86_64_PC32 against undefined symbol 
`__imp_WSAGetLastError'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x13d): 
undefined reference to `__imp_

Re: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

We're just trying to compile a test case and I checked that the
command line I sent does work. So, I think that it okay.
But, the original problem is with the Cygwin command line tools.

Michael.


On 25/09/2020 15:37, Eliot Moss wrote:

Native Windows is not Cygwin ...

If you have a problem in the native Windows environment, that would be 
with Microsoft, not Cygwin. If you're compiling for Cygwin, you need to 
use the CYgwin tool chain.


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: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

On 25/09/2020 14:19, Ken Brown wrote:

On 9/24/2020 8:01 AM, Michael McMahon wrote:



On 24/09/2020 12:26, Ken Brown wrote:

On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote:

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain sockets
(a recent feature in Windows 10 and 2019 server) and Cygwin.
I think I possibly know the cause since I had to investigate a similar
looking issue on another platform built on Windows.

The problem is that cygwin commands don't seem to recognise native Unix
domain sockets correctly. For example, the socket "foo.sock" should
have the same ownership and similar permissions to other files
in the example below:

$ ls -lrt
total 2181303

-rw-r--r--  1 mimcmah  None 1259   Sep 23 10:22 test.c
-rwxr-xr-x  1 mimcmah  None 3680   Sep 23 10:22 
test.obj
-rwxr-xr-x  1 mimcmah  None 121344 Sep 23 10:22 
test.exe
-rw-r-  1 Unknown+User Unknown+Group 0 Sep 23 10:23 
foo.sock
-rw-r--r--  1 mimcmah  None 144356 Sep 23 10:27 
check.ot


A bigger problem is that foo.sock can't be deleted with the cygwin "rm"
command.

$ rm -f foo.sock
rm: cannot remove 'foo.sock': Permission denied

$ chmod 777 foo.sock
chmod: changing permissions of 'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example shows.

I think the problem may relate to the way native Unix domain sockets 
are

implemented in Windows and the resulting special handling required.
They are implemented as NTFS reparse points and when opening them
with CreateFile, you need to specify the FILE_FLAG_OPEN_REPARSE_POINT
flag. Otherwise, you get an ERROR_CANT_ACCESS_FILE. There are other
complications unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code snippet
which creates foo.sock in the current directory. Obviously, this
only works on recent versions of Windows 10 and 2019 server.


Cygwin doesn't currently support native Windows AF_UNIX sockets, as 
you've discovered.  See


https://urldefense.com/v3/__https://cygwin.com/pipermail/cygwin/2020-June/245088.html__;!!GqivPVa7Brio!P7lIFI4rYAtWh8_DtCbRCxT-M_E4vwQ0qwzQ0p656T73BpJ0jbUkLI_bXdA6mmSL9lJcSQ$ 

for the current state of AF_UNIX sockets on Cygwin, including the 
possibility of using native Windows AF_UNIX sockets on systems that 
support them.


If all you want is for Cygwin to recognize such sockets and allow you 
to apply rm, chmod, etc., I don't think it would be hard to add that 
capability.  But I doubt if that's all you want.


Further discussion of this will have to wait until Corinna is available.



Thanks for the info. It's mainly about recognition of sockets for
regular commands. Since these objects can exist on Windows filesystems
now, potentially created by any kind of Windows application,
it would be great if Cygwin could handle them, irrespective of whether
the Cygwin development environment does. Though that sounds like a
good idea too.


I think this has a simple fix (attached), but I can't easily test it 
because your test program doesn't compile for me.  First, I got


$ gcc -o native_unix_socket native_unix_socket.c
native_unix_socket.c:5:10: fatal error: WS2tcpip.h: No such file or 
directory

     5 | #include 
   |  ^~~~
compilation terminated.

I fixed this by making the include file name lower case.  (My system is 
case sensitive, so it matters.)


Next:

$ gcc -o native_unix_socket native_unix_socket.c
native_unix_socket.c:8:10: fatal error: afunix.h: No such file or directory
     8 | #include 
   |  ^~
compilation terminated.

There's no file afunix.h in the Cygwin distribution, but I located it 
online and pasted in the contents.  The program now compiles but fails 
to link:


$ gcc -o native_unix_socket native_unix_socket.c
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): undefined reference 
to `__imp_WSAStartup'
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): relocation truncated 
to fit: R_X86_64_PC32 against undefined symbol `__imp_WSAStartup'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): undefined reference 
to `__imp_WSAGetLastError'
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): relocation truncated 
to fit: R_X86_64_PC32 against undefined symbol `__imp_WSAGetLastError'
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x13d): undefined reference 
to `__imp_WSAGetLastError'
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x13d): relocation truncated 
to fit: R_X86_64_PC32 against undefined symbol `__imp_WSAG

Re: Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

On 24/09/2020 12:26, Ken Brown wrote:

On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote:

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain sockets
(a recent feature in Windows 10 and 2019 server) and Cygwin.
I think I possibly know the cause since I had to investigate a similar
looking issue on another platform built on Windows.

The problem is that cygwin commands don't seem to recognise native Unix
domain sockets correctly. For example, the socket "foo.sock" should
have the same ownership and similar permissions to other files
in the example below:

$ ls -lrt
total 2181303

-rw-r--r--  1 mimcmah  None 1259   Sep 23 10:22 test.c
-rwxr-xr-x  1 mimcmah  None 3680   Sep 23 10:22 test.obj
-rwxr-xr-x  1 mimcmah  None 121344 Sep 23 10:22 test.exe
-rw-r-  1 Unknown+User Unknown+Group 0 Sep 23 10:23 foo.sock
-rw-r--r--  1 mimcmah  None 144356 Sep 23 10:27 check.ot

A bigger problem is that foo.sock can't be deleted with the cygwin "rm"
command.

$ rm -f foo.sock
rm: cannot remove 'foo.sock': Permission denied

$ chmod 777 foo.sock
chmod: changing permissions of 'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example shows.

I think the problem may relate to the way native Unix domain sockets are
implemented in Windows and the resulting special handling required.
They are implemented as NTFS reparse points and when opening them
with CreateFile, you need to specify the FILE_FLAG_OPEN_REPARSE_POINT
flag. Otherwise, you get an ERROR_CANT_ACCESS_FILE. There are other
complications unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code snippet
which creates foo.sock in the current directory. Obviously, this
only works on recent versions of Windows 10 and 2019 server.


Cygwin doesn't currently support native Windows AF_UNIX sockets, as 
you've discovered.  See


   
https://urldefense.com/v3/__https://cygwin.com/pipermail/cygwin/2020-June/245088.html__;!!GqivPVa7Brio!P7lIFI4rYAtWh8_DtCbRCxT-M_E4vwQ0qwzQ0p656T73BpJ0jbUkLI_bXdA6mmSL9lJcSQ$ 

for the current state of AF_UNIX sockets on Cygwin, including the 
possibility of using native Windows AF_UNIX sockets on systems that 
support them.


If all you want is for Cygwin to recognize such sockets and allow you to 
apply rm, chmod, etc., I don't think it would be hard to add that 
capability.  But I doubt if that's all you want.


Further discussion of this will have to wait until Corinna is available.



Thanks for the info. It's mainly about recognition of sockets for
regular commands. Since these objects can exist on Windows filesystems
now, potentially created by any kind of Windows application,
it would be great if Cygwin could handle them, irrespective of whether
the Cygwin development environment does. Though that sounds like a
good idea too.

- Michael
--
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

Problems with native Unix domain sockets on Win 10/2019

[Michael McMahon via Cygwin]

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain sockets
(a recent feature in Windows 10 and 2019 server) and Cygwin.
I think I possibly know the cause since I had to investigate a similar
looking issue on another platform built on Windows.

The problem is that cygwin commands don't seem to recognise native Unix
domain sockets correctly. For example, the socket "foo.sock" should
have the same ownership and similar permissions to other files
in the example below:

$ ls -lrt
total 2181303

-rw-r--r--  1 mimcmah  None 1259   Sep 23 10:22 test.c
-rwxr-xr-x  1 mimcmah  None 3680   Sep 23 10:22 test.obj
-rwxr-xr-x  1 mimcmah  None 121344 Sep 23 10:22 test.exe
-rw-r-  1 Unknown+User Unknown+Group 0 Sep 23 10:23 foo.sock
-rw-r--r--  1 mimcmah  None 144356 Sep 23 10:27 check.ot

A bigger problem is that foo.sock can't be deleted with the cygwin "rm"
command.

$ rm -f foo.sock
rm: cannot remove 'foo.sock': Permission denied

$ chmod 777 foo.sock
chmod: changing permissions of 'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example shows.

I think the problem may relate to the way native Unix domain sockets are
implemented in Windows and the resulting special handling required.
They are implemented as NTFS reparse points and when opening them
with CreateFile, you need to specify the FILE_FLAG_OPEN_REPARSE_POINT
flag. Otherwise, you get an ERROR_CANT_ACCESS_FILE. There are other
complications unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code snippet
which creates foo.sock in the current directory. Obviously, this
only works on recent versions of Windows 10 and 2019 server.

All the best,
Michael McMahon

#define WIN32_LEAN_AND_MEAN

#include 
#include 
#include 
#include 
#include 
#include 

#define WIN32_LEAN_AND_MEAN


int __cdecl main(int argc, char *argv[])
{
WSADATA wsadata;
struct sockaddr_un addr;
socklen_t len;
int z = AF_UNIX;
SOCKET s, s0;

if (WSAStartup(MAKEWORD(2,2), &wsadata) != 0) {
printf("STartup failed\n");
return 0;
}
s0 = socket(AF_UNIX, SOCK_STREAM, 0);
memset(&addr, 0, sizeof(addr));

addr.sun_family = AF_UNIX;
//strcpy(addr.sun_path, argv[1]);
strcpy(addr.sun_path, "foo.sock");

z = bind(s0, (const struct sockaddr *) &addr, strlen(addr.sun_path) + 
sizeof (addr.sun_family));
if (z != 0) {
printf("bind failed %ld\n", WSAGetLastError());
}
len = sizeof(addr);
z = getsockname(s0, (struct sockaddr *)&addr, &len);
if (z != 0) {
printf("getsockname failed %ld\n", WSAGetLastError());
} else {
printf("getsockname works\n");
printf("fam = %d, len = %d\n", addr.sun_family, len);
int clen = len - offsetof(struct sockaddr_un, sun_path);
printf("offsetof clen = %d\n", clen);
printf("strlen = %zd\n", strlen(addr.sun_path));
printf("name = %s\n", addr.sun_path);
}
}

--
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

Issues with removing cygwin installed TTF font files

[Michael Soegtrop]

Dear Cygwin Team and Users,

since a few months I have issues deleting cygwin installations. In some 
cases randomly the /usr/share/fonts/microsoft folder and the TTF files 
in it remain. According to DOS dir the folder contains junctions to TTF 
files - not sure how this is possible - afaik a junction is for folders. 
But what I get is this:


C:\ci\cygwin64_21081_16603\usr\share\fonts\microsoft>dir
 Volume in drive C is SYSTEM
 Volume Serial Number is 70C2-07FA

 Directory of C:\ci\cygwin64_21081_16603\usr\share\fonts\test

02/07/2020  13:52  .
02/07/2020  13:52  ..
01/07/2020  11:47 ahronbd.ttf [...]
01/07/2020  11:47 andlso.ttf [...]
01/07/2020  11:47 angsa.ttf [...]
01/07/2020  11:47 angsab.ttf [...]
01/07/2020  11:47 angsai.ttf [...]
01/07/2020  11:47 angsau.ttf [...]
01/07/2020  11:47 angsaub.ttf [...]
01/07/2020  11:47 angsaui.ttf [...]
01/07/2020  11:47 angsauz.ttf [...]
:

Interesting is that this does not happen always. I am working on a open 
source project and our CI installs and removes cygwin about 100 times a 
day. I see this issue about 20 times per month - distributed over all of 
our CI runners. Maybe Windows gives the TTF file some special handling 
every now and again, but I checked the registry and there is nothing 
pointing to this cygwin folder, except the cygwin installation registry.


I couldn't find any method to remove these files. I made sure I have 
delete rights and that nobody has a lock on these files, but still 
whatever I tried (Explorer, cygwin admin console, DOS admin console, 
reboot a few times, chkdsk, google) failed.


If you have an idea that could help me to delete these files reliably 
and/or avoid this situation, it would help me a lot!


Best regards,

Michael

--
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

Linux

[Zektser, Michael P via Cygwin]

1 [main] ssh 11260 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
--
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

Cygwin terminal fails to start after win update

[Michael Moats]

Hello. Loaded cygwin a few weeks ago, but after windows 10 update, 
mintty term fails to start.


Versions:
cygwin 3.1.6-1

OS Name    Microsoft Windows 10 Home
Version    10.0.19041 Build 19041

When problem first noticed:
Error: Could not fork child process: Resource temporarily unavailable (-1).
DLL rebasing may be required; see 'rebaseall / rebase --help'.
(and terminal allows no typing)

When attempt is made to add dll, bash and some other individual 
exceptions to firewall ASLR settings, Mintty starts & shell commands 
such as echo and pwd will work, but commands from /bin (i.e. ls, ln, 
grep, vi, cat, which) return nothing. Maybe more exceptions needed, but 
which ones?


To get cygwin working a usual, these gross windows defender firewall 
changes were made:


Windows Security
    App & browser control
        Exploit protection

Force randomization for images (Mandatory ASLR)
    Force relocation of images not compiled with /DYNAMICBASE
-> Off by default     [Mintty working]
-> On by default    [Mintyy not working]

Randomize memory allocations (Bottom-up ASLR)
    Randomize locations for virtual memory allocations.
-> Off by default     [Mintyy working]
-> On by default    [Mintyy not working]

High-entropy ASLR
    Increase variability when using Randomize memory allocations 
(Bottom-up ASLR)

-> Off by default     [Mintty working]
-> On by default    [Mintty not working]

When Cyg/Mintty is working with above gross changes:
    $ cd /usr

    $ ln -s /bin /usr/bin

    $ ls -i | grep bin
    1125899907459844 bin/
    562949954038681 sbin/

    $ cd ..

    $ ls -i | grep bin
    1125899907459844 bin/
    562949954038681 sbin/

    $ ps -ef | grep -i min
       X 649   1 ?    13:18:14 /usr/bin/mintty

Thanks in advance!!

-- Michael Moats


--
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

Setup: CMake-based build system

[Michael Wild via Cygwin]

Dear all
Hi Jon

For the purpose of my recent experiments I ported the setup app to
CMake-based build system. Before I throw it away I thought I'd brush it up
a bit and submit it for you to do with as you please.

Kind regards

Michael


0001-Add-CMake-based-build-system.patch
Description: Binary data
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

On Sun, 30 Aug 2020, 22:24 Jon Turney wrote:

> On 27/08/2020 06:48, Michael Wild via Cygwin wrote:
> > On Wed, Aug 26, 2020 at 10:57 PM Jon Turney wrote:
> >>
> >> However, even if that's fixed, there's no value for winsymlinks in
> >> CYGWIN env var to specify the behaviour of Cygwin 3.1.4 and previous
> >> (i.e. always create traditional symlinks, don't use WSL symlink reparse
> >> points)
> >
> > Thanks Jon for the elaboration. Isn't winsymlinks=lnk supposed to do this
> > per the documentation?
>
> No.
>
> I'm not sure what documentation you are looking at, but [1][2] seems
> reasonably clear that the behaviour of Cygwin 3.1.4 and earlier (what I
> referred to as "traditional cygwin symlinks") isn't the same as ".lnk
> symlinks".
>
> [1] https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks
> [2] https://cygwin.com/cygwin-ug-net/using-cygwinenv.html


Ah, I was jumping ahead there. My intention was having no WSL symlink
reparse points. And per my experiments, winsymlinks:lnk gets that job done.

Michael
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

On Thu, Aug 27, 2020 at 2:48 PM Michael Wild wrote:

>
>
> [...] I attached this fix as a patch. [...]
>
>
No, I didn't...


0001-Keep-CYGWIN-environment-variable-when-running-script.patch
Description: Binary data
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

On Thu, Aug 27, 2020 at 11:44 AM Michael Wild wrote:

>
> On Thu, Aug 27, 2020 at 11:02 AM Corinna Vinschen wrote:
>
>> On Aug 27 07:48, Michael Wild via Cygwin wrote:
>> > On Wed, Aug 26, 2020 at 10:57 PM Jon Turney wrote:
>> >
>> > >
>> > > It turns out to be the case that setup doesn't propagate the CYGWIN
>> > > environment variable into the environment for scripts it runs, so
>> > > setting that isn't going to make any difference.  That should probably
>> > > be considered a bug.
>> > >
>> > > However, even if that's fixed, there's no value for winsymlinks in
>> > > CYGWIN env var to specify the behaviour of Cygwin 3.1.4 and previous
>> > > (i.e. always create traditional symlinks, don't use WSL symlink
>> reparse
>> > > points)
>> > >
>> >
>> > Thanks Jon for the elaboration. Isn't winsymlinks=lnk supposed to do
>> this
>> > per the documentation? Could Corinna be convinced to include an option
>> > where this can be done? To be honest, my hopes are greater to get this
>> > worked-around in a useful timeframe from the Cygwin side than getting
>> the
>> > proper fix into Docker.
>>
>> Isn't it sufficient to fix setup so you can create lnk-style symlinks in
>> your scenario?  The CYGWIN env variable and the number of options is
>> such a mess.
>>
>>
>> Corinna
>>
>
> I am right now modifying setup to not sanitize CYGWIN away when invoking
> the post-install scripts and then will report back.
>
> Michael
>

Hmm, OK, changing script.cc to not strip out CYGWIN is trivial. But the
harder part is that main.cc uses ShellExecuteEx() with
SHELLEXECUTEINFO.verb set to "runas" in order to re-run setup elevated.
This resets all environment variables back to default. In my instance I can
circumvent this by passing --no-admin and running from an elevated shell
where CYGWIN is set already. And indeed, this works and resolves my Docker
problem. I attached this fix as a patch. But on the other hand, I find this
behavior to be a bit confusing. However, I don't see an easy way of
resolving the "runas" issue, because it is by design. An option would be
that the calling process passes the CYGWIN variable as a command line
argument to the elevated process. But that is also ugly. What do you guys
think?

Michael
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

On Thu, Aug 27, 2020 at 11:02 AM Corinna Vinschen wrote:

> On Aug 27 07:48, Michael Wild via Cygwin wrote:
> > On Wed, Aug 26, 2020 at 10:57 PM Jon Turney wrote:
> >
> > >
> > > It turns out to be the case that setup doesn't propagate the CYGWIN
> > > environment variable into the environment for scripts it runs, so
> > > setting that isn't going to make any difference.  That should probably
> > > be considered a bug.
> > >
> > > However, even if that's fixed, there's no value for winsymlinks in
> > > CYGWIN env var to specify the behaviour of Cygwin 3.1.4 and previous
> > > (i.e. always create traditional symlinks, don't use WSL symlink reparse
> > > points)
> > >
> >
> > Thanks Jon for the elaboration. Isn't winsymlinks=lnk supposed to do this
> > per the documentation? Could Corinna be convinced to include an option
> > where this can be done? To be honest, my hopes are greater to get this
> > worked-around in a useful timeframe from the Cygwin side than getting the
> > proper fix into Docker.
>
> Isn't it sufficient to fix setup so you can create lnk-style symlinks in
> your scenario?  The CYGWIN env variable and the number of options is
> such a mess.
>
>
> Corinna
>

I am right now modifying setup to not sanitize CYGWIN away when invoking
the post-install scripts and then will report back.

Michael
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

On Wed, Aug 26, 2020 at 10:57 PM Jon Turney wrote:

>
> It turns out to be the case that setup doesn't propagate the CYGWIN
> environment variable into the environment for scripts it runs, so
> setting that isn't going to make any difference.  That should probably
> be considered a bug.
>
> However, even if that's fixed, there's no value for winsymlinks in
> CYGWIN env var to specify the behaviour of Cygwin 3.1.4 and previous
> (i.e. always create traditional symlinks, don't use WSL symlink reparse
> points)
>

Thanks Jon for the elaboration. Isn't winsymlinks=lnk supposed to do this
per the documentation? Could Corinna be convinced to include an option
where this can be done? To be honest, my hopes are greater to get this
worked-around in a useful timeframe from the Cygwin side than getting the
proper fix into Docker.

Michael
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

On Wed, Aug 26, 2020 at 9:06 PM Michael Wild wrote:

>
>
> On Wed, Aug 26, 2020 at 8:31 PM Achim Gratz wrote:
>
>> Michael Wild via Cygwin writes:
>> > Is there a way to disable WSL symlinks when installing Cygwin with
>> > setup.exe? Problem is that Docker on Windows apparently doesn't support
>> > them (see https://github.com/moby/moby/issues/41058). I would like to
>> use a
>> > custom Docker image for GitHub Actions to reproducibly build my packages
>> > but am failing to build the base image because of this.
>>
>> That description is not very clear.  If the symlinks are created during
>> postinstall, then they should obey the value of CYGWIN environment that
>> is in effect at that time.  If so, then the behaviour should start
>> appearing with cygwin-3.1.5, which is the first release that has the
>> code supporting these (and makes them the default).  I'm not aware that
>> the behaviour of setup.exe has changed in that respect recently, but I
>> haven't checked thoroughly.
>>
>>
>> Regards,
>> Achim.
>>
>>
> In order to reproduce, run the following commands on Windows:
>
> > docker run --name setup -it
> mcr.microsoft.com/windows/servercore:10.0.17763.1397-amd64
>
> Once inside the container, run:
>
> > powershell
> PS> $env:CYGWIN=winsymlinks:lnk
> PS> mkdir \tmp
> PS> cd \tmp
> PS> Invoke-WebRequest -Uri https://www.cygwin.com/setup-x86_64.exe
> -OutFile setup-x86_64.exe
> PS> .\setup-x86_64.exe -W -n -q -R C:\Cygwin64 -s
> http://mirrors.kernel.org/sourceware/cygwin/ -P default
> PS> Wait-Process -Name setup-x86_64
> PS> fsutil reparsePoint query C:\cygwin64\dev\fd
>
> The last command will output something like:
>
> Reparse Tag Value : 0xa01d
> Tag value: Microsoft
> Tag value: Name Surrogate
>
> Reparse Data Length: 0x0011
> Reparse Data:
> : 02 00 00 00 2f 70 72 6f 63 2f 73 65 6c 66 2f 66 /proc/self/f
> 0010: 64
>
> So, the CYGWIN variable got ignored.
>
> If you want, you can try to run a Cygwin shell:
>
> PS> C:\Cygwin64\bin\bash.exe --login -i
>
> For me this works fine. Then, exit the container and try to commit it:
>
> PS> exit
> > exit
> > docker commit setup cygwin:latest
>
> The last command then errors out with:
>
> Error response from daemon: re-exec error: exit status 1: output:
> time="2020-08-26T21:00:55+02:00" level=error msg="hcsshim::ImportLayer -
> failed failed in Win32: The system cannot find th
> e path specified. (0x3)" error="hcsshim::ImportLayer - failed failed in
> Win32: The system cannot find the path specified. (0x3)"
> importFolderPath="C:\\ProgramData\\Docker\\tmp\\hcs00092524
> 3"
> path="?\\C:\\ProgramData\\Docker\\windowsfilter\\c31ac616438460478e6cc6e5526ee664e620ba4479da433bcabb6d2a76880ef4"
> hcsshim::ImportLayer - failed failed in Win32: The system cannot find the
> path specified. (0x3)
>
> Does this help diagnosing the problem?
>
> Kind regards
>
> Michael
>

I tried snooping into the setup code at
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=summary. The word CYGWIN
doesn't show up, so I don't assume it checks the variable. I do see code to
create links when unpacking archives, but to me it looks like it only does
hard-links and the old-style link files. Next I'll try to find where the
post-install scripts are called and put in some tracing code to find out
what's going on...

Michael
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

On Wed, Aug 26, 2020 at 8:31 PM Achim Gratz wrote:

> Michael Wild via Cygwin writes:
> > Is there a way to disable WSL symlinks when installing Cygwin with
> > setup.exe? Problem is that Docker on Windows apparently doesn't support
> > them (see https://github.com/moby/moby/issues/41058). I would like to
> use a
> > custom Docker image for GitHub Actions to reproducibly build my packages
> > but am failing to build the base image because of this.
>
> That description is not very clear.  If the symlinks are created during
> postinstall, then they should obey the value of CYGWIN environment that
> is in effect at that time.  If so, then the behaviour should start
> appearing with cygwin-3.1.5, which is the first release that has the
> code supporting these (and makes them the default).  I'm not aware that
> the behaviour of setup.exe has changed in that respect recently, but I
> haven't checked thoroughly.
>
>
> Regards,
> Achim.
>
>
In order to reproduce, run the following commands on Windows:

> docker run --name setup -it
mcr.microsoft.com/windows/servercore:10.0.17763.1397-amd64

Once inside the container, run:

> powershell
PS> $env:CYGWIN=winsymlinks:lnk
PS> mkdir \tmp
PS> cd \tmp
PS> Invoke-WebRequest -Uri https://www.cygwin.com/setup-x86_64.exe -OutFile
setup-x86_64.exe
PS> .\setup-x86_64.exe -W -n -q -R C:\Cygwin64 -s
http://mirrors.kernel.org/sourceware/cygwin/ -P default
PS> Wait-Process -Name setup-x86_64
PS> fsutil reparsePoint query C:\cygwin64\dev\fd

The last command will output something like:

Reparse Tag Value : 0xa01d
Tag value: Microsoft
Tag value: Name Surrogate

Reparse Data Length: 0x0011
Reparse Data:
: 02 00 00 00 2f 70 72 6f 63 2f 73 65 6c 66 2f 66 /proc/self/f
0010: 64

So, the CYGWIN variable got ignored.

If you want, you can try to run a Cygwin shell:

PS> C:\Cygwin64\bin\bash.exe --login -i

For me this works fine. Then, exit the container and try to commit it:

PS> exit
> exit
> docker commit setup cygwin:latest

The last command then errors out with:

Error response from daemon: re-exec error: exit status 1: output:
time="2020-08-26T21:00:55+02:00" level=error msg="hcsshim::ImportLayer -
failed failed in Win32: The system cannot find th
e path specified. (0x3)" error="hcsshim::ImportLayer - failed failed in
Win32: The system cannot find the path specified. (0x3)"
importFolderPath="C:\\ProgramData\\Docker\\tmp\\hcs00092524
3"
path="?\\C:\\ProgramData\\Docker\\windowsfilter\\c31ac616438460478e6cc6e5526ee664e620ba4479da433bcabb6d2a76880ef4"
hcsshim::ImportLayer - failed failed in Win32: The system cannot find the
path specified. (0x3)

Does this help diagnosing the problem?

Kind regards

Michael
--
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: Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

Hi Andrey

On Wed, Aug 26, 2020 at 5:20 PM Andrey Repin wrote:

> Greetings, Michael Wild!
>
> > Is there a way to disable WSL symlinks when installing Cygwin with
> > setup.exe? Problem is that Docker on Windows apparently doesn't support
> > them (see https://github.com/moby/moby/issues/41058). I would like to
> use a
> > custom Docker image for GitHub Actions to reproducibly build my packages
> > but am failing to build the base image because of this.
>
> What is the value of your CYGWIN environment variable?
> Do you run setup elevated?
>
>
I tried setting CYGWIN=winsymlinks:lnk but no luck. The docker build
process uses an administrator account inside the container, so yes, it is
elevated.

Michael
--
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] python-paramiko 2.7.1-1

[Michael Wild via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* python36-paramiko-2.7.1-1
* python37-paramiko-2.7.1-1
* python38-paramiko-2.7.1-1

This is a library for making SSH2 connections (client or server).
Emphasis is on using SSH2 as an alternative to SSL for making secure
connections between python scripts. All major ciphers and hash methods
are supported. SFTP client and server mode are both supported too.
--
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] python-nacl 1.4.0-1

[Michael Wild via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* python36-nacl-1.4.0-1
* python37-nacl-1.4.0-1
* python38-nacl-1.4.0-1

PyNaCl is a Python binding to libsodium, which is a fork of the
Networking and Cryptography library. These libraries have a stated goal of
improving usability, security and speed.
--
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] python-bcrypt 3.2.0-1

[Michael Wild via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* python36-bcrypt-3.2.0-1
* python37-bcrypt-3.2.0-1
* python38-bcrypt-3.2.0-1

Password hashing library for Python
--
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] tmux 3.1b-1

[Michael Wild via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* tmux-3.1b-1

tmux enables a number of terminals (or windows) to be accessed and
controlled from a single terminal like screen. tmux runs as a server-client
system. A server is created automatically when necessary and holds a number
of
sessions, each of which may have a number of windows linked to it. Any
number
of clients may connect to a session, or the server may be controlled by
issuing
commands with tmux. Communication takes place through a socket, by default
placed in /tmp. Moreover tmux provides a consistent and well-documented
command
interface, with the same syntax whether used interactively, as a key
binding,
or from the shell. It offers a choice of vim or Emacs key layouts.
--
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

Forcing setup.exe not to create WSL symlinks

[Michael Wild via Cygwin]

Hi all

Is there a way to disable WSL symlinks when installing Cygwin with
setup.exe? Problem is that Docker on Windows apparently doesn't support
them (see https://github.com/moby/moby/issues/41058). I would like to use a
custom Docker image for GitHub Actions to reproducibly build my packages
but am failing to build the base image because of this.

Kind regards

Michael
--
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: Trouble with output character sets from Win32 applications running under mksh

[Michael Shay via Cygwin]

Michael



From:   "Brian Inglis" 
To: cygwin@cygwin.com
Date:   08/04/2020 08:32 AM
Subject:Re: Trouble with output character sets from Win32 
applications running under mksh
Sent by:"Cygwin" 



On 2020-08-03 16:05, Michael Shay via Cygwin wrote:
> On 2020-08-03 11:42, Andrey Repin wrote:
>>>> Doesn't help. I tried 65001 (UTF-8):

>>> Because you're confusing things.
>>> chcp has nothing to do with LANG or LC_*.
>>> Et vice versa.
>>>
>> chcp sets console code page for native console applications. 
>>> Only for those supporting it. Many do not.
>>> LANG sets output parameters for Cygwin applications (and other 
programs 
>>> that look for it, but these are few).

>> You cut the significant statement at the top of the OP:
>>>> I'm having a problem with Cygwin 3.1.4, changing the character set on 

>>>> the fly. It seems to work with Cygwin applications, but not with 
Win32 
>>>> applications.

>> He has problems with invalid characters only running win32 console 
>> applications: I changed the subject to hopefully better reflect the 
issue.
>> 
>> I am unsure where Cygwin 3.1.4 comes into Win32 applications - you have 
to 
>> use the Windows codepage conversion routines.
>> 
>> You can only change input character sets on the fly; output character 
sets 
>> will depend on mintty support of xterm-compatible character set support
>> and switching escape sequences; if you set up UTF16LE console output,
>> Windows and mintty should handle it.
>> 
>> Perhaps a better description of your environment, build tools, what you 

>> are trying to do, what you expect as output, and what you are getting 
as 
>> output, could help us better understand and help with the issue you 
see.

> The script I sent changes the locale information i.e. LANG and LC_ALL 
are 
> set to en_US.CP1252. i.e.
> 
> export LANG="en_US.CP1252"
> export LC_ALL=en_US.CP1252

FYI the normal sequence and order to check is LANG, LC_CTYPE, LC_ALL, 
where the
last var set wins, or the reverse where the first var set wins; the 
default
locale may be POSIX C.ASCII or the effective Windows locale, depending on 
your
startup.
>> Thanks, that's good to know.

> Then, it runs a simple Win32 program that takes a single input argument, 
ZÇ,
> the second character being C-cedilla, an 8-bit character, hex value 
0xc7.
> The Win32 program transcodes the input Unicode argument using the Cygwin
> character set to determine the codepage, 1252.

Do you mean using the environment variables to determine the codepage?
>> Yes. Our code does try to fetch the character set information from the
>> environment.


FYI the default character set if none is specified is the Unix equivalent 
of the
default Windows "ANSI"/OEM code page, in English or many European locales 
that
will be ISO-8859-1.

You may have to use cygpath -C OEM chars... or cygpath -C ANSI chars... to
convert a string to the required character set for console or GUI 
programs.
>> Our production code uses the console to display error information in 
the
>> appropriate character set, but our command-line utilities expect to be
>> able to take input strings encoded in the character set in use, which
>> may be an 8-bit SBCS like ISO-8849-1, Windows 1252, or a MBCS, like 
UTF-8
>> or e.g. Windows 932. Using 'cygpath' isn't an option.

Please specify what you mean by "Unicode" in each context; that term means 
a
standard for representing scripts in many writing systems with a large 
character
glyph repertoire and a number of encodings, representations, and handling 
rules:
in each use case, do you mean a char/wchar representation, and/or an 
encoding
UTF16LE or UTF-8?
Similarly when MS uses "ANSI" they may mean an SBCS OEM code page.

>> Unicode == UTF-16 in all cases. This is the wide-character set used by 
Microsoft
>> as far as I can tell in the wide-char version of their Win32 API 
functions e.g.
>> CreateProcessW() vs. CreateProcessA().

To check what is available and what is in effect in Cygwin, try e.g.:

$ for o in system user no-unicode input format; do echo `locale --$o` $o; 
done
en_US system
en_GB user
en_CA no-unicode
en_CA input
en_CA format
$ locale

on both Cygwin versions.

>>1.7.28 output

>>$for o in system user no-unicode input format; do echo `locale --$o` $o; 
done
>>en_US system
>>en_US user
>>en_US no-unicode
>>locale: unknown option -- input
>>Try `locale --help' for more information.
>>input
>>en_US format

>>3.1.4 output

>>$for o in system user no-unicode input format; do echo `locale --$o` $o; 
done
&g

Re: Trouble with output character sets from Win32 applications running under mintty

[Michael Shay via Cygwin]

Michael



From:   "Brian Inglis" 
To: cygwin@cygwin.com
Date:   08/03/2020 05:23 PM
Subject:Re: Trouble with output character sets from Win32 
applications running under mintty
Sent by:"Cygwin" 



On 2020-08-03 11:42, Andrey Repin wrote:
>> Doesn't help. I tried 65001 (UTF-8):
> 
> Because you're confusing things.
> chcp has nothing to do with LANG or LC_*.
> Et vice versa.
> 
> chcp sets console code page for native console applications. Only for 
those
> supporting it. Many do not.
> LANG sets output parameters for Cygwin applications (and other programs 
that
> look for it, but these are few).

You cut the significant statement at the top of the OP:

>> I'm having a problem with Cygwin 3.1.4, changing the character set on 
the 
>> fly. It seems to work with Cygwin applications, but not with Win32 
>> applications.

He has problems with invalid characters only running win32 console 
applications:
I changed the subject to hopefully better reflect the issue.

I am unsure where Cygwin 3.1.4 comes into Win32 applications - you have to 
use
the Windows codepage conversion routines.

You can only change input character sets on the fly; output character sets 
will
depend on mintty support of xterm-compatible character set support and 
switching
escape sequences; if you set up UCS16LE console output, Windows and mintty
should handle it.

Perhaps a better description of your environment, build tools, what you 
are
trying to do, what you expect as output, and what you are getting as 
output,
could help us better understand and help with the issue you see.

-- 
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 IEC 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

The script I sent changes the locale information i.e. LANG and LC_ALL are 
set to en_US.CP1252. i.e.

export LANG="en_US.CP1252"
export LC_ALL=en_US.CP1252

Then, it runs a simple Win32 program that takes a single input argument, 
ZÇ, the second character being C-cedilla, an 8-bit character, hex value 
0xc7. The Win32 program transcodes the input Unicode argument using the 
Cygwin character set to determine the codepage, 1252. It then prints the 
transcoded characters to stdout, and the result should be ZÇ, identical to 
the input argument. This works fine using Cygwin 1.7.28. Cygwin 3.1.4 is 
launching the Win32 application, and is responsible for transcoding the 
arguments passed to it by mksh, in this case CP1252 characters ZÇ, into 
Unicode. That means Cygwin has to use the mb-to-uc function for 
transcoding codepage 1252 to Unicode. It does not. It uses the UTF-8 to 
Unicode function (I've seen this using gdb). That function flags the Ç as 
an invalid UTF-8 sequence, not surprisingly since it's not a UTF-8 
character. No matter what character set I use in 'export LANG...' and 
'export LC_ALL...', Cygwin 3.1.4 always uses the uft8-to-wc transcoding 
function in sys1.7.28 Uses the correct function. I'm not using mintty, I'm 
using mksh, a requirement since our software uses lots of shell scripts, 
and for legacy support, that means using a Korn shell. I could understand 
it if 1.7.28 didn't do the proper transcoding, but it does. 

I used:

gdb mksh

to load mksh into the debugger, then started it with

start -c 'cygtest.exe ZÇ'

That allowed me to step into child_info_spawn::worker() and stop at the 
call to CreateProcess(), where the command line (cygtest.exe) and argument 
(ZÇ) are translated into Unicode.

This is the code to which I'm referring, in strfuncs.cc, which is supposed 
to translate the command line and arguments from CP 1252 into Unicode.

  size_t __reg3
  sys_mbstowcs (wchar_t * dst, size_t dlen, const char *src, size_t nms)
  {
mbtowc_p f_mbtowc = __MBTOWC;
if (f_mbtowc == __ascii_mbtowc)
  {
f_mbtowc = __utf8_mbtowc;   <<<< THE CODE CHANGES THE 
'__ascii_mbtowc' TO '__utf8_mbtowc' EVERY TIME, REGARDLESS OF THE 
CODEPAGE.
  }
return sys_cp_mbstowcs (f_mbtowc, dst, dlen, src, nms);
  }

So 'f_mbtowc' is set to _ascii_mbtowc, the default.You said:

You can only change input character sets on the fly;

The input character set to Cygwin should have been changed to CP 1252, as 
it was in 1.7.28. At least, that's what I would expect to happen. If it 
does not, or if miintty is required, then that's a regression from 1.7.28.

Mike Shay







  
NOTICE  from Ab Initio: This email (including any attachments) may contain 

Re: Trouble with character sets

[Michael Shay via Cygwin]

Michael



From:   "Andrey Repin" 
To:     "Michael Shay" , cygwin@cygwin.com
Date:   08/03/2020 02:06 PM
Subject:Re: Trouble with character sets



Greetings, Michael Shay!

Please bottom post in this mailing list.

> Doesn't help. I tried 65001 (UTF-8):

Because you're confusing things.
chcp has nothing to do with LANG or LC_*.
Et vice versa.

chcp sets console code page for native console applications. Only for 
those
supporting it. Many do not.
LANG sets output parameters for Cygwin applications (and other programs 
that
look for it, but these are few).

> ### SET CP TO UTF-8, 65001
> $cygwin_charset_test.ksh
> Old CP 65001
> locale on entry
> LANG=
> LC_CTYPE="C.UTF-8"
> LC_NUMERIC="C.UTF-8"
> LC_TIME="C.UTF-8"
> LC_COLLATE="C.UTF-8"
> LC_MONETARY="C.UTF-8"
> LC_MESSAGES="C.UTF-8"
> LC_ALL=

> ### CP SET TO 65001
> Active code page: 65001
> locale changed to
> LANG=en_US.CP1252
> LC_CTYPE="en_US.CP1252"
> LC_NUMERIC="en_US.CP1252"
> LC_TIME="en_US.CP1252"
> LC_COLLATE="en_US.CP1252"
> LC_MONETARY="en_US.CP1252"
> LC_MESSAGES="en_US.CP1252"
> LC_ALL=en_US.CP1252

> Running WIN32 pgm
> Transcoding using Cygwin codepage: 1252
> Input widechar string:
> lpw[0] = Z - 5A
> lpw[1] =  - F0C7
> wmain: Z?
> Active code page: 65001

> and 1252

> ### SET CP TO 1252
> $cygwin_charset_test.ksh
> Old CP 65001
> locale on entry
> LANG=
> LC_CTYPE="C.UTF-8"
> LC_NUMERIC="C.UTF-8"
> LC_TIME="C.UTF-8"
> LC_COLLATE="C.UTF-8"
> LC_MONETARY="C.UTF-8"
> LC_MESSAGES="C.UTF-8"
> LC_ALL=

> ### CP SET TO 1252
> Active code page: 1252
> locale changed to
> LANG=en_US.CP1252
> LC_CTYPE="en_US.CP1252"
> LC_NUMERIC="en_US.CP1252"
> LC_TIME="en_US.CP1252"
> LC_COLLATE="en_US.CP1252"
> LC_MONETARY="en_US.CP1252"
> LC_MESSAGES="en_US.CP1252"
> LC_ALL=en_US.CP1252

> Running WIN32 pgm
> Transcoding using Cygwin codepage: 1252
> Input widechar string:
> lpw[0] = Z - 5A
> lpw[1] =  - F0C7
> wmain: Z?
> Active code page: 65001


-- 
With best regards,
Andrey Repin
Monday, August 3, 2020 20:36:16

Sorry for my terrible english...



Thanks for the feedback. I wasn't aware of the protocol.

Mike Shay


  
NOTICE  from Ab Initio: This email (including any attachments) may contain 
information that is subject to confidentiality obligations or is legally 
privileged, and sender does not waive confidentiality or privilege. If received 
in error, please notify the sender, delete this email, and make no further use, 
disclosure, or distribution.  
--
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: Trouble with character sets

[Michael Shay via Cygwin]

Doesn't help. I tried 65001 (UTF-8):

### SET CP TO UTF-8, 65001
$cygwin_charset_test.ksh
Old CP 65001
locale on entry
LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

### CP SET TO 65001
Active code page: 65001
locale changed to
LANG=en_US.CP1252
LC_CTYPE="en_US.CP1252"
LC_NUMERIC="en_US.CP1252"
LC_TIME="en_US.CP1252"
LC_COLLATE="en_US.CP1252"
LC_MONETARY="en_US.CP1252"
LC_MESSAGES="en_US.CP1252"
LC_ALL=en_US.CP1252

Running WIN32 pgm
Transcoding using Cygwin codepage: 1252
Input widechar string:
lpw[0] = Z - 5A
lpw[1] =  - F0C7
wmain: Z?
Active code page: 65001

and 1252

### SET CP TO 1252
$cygwin_charset_test.ksh
Old CP 65001
locale on entry
LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

### CP SET TO 1252
Active code page: 1252
locale changed to
LANG=en_US.CP1252
LC_CTYPE="en_US.CP1252"
LC_NUMERIC="en_US.CP1252"
LC_TIME="en_US.CP1252"
LC_COLLATE="en_US.CP1252"
LC_MONETARY="en_US.CP1252"
LC_MESSAGES="en_US.CP1252"
LC_ALL=en_US.CP1252

Running WIN32 pgm
Transcoding using Cygwin codepage: 1252
Input widechar string:
lpw[0] = Z - 5A
    lpw[1] =  - F0C7
wmain: Z?
Active code page: 65001




Michael



From:   "Brian Inglis" 
To: cygwin@cygwin.com
Date:   08/03/2020 12:31 PM
Subject:Re: Trouble with character sets
Sent by:"Cygwin" 



On 2020-08-03 09:36, Michael Shay via Cygwin wrote:
> I'm having a problem with Cygwin 3.1.4, changing the character set on 
the 
> fly. It seems to work with Cygwin applications, but not with Win32 
> applications.
> I have a Korn shell script:
> #!/bin/ksh
> OLD_LANG="$LANG"
> OLD_LC_ALL="$LC_ALL"
> echo "locale on entry"
> locale
> echo ""
> export LANG="en_US.CP1252"
> export LC_ALL=en_US.CP1252
> echo "locale changed to"
> locale
> echo ""
> # Default is to run the Win32 program. Input any argument other than 
> 'WIN32'
> # to run '/bin/echo'.
> case $# in
>0 )  echo "Running WIN32 pgm"
> ksh -c 'cygtest.exe ZÇ'
> ;;
>1 )  echo "Running Cygwin 'echo'"
> ksh -c '/bin/echo ZÇ'
> ;;
>2 )  echo "Running WIN32 pgm"
> ksh -c 'cygtest.exe ZÇ'
> echo ""
> echo "Running Cygwin 'echo'"
> ksh -c '/bin/echo ZÇ'
> ;;
>* ) ;;
> esac
> LC_ALL="$OLD_LC_ALL"
> LANG="$OLD_LANG"
> and a Win32 application (attached file cygtest.cpp)
> I used gdb to see what was happening in child_info_spawn::worker(), when 
a 
> Win32 program is started using:
>   rc = CreateProcessW (runpath,   /* image name w/ full path */
>cmd.wcs (wcmd),  /* what was passed to exec */
>sa,/* process security attrs */
>sa,/* thread security attrs */
>TRUE,/* inherit handles */
>c_flags,
>envblock,  /* environment */
>NULL,
>&si,
>&pi);
> Specifically, 'cmd.wcs(wcmd)' invokes:
>   wchar_t *wcs (wchar_t *wbuf, size_t n)
>   {
> if (n == 1)
>   wbuf[0] = L'\0';
> else
> sys_mbstowcs (wbuf, n, buf);
> return wbuf;
>   }
> and sys_mbstowcs():
> size_t __reg3
> sys_mbstowcs (wchar_t * dst, size_t dlen, const char *src, size_t nms)
> {
>   mbtowc_p f_mbtowc = __MBTOWC;
>   if (f_mbtowc == __ascii_mbtowc)
> {
>   f_mbtowc = __utf8_mbtowc; <<<<< 
this 
> is ALWAYS done, no matter what charset is in use.
> }
>   return sys_cp_mbstowcs (f_mbtowc, dst, dlen, src, nms);
> }
> Since the CP1252 is an 8-bit single-byte character set with characters 
>= 
> 0x80, the '0xc7' character is always translated as '0xc7 0xf0', with the 

> '0xf0' byte indicating an invalid character in the string.
> This doesn't seem to happen when e.g. '/bin/echo' is run, although I 
> haven't stepped into the code to see what's happening.
> I do not think this is a Cygwin bug, but since the User's Guide says the 

> locale and charset can be changed on the fly, I don't know

Trouble with character sets

[Michael Shay via Cygwin]

I'm having a problem with Cygwin 3.1.4, changing the character set on the 
fly. It seems to work with Cygwin applications, but not with Win32 
applications.

I have a Korn shell script:
#!/bin/ksh

OLD_LANG="$LANG"
OLD_LC_ALL="$LC_ALL"

echo "locale on entry"
locale
echo ""

export LANG="en_US.CP1252"
export LC_ALL=en_US.CP1252

echo "locale changed to"
locale
echo ""

# Default is to run the Win32 program. Input any argument other than 
'WIN32'
# to run '/bin/echo'.

case $# in
   0 )  echo "Running WIN32 pgm"
ksh -c 'cygtest.exe ZÇ'
;;
   1 )  echo "Running Cygwin 'echo'"
ksh -c '/bin/echo ZÇ'
;;
   2 )  echo "Running WIN32 pgm"
ksh -c 'cygtest.exe ZÇ'
echo ""
echo "Running Cygwin 'echo'"
ksh -c '/bin/echo ZÇ'
;;
   * ) ;;
esac

LC_ALL="$OLD_LC_ALL"
LANG="$OLD_LANG"

and a Win32 application (attached file cygtest.cpp)

I used gdb to see what was happening in child_info_spawn::worker(), when a 
Win32 program is started using:

  rc = CreateProcessW (runpath,   /* image name w/ full path */
   cmd.wcs (wcmd),  /* what was passed to exec */
   sa,/* process security attrs */
   sa,/* thread security attrs */
   TRUE,/* inherit handles */
   c_flags,
   envblock,  /* environment */
   NULL,
   &si,
   &pi);
Specifically, 'cmd.wcs(wcmd)' invokes:

  wchar_t *wcs (wchar_t *wbuf, size_t n)
  {
if (n == 1)
  wbuf[0] = L'\0';
else
sys_mbstowcs (wbuf, n, buf);
return wbuf;
  }

and sys_mbstowcs():

size_t __reg3
sys_mbstowcs (wchar_t * dst, size_t dlen, const char *src, size_t nms)
{
  mbtowc_p f_mbtowc = __MBTOWC;
  if (f_mbtowc == __ascii_mbtowc)
{
  f_mbtowc = __utf8_mbtowc; < this 
is ALWAYS done, no matter what charset is in use.
}
  return sys_cp_mbstowcs (f_mbtowc, dst, dlen, src, nms);
}

Since the CP1252 is an 8-bit single-byte character set with characters >= 
0x80, the '0xc7' character is always translated as '0xc7 0xf0', with the 
'0xf0' byte indicating an invalid character in the string.

This doesn't seem to happen when e.g. '/bin/echo' is run, although I 
haven't stepped into the code to see what's happening.

I do not think this is a Cygwin bug, but since the User's Guide says the 
locale and charset can be changed on the fly, I don't know what's going 
awry.

Any suggestions? If you need more information, I'm happy to provide it.

Mike Shay

Here's the source for the Win32 program. I built it with Visual Studio 
2015, to get something running quickly.



  
NOTICE  from Ab Initio: This email (including any attachments) may contain 
information that is subject to confidentiality obligations or is legally 
privileged, and sender does not waive confidentiality or privilege. If received 
in error, please notify the sender, delete this email, and make no further use, 
disclosure, or distribution.  

cygtest.cpp
Description: Binary data
--
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: Please update "mingw64-x86_64-gtksourceview3.0" - the available version has a severe bug

[Michael Soegtrop]

Hi Marco,


unfortunately it will not be updated shortly.
The package is currently without an active maintainer

https://sourceware.org/pipermail/cygwin-apps/2020-March/039877.html

Are you eventually interested to adopt it ?


I am not an expert for GTK3 but I maintain the windows build of a 
largish open source project which uses GTK3 and has many CI runs a day 
each with a freshly installed cygwin, so I find out quickly if e.g. 
dependencies break. I am also roughly familiar with the cygwin packaging 
process.


So yes, if nobody else is maintaining it, I can do so. It is due time to 
give back a little bit to the cygwin project which does help me a lot 
(how can one survive on Windows without it?). I can also take care of 
the gtksourceview cygwin package (not mingw), although I have much less 
exposure to if this will work or not.


And I guess I should take care of base GTK3 as well then, both cygwin 
and mingw (of cause only if the cygwin package doesn't have a maintainer 
already).


What are the formalities?

Best regards,

Michael
--
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

Please update "mingw64-x86_64-gtksourceview3.0" - the available version has a severe bug

[Michael Soegtrop]

Dear Cygwin Team,

can you please update these packages:

mingw64-x86_64-gtksourceview3.0
mingw64-i686-gtksourceview3.0

The available version 3.24.6 has a severe bug: when a thread ends global 
objects of gtksourceview are deleted which later leads to crashes when 
the corresponding memory is reallocated, since the objects are still 
used by other threads.


This is fixed since a while, definitely in 3.24.11.

AFAIK the cygwin (not mingw) packages don't have this issue, but for 
consistency they should also be updated.


Thanks & best regards,

Michael
--
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: "tmux open terminal failed: not a terminal" in terminal emulators other than mintty

[Michael Wild via Cygwin]

On Fri, 27 Mar 2020, 14:29 Kacper Michajlow wrote:

> > You can try another pty emulator. F.e. wintty.
>
> Not really interested in some dead projects ;p
>
> Let me rephrase the question, because I misspoke.
>
> Currently Cygwin works acceptably only under Mintty as far as I can see.
> Running it from cmd or any of terminal emulators listed before result in
> sub-par performance. Even things like Home button to move cursor doesn't
> work, as originally stated tmux doesn't work and so on.
>
> Now that Windows is making improvements to their console
>
> https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/
> it may be good time to improve Cygwin's compatibility.
>
> Since my first mail I looked at git log and seen pty related changes,
> compiled latest Cygwin, but it doesn't work better and even worse, because
> mouse stopped working over ssh in tmux.
>
> That said, I guess my really questions are:
> 1. Is the goal to improve Windows console compatibility?
> 2. If yes, what is the current status and challenges?
> 3. And my original question will the tmux work? :)
>
> Projects like Windows Terminal are convenient way to have PS, CMD, Cygwin
> and its child MSYS in one window hence I am wondering if it will be
> possible without drawbacks.
>

Hi

As the maintainer of the tmux Cygwin package I have to admit that I have no
idea how to fix this. Sorry.

Kind regards

Michael
--
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: lpr sends a file to my printer but it just sits there in the print queue

[Michael Coulter]

Thanks for the suggestions.

With the help of the directions here:
https://www.itg.ias.edu/content/connect-network-printer-lpr-windows10

I was able to set up a printer port that works with /usr/bin/lpr -d 
PORT_NAME some_file.txt


No idea why the normal Windows printer did not work, as that has worked 
in the past.


-- Michael Coulter


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

lpr sends a file to my printer but it just sits there in the print queue

[Michael Coulter]

I'm running 64-bit Windows 10 with Cygwin (see attached cygcheck.out).

The lpr command is sending my file to the printer, but it never prints.  
It just sits in the Windows print queue with status "Sent to printer".


e.g.:
/usr/bin/lpr -d "ET-4500" xx.txt

If I print something else with say, Word, that document gets printed 
while the lpr job still sits there.


My printer is an Epson ET-4500.

It seems that somehow Windows or the printer needs to be told that the 
job is complete and can be printed.


Any suggestions?

Thanks,
Michael Coulter




Cygwin Configuration Diagnostics
Current System Time: Tue Jan 07 11:53:52 2020

Windows 10 Home Ver 10.0 Build 18362 

Path:   C:\mc\home\bin
C:\wp\cygsetup\wp\cygwin64\bin
C:\wp\cygsetup\wp\cygwin64\usr\local\bin
C:\wp\cygsetup\wp\cygwin64\bin
C:\windows\system32
C:\windows
C:\windows\System32\Wbem
C:\windows\System32\WindowsPowerShell\v1.0
C:\windows\System32\OpenSSH
C:\mc\home\bi
C:\Users\Michael\AppData\Local\Microsoft\WindowsApps"
C:\pkgs\MinGW\bin

Output from C:\wp\cygsetup\wp\cygwin64\bin\id.exe
UID: 197610(Michael)
GID: 197121(Michael)
197121(Michael)
114(Local account and member of Administrators group)
544(Administrators)
545(Users)
4(INTERACTIVE)
66049(CONSOLE LOGON)
11(Authenticated Users)
15(This Organization)
113(Local account)
4095(CurrentSession)
66048(LOCAL)
262154(NTLM Authentication)
405504(High Mandatory Level)

SysDir: C:\windows\system32
WinDir: C:\windows

USER = 'Michael'
CYGWIN = 'nodosfilewarning'
HOME = '/cygdrive/c/mc/home'

_ = '/usr/bin/cygcheck'
MACRIUM_17_FILENAME6 = 'AFFC91AF1120FAF6-05-05.mrimg'
OnlineServices = 'Online Services'
MACRIUM_16_METHOD1 = '0'
MACRIUM_16_FILENAME2 = 'AFFC91AF1120FAF6-01-01.mrimg'
MACRIUM_17_AES = '0'
MACRIUM_17_METHOD10 = '1'
MACRIUM_16_APPENDTYPE = '1'
MACRIUM_16_DRIVE_PARTITION2 = '0, 1'
MACRIUM_16_METHOD8 = '1'
MACRIUM_16_INCREMENT5 = '4'
MACRIUM_16_FILEPATH7 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-06-06.mrimg'
COMSPEC = 'C:\windows\system32\cmd.exe'
MACRIUM_17_FILEPATH5 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-04-04.mrimg'
ROOT_DIR = '/cygdrive/c'
TERM = 'vt100'
LINES = '24'
PSModulePath = 'C:\Program 
Files\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerShell\v1.0\Modules'
MACRIUM_16_INCREMENT2 = '1'
MACRIUM_17_INCREMENT5 = '4'
MACRIUM_16_FILEPATH9 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-08-08.mrimg'
MACRIUM_16_FILENAME5 = 'AFFC91AF1120FAF6-04-04.mrimg'
HOMEPATH = '\Users\Michael'
MACRIUM_17_METHOD8 = '1'
COMPUTERNAME = 'MICHAEL5'
MACRIUM_16_FILEPATH5 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-04-04.mrimg'
MKSHOME = '/cygdrive/c/wp/mks/home'
MACRIUM_17_METHOD4 = '1'
MACRIUM_17_FILEPATH10 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-09-09.mrimg'
MACRIUM_17_FILEPATH7 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-06-06.mrimg'
MACRIUM_17_METHOD = '1'
USERPROFILE = 'C:\Users\Michael'
MACRIUM_17_FILENAME4 = 'AFFC91AF1120FAF6-03-03.mrimg'
MACRIUM_17_METHOD6 = '1'
FCEDIT = '/cygdrive/c/mc/home/bin/vi'
MACRIUM_16_FILENAME7 = 'AFFC91AF1120FAF6-06-06.mrimg'
MACRIUM_17_DRIVE_PARTITION5 = '0, 5'
MACRIUM_17_INTELLIGENT = '1'
USERDOMAIN_ROAMINGPROFILE = 'MICHAEL5'
MACRIUM_17_METHOD2 = '1'
MACRIUM_16_INCREMENT4 = '3'
MACRIUM_16_INCREMENT9 = '8'
MACRIUM_17_INCREMENT7 = '6'
PROCESSOR_REVISION = '9e0a'
MACRIUM_17_DRIVE_PARTITION2 = '0, 1'
DriverData = 'C:\Windows\System32\Drivers\DriverData'
MACRIUM_16_METHOD9 = '1'
MACRIUM_17_FILENAME11 = 'AFFC91AF1120FAF6-10-10.mrimg'
MACRIUM_16_BACKUP_TYPE = '0'
MACRIUM_17_FILENAME8 = 'AFFC91AF1120FAF6-07-07.mrimg'
platformcode = '1M'
PUBLIC = 'C:\Users\Public'
MACRIUM_16_METHOD10 = '1'
MACRIUM_16_IMAGEID = 'AFFC91AF1120FAF6'
MACRIUM_17_FILEPATH9 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-08-08.mrimg'
MACRIUM_16_COMPRESSION = '1'
MACRIUM_17_FILENAME3 = 'AFFC91AF1120FAF6-02-02.mrimg'
MACRIUM_17_IMAGEID = 'AFFC91AF1120FAF6'
MACRIUM_17_FILEPATH1 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-00-00.mrimg'
PROGRAMFILES = 'C:\Program Files'
MACRIUM_16_FILEPATH3 = 
'L:\backups\michael5\m5_dailies\AFFC91AF1120FAF6-02-02.mrimg'
ALLUSERSPROFILE = 'C:\ProgramData'
MACRIUM_16_CURRENT_INCREMENT = '9'
MACRIUM_17_COMPRESSION = '1&

Re: Cygwin 3.1.x fails if I have the use legacy console box checked in Windows 10

[Michael D. Lawler]

It looks like the changes between 3/27 and 3/31 were to support 
24-bit color in the normal console in 1703 or later and to fake the 
support for legacy console.  I can't currently compile anything, but 
I'm guessing that something went wrong with that change for legacy 
console.  The other changes seem less likely to cause the problem 
based on reading the diff.


At 10:34 PM 11/4/2019, you wrote:
I'm using Win 10 1903 build 18362.449 and if I check the use legacy 
console box under properties options in the console then I get the 
following error with ssh built with cygwin.
  0 [main] ssh 1942 C:\Program Files\OpenSSH\bin\ssh.exe: *** 
fatal error - couldn't initialize fd 0 for /dev/cons0
   5898 [main] ssh 1942 cygwin_exception::open_stackdumpfile: 
Dumping stack trace to ssh.exe.stackdump



Stack trace:
FrameFunctionArgs
001  00180060B7E (00180267ED8, 0018025A1B9, 000, 000BA50)
001  00180049249 (0018006CEBF, , 
000, 000CB00)

001  00180049282 (000, 0018035FC20, 000, 000CB30)
001  0018005ABFC (000CC70, 000, 001800D1BA2, 000CC70)
00180342D08  0018005AD46 (00100464280, 00180221860, 
FEFF552BFF677272, 000)

000CCD0  00180049A0C (000, 000, 000, 000)
000  00180048353 (000, 000, 000, 000)
000FFF0  00180048404 (000, 000, 000, 000)
End of stack trace


If I use 3.07 this works.  Also if I use the March 27 2019 snapshot 
it works, but if I use the March 31 2019 or later snapshot I get the 
above error.  I couldn't find anything that said that Cygwin now 
didn't support the legacy console thus I'm reporting this issue.


--
Michael D. Lawler
email mailto:mdlaw...@lawlers.us


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


--
Michael D. Lawler
email mailto:mdlaw...@lawlers.us


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

Cygwin 3.1.x fails if I have the use legacy console box checked in Windows 10

[Michael D. Lawler]

I'm using Win 10 1903 build 18362.449 and if I check the use legacy 
console box under properties options in the console then I get the 
following error with ssh built with cygwin.
  0 [main] ssh 1942 C:\Program Files\OpenSSH\bin\ssh.exe: *** 
fatal error - couldn't initialize fd 0 for /dev/cons0
   5898 [main] ssh 1942 cygwin_exception::open_stackdumpfile: 
Dumping stack trace to ssh.exe.stackdump



Stack trace:
FrameFunctionArgs
001  00180060B7E (00180267ED8, 0018025A1B9, 000, 000BA50)
001  00180049249 (0018006CEBF, , 000, 
000CB00)

001  00180049282 (000, 0018035FC20, 000, 000CB30)
001  0018005ABFC (000CC70, 000, 001800D1BA2, 000CC70)
00180342D08  0018005AD46 (00100464280, 00180221860, FEFF552BFF677272, 
000)

000CCD0  00180049A0C (000, 000, 000, 000)
000  00180048353 (000, 000, 000, 000)
000FFF0  00180048404 (000, 000, 000, 000)
End of stack trace


If I use 3.07 this works.  Also if I use the March 27 2019 snapshot 
it works, but if I use the March 31 2019 or later snapshot I get the 
above error.  I couldn't find anything that said that Cygwin now 
didn't support the legacy console thus I'm reporting this issue.


--
Michael D. Lawler
email mailto:mdlaw...@lawlers.us


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

RE: How can I determine why gdb throws unknown exceptions when debugging programs with threads on my Cygwin installation?

[Soegtrop, Michael]

Dear Jay,

> On the advice of Jon Turney, I ran a "bt f" command after gdb caught the
> exception, and it appears that a Trend Micro dll  (TmUmEvt64.dll) is where the
> error occurs:

Since the message with a similar problem I posted is from April 2016, it would 
also make sense to report this to Trend Micro. Maybe they can manage to fix 
this bug before another 3 1/2 years are over.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: How can I determine why gdb throws unknown exceptions when debugging programs with threads on my Cygwin installation?

[Soegtrop, Michael]

Dear Jon,

It has been reported in the past that antivirus software from Trend Micro 
result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().

See: 
http://cygwin.1069669.n5.nabble.com/XWin-startup-crash-x86-64-Windows-10-td126544.html#a126561

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Michael Haubenwallner]

On 10/16/19 4:35 PM, Takashi Yano wrote:
> On Mon, 14 Oct 2019 13:07:22 +0200
> Michael Haubenwallner wrote:
>>> haubi@linuxbox ~ $ ssh -t cygwin2016 hostname; hostname; ssh -t cygwin2016 
>>> hostname
> 
> By the way, why do you specify -t option for ssh?
> Without -t option, that will work as you expected.
> 

Using ssh here is just the sample.  The real project is the Gentoo
Linux package manager named "portage", which does open a PTY for each
build task.  I'm not into it's details, but my guess is to have more
control over some package's build system beyond just redirecting stdin,
stdout and stderr.

/haubi/

PS: In case you wonder why using a Linux package manager on Cygwin:
There is the Gentoo Prefix subproject, that allows to install and manage
the Gentoo package set within some directory without the need for chroot
or even root permission, on top of any POSIXish platform, not just Linux.

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Michael Haubenwallner]

On 10/11/19 11:24 AM, Takashi Yano wrote:
> Hi Michael,
> 
> On Thu, 10 Oct 2019 12:43:56 +0200
> Michael Haubenwallner wrote:
>> I'm encountering another strange behaviour I do not remember to have seen 
>> before:
>>
>> Using ssh from some Linux xterm into the Cygwin sshd running on Server 2019
>> does clear the current terminal content as if /usr/bin/clear was executed.
> 
> This is intentional behaviour.
> 
> The pseudo console has its own screen buffer behind, and redraws
> the screen based on the screen buffer at undetermined timing.> The screen 
> buffer is empty at the beginning, so the screen should
> be cleared at the opening of the pty so that the real screen and
> the screen buffer are synchronozed.
> 
> The clear screen is prevented when TERM=dumb, so you can see what
> happens if clear screen is not done by following steps.> 
> 1)  Execute ls or ps to draw something to screen.
> 2) env TERM=dumb ssh 
> 3) Execute cmd.exe.

Well... even that one is counter intuitive regarding the 'Last login' line.
After login into Cygwin sshd, the 'Last login' line is not shown:

haubi@linuxbox ~ $ ssh cygwin2019

> 
> haubi@cygwin2019 ~
> $
> 
> 
> 
> 
> 
> 
> 


When starting cmd, the terminal does loose colors, and the 'Last login'
line suddenly is shown as first line:

> Last login: Mon Oct 14 12:30:52 2019 from 192.168.56.1
> 
> haubi@cygwin2019 ~
> $ cmd
> Microsoft Windows [Version 10.0.17763.805]
> (c) 2018 Microsoft Corporation. All rights reserved.
> 
> C:\cygwin64\home\haubi> 
> 
> 


However, with TERM=dumb, the terminal content is:

> {some output from previous linux commands}
> {some output}
> {some output}
> {some output}
> {some output}
> haubi@linuxbox ~ $ TERM=dumb ssh cygwin2019
> Last login: Mon Oct 14 12:37:24 2019 from 192.168.56.1
> 
> haubi@cygwin2019 ~
> $ 


And when cmd was started:

> Last login: Mon Oct 14 12:37:24 2019 from 192.168.56.1
> 
> haubi@cygwin2019 ~
> $ cmd
> Microsoft Windows [Version 10.0.17763.805]
> (c) 2018 Microsoft Corporation. All rights reserved.
> 
> C:\cygwin64\home\haubi>
> 
> 


Actually I do prefer the TERM=dumb behaviour, having the current terminal
buffer content get redrawn at line 1 when cmd is started only, not when
running just Cygwin programs.

My real problem is more sophisticated, and boils down to the creation of some
pty's in a row, each having some commands run inside, and I do expect to see
the output of each command while the series runs and when done, much like:


> {some output from previous linux commands}
> {some output}
> {some output}
> haubi@linuxbox ~ $ ssh -t cygwin2016 hostname; hostname; ssh -t cygwin2016 
> hostname
> cygwin2016
> Connection to cygwin2016 closed.
> linuxbox
> cygwin2016
> Connection to cygwin2016 closed.
> haubi@linuxbox ~ $


And looking at the code actually makes me belive that even emacs does have
troubles when the clear screen code is emitted on pty creation...

Thanks!
/haubi/ (in hope that "embedding the screen shots" does work)

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Michael Haubenwallner]

Hi Takashi,

On 9/22/19 4:11 PM, Ken Brown wrote:
 
> There have been a lot of changes in the PTY code since
> cygwin-3.1.0-0.5.  Please test!

I'm encountering another strange behaviour I do not remember to have seen 
before:

Using ssh from some Linux xterm into the Cygwin sshd running on Server 2019
does clear the current terminal content as if /usr/bin/clear was executed.

Even moving /usr/bin/screen away does not make a difference, and it actually
does look like creating a new PTY does emit some 'clear screen' TTY code
(whatever that exactly is).

This does neither happen on Server 2012r2, nor with cygwin-3.0.7 on Server 2019.

Thanks!
/haubi/

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Michael Haubenwallner]

Hi Takashi,

On 9/22/19 4:11 PM, Ken Brown wrote:

> There have been a lot of changes in the PTY code since
> cygwin-3.1.0-0.5.  Please test!

seems there is another issue related to new PTY code:

* I'm logged into some Server 2012r2 box via Cygwin sshd from Linux xterm,
* export EDITOR=vim # but same problem with EDITOR=emacs
* cd to some git project
* git rebase -i HEAD^
* Ctrl-Z, to temporarily return to shell prompt

Both the editor and the git processes seem to be suspended, but the
shell does not react nor show the prompt in any way, although further
keyboard input characters are displayed.

In a different (ssh) session, with 'ps' I can see the 'git' and 'vim'
processes to be suspended, as in having a leading 'S':
$ ps | grep pty0
S   51349   51348   51346  27448  pty0  197609 14:37:21 /usr/bin/vim
S   51346   51176   51346  11280  pty0  197609 14:37:20 /usr/bin/git
51176   51174   51176  39632  pty0  197609 14:26:41 /usr/bin/bash
S   51348   51346   51346  30960  pty0  197609 14:37:21 
/usr/libexec/git-core/git

Resuming these processes with 'kill -CONT 51349 51346 51348' seems to work so 
far,
but when quitting the editor (using :q), the vim process is gone, but both git
processes do consume 100% (one single cpu) each, without any further result.

Any idea?

Thanks!
/haubi/

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Michael Haubenwallner]

Hi,

On 9/22/19 4:11 PM, Ken Brown wrote:
> The following packages have been uploaded to the Cygwin distribution
> as test releases:

so I do have some Azure Pipelines running, which perform an automated
Cygwin setup from scratch before building my pet project there.

But then, I also do want to autotest cygwin1.dll itself a little, so I want
to use cygwin TEST versions or similar.  Because setup.exe does not
support that right now from the commandline, I do use snapshot builds of
cygwin1.dll, because identifying the last snapshot felt easier than
identifying the last test release.
However, I do see the last snapshot dating back to 2019-08-19, which is
rather old compared to test releases seen since then.

Is there something broken with building snapshots, or is it just not automated?

Thanks!
/haubi/

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.4 (TEST)

[Michael Haubenwallner]

Hi Mark,

On 9/14/19 12:08 AM, Mark Geisert wrote:
> Michael Haubenwallner wrote:
>> On 9/5/19 3:16 PM, Ken Brown wrote:
>>> The following packages have been uploaded to the Cygwin distribution
>>> as test releases:
>>>
>>> * cygwin-3.1.0-0.4
>>> * cygwin-devel-3.1.0-0.4
>>> * cygwin-doc-3.1.0-0.4
>>
>>> - New APIs: sched_getaffinity, sched_setaffinity, pthread_getaffinity_np,
>>>    pthread_setaffinity_np, plus CPU_SET macros.
>>
>> There's some problem with , seen with boost-1.71.0/bootstrap.sh,
>> even after tweaking their sysinfo.cpp like this to include :
>>

>> Actually it is boost's fault to include  before defining 
>> _GNU_SOURCE,
>> but it feels like Cygwin should *not* define CPU_COUNT_S without _GNU_SOURCE.

> Thanks for the problem report.  Blame me for this one.  I believe your last
> suggestion is the correct fix but I want to double-check something additional.
> Shortly I'll submit a patch to correct this one way or another.

Fix does work as expected, thanks!
/haubi/

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.4 (TEST)

[Michael Haubenwallner]

On 9/5/19 3:16 PM, Ken Brown wrote:
> The following packages have been uploaded to the Cygwin distribution
> as test releases:
> 
> * cygwin-3.1.0-0.4
> * cygwin-devel-3.1.0-0.4
> * cygwin-doc-3.1.0-0.4

> - New APIs: sched_getaffinity, sched_setaffinity, pthread_getaffinity_np,
>   pthread_setaffinity_np, plus CPU_SET macros.

There's some problem with , seen with boost-1.71.0/bootstrap.sh,
even after tweaking their sysinfo.cpp like this to include :

-#if defined(OS_LINUX)
+#if defined(OS_LINUX) || defined(OS_CYGWIN)

This boils down to a test case like this that succeeds to *compile* on Linux,
although requires _GNU_SOURCE to be defined earlier to perform anything useful:

$ cat > test.cc <<'EOF'
#ifdef LIKE_BOOST
# include 
# define _GNU_SOURCE
#endif
#include 
int main()
{
#if defined(CPU_COUNT_S)
  ::cpu_set_t cpu_set;
  if (::sched_getaffinity(0, sizeof(cpu_set_t), &cpu_set) == 0)
{
  return CPU_COUNT_S(sizeof(cpu_set_t), &cpu_set);
}
#endif
  return 0;
}
EOF

Both these commands fail to compile on Cygwin with identical error:
$ g++ test.c -DLIKE_BOOST
$ g++ test.c
test.c: In function ‘main’:
test.c:10:7: warning: implicit declaration of function ‘sched_getaffinity’; did 
you mean ‘sched_getparam’? [-Wimplicit-function-declaration]
   if (sched_getaffinity(0, sizeof(cpu_set_t), &cpu_set) == 0)
   ^
   sched_getparam

Actually it is boost's fault to include  before defining _GNU_SOURCE,
but it feels like Cygwin should *not* define CPU_COUNT_S without _GNU_SOURCE.

Thoughts?
/haubi/

PS: This does work as expected:
$ g++ test.c -D_GNU_SOURCE

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