Re: cyg-x install error
thank you very much for what to look for. i will report status after checking. On September 13, 2024 9:49:44 PM PDT, Brian Inglis via Cygwin wrote: >On 2024-09-13 18:06, S. Cowles via Cygwin wrote: >> >> On Fri, 13 Sep 2024, Brian Inglis via Cygwin wrote: >>> On 2024-09-13 14:02, S. Cowles via Cygwin wrote: >>>> >>>> i have a clean install of cygwin on a win11pro box. when i install cyg-x >>>> (via https://x.cygwin.com/docs/ug/setup.html#setup-cygwin-x-installing), i >>>> get the following error: >>>> >>>> Package: _/xinit >>>> xinit.sh exit code 3 >>> >>> Where are you seeing this error? >> >> final error reporting window of setup-x86_64.ext instance >> >> >>>> the result of the error is no access to any cyg-x apps via start menu, >>>> etc. what is the proper way to fix this error? >>> >>> What does it show in /var/log/setup.log.full? >> >> >> attached. >> >> relevant lines appear to be: >> mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start >> Menu/Programs/Cygwin-X/XWin Server.lnk" failed; does the target directory >> exist? >> mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start >> Menu/Programs/Cygwin-X/User script.lnk" failed; does the target directory >> exist? >> dir permissions are reported as: >> d---rwxr-x+ 1 userxyz Administrators 0 May 20 10:06 Cygwin-X/ >> suggestions? > >Problem is that directory is not created with a User DACL, so its parent >probably also lacks a User DACL. > >First check the X11 directories are okay: > >$ ls -gloR /etc/X11 >/etc/X11: >total 23 >drwxr-xr-x 10 Jun 15 18:15 app-defaults >drwxr-xr-x 10 Aug 2 20:25 fontpath.d >-rw-r--r-- 1 3887 Jun 15 18:20 system.XWinrc >drwxr-xr-x 10 Dec 26 2022 xinit >-rwxr--r-- 1 884 Feb 13 2015 Xloadimage >-rw-r--r-- 1 547 Dec 26 2022 Xmodmap >-rw-r--r-- 1 493 Dec 26 2022 Xresources >drwxrwxr-x 10 Jun 15 18:15 xsm > >/etc/X11/app-defaults: >total 138 >-rw-r--r-- 1 9870 Apr 27 11:51 Editres >-rw-r--r-- 1 2751 Apr 27 11:51 Editres-color >-rw-r--r-- 1 2872 Jul 16 2023 GXditview >-rw-r--r-- 1 601 Jul 16 2023 GXditview-color >-rw-r--r-- 1 3184 Dec 18 2022 Viewres >-rw-r--r-- 1 973 Dec 18 2022 Viewres-color >-rw-r--r-- 1 22916 May 20 2023 XCalc >-rw-r--r-- 1 11573 May 20 2023 XCalc-color >-rw-r--r-- 1 4086 Aug 12 2022 XClipboard >-rw-r--r-- 1 754 Dec 18 2022 Xfd >-rw-r--r-- 1 4928 Apr 27 12:17 XFontSel >-rw-r--r-- 1 106 Apr 27 12:12 XLoad >-rw-r--r-- 1 6148 Apr 27 12:13 Xman >-rw-r--r-- 1 3871 Apr 27 12:47 XSm >-rw-r--r-- 1 11515 Jan 25 2024 XTerm >-rw-r--r-- 1 5826 Jan 25 2024 XTerm-color > >/etc/X11/fontpath.d: >total 7 >lrwxrwxrwx 1 30 Apr 17 2018 urw-fonts -> /usr/share/X11/fonts/urw-fonts >lrwxrwxrwx 1 27 Jun 15 18:13 'xorg-x11-fonts-100dpi:unscaled:pri=30' -> >/usr/share/X11/fonts/100dpi >lrwxrwxrwx 1 26 Jun 15 18:13 'xorg-x11-fonts-75dpi:unscaled:pri=20' -> >/usr/share/X11/fonts/75dpi >lrwxrwxrwx 1 25 Jun 15 18:13 'xorg-x11-fonts-misc:unscaled:pri=10' -> >/usr/share/X11/fonts/misc >lrwxrwxrwx 1 26 Jun 15 18:13 xorg-x11-fonts-Type1 -> >/usr/share/X11/fonts/Type1 > >/etc/X11/xinit: >total 28 >-rwxr-xr-x 1 3770 Dec 26 2022 startxwinrc >-rwxr-xr-x 1 2692 Dec 26 2022 Xclients >drwxr-xr-x 10 Apr 24 2023 Xclients.d >-rwxr-xr-x 1 1486 Dec 26 2022 xinitrc >drwxr-xr-x 10 Mar 10 2024 xinitrc.d >-rw-r--r-- 1 1870 Dec 26 2022 xinitrc-common >-rwxr-xr-x 1 4740 Dec 26 2022 Xsession > >/etc/X11/xinit/Xclients.d: >total 4 >-rwxrwxr-x 1 110 Apr 1 2023 Xclients.openbox.sh >-rwxrwxr-x 1 177 Apr 1 2023 Xclients.openbox-gnome.sh >-rwxrwxr-x 1 122 Apr 1 2023 Xclients.openbox-kde.sh >-rwxr-xr-x 1 121 Dec 18 2022 Xclients.xinit-compat.sh > >/etc/X11/xinit/xinitrc.d: >total 3 >-rwxr-xr-x 1 558 Feb 24 2024 00-start-message-bus.sh >-rwxr-xr-x 1 543 Dec 26 2022 localuser.sh >-rwxr-xr-x 1 537 Sep 4 2017 xdg-user-dirs.sh > >/etc/X11/xsm: >total 1 >-rw-r--r-- 1 77 Apr 27 12:47 system.xsm > >Next go to the Cygwin-X directory and check up the parents in the path until >you can see drwxr[-w]xr[-w]x, and check that directory has User DACLs e.g. >[sanitized]: > >$ lsattr -d /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ >/proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ Readonly, Notindexed >$ls -dl /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ >drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Dec 7 2019 >/pr
Re: cyg-x install error
On 2024-09-13 18:06, S. Cowles via Cygwin wrote: On Fri, 13 Sep 2024, Brian Inglis via Cygwin wrote: On 2024-09-13 14:02, S. Cowles via Cygwin wrote: i have a clean install of cygwin on a win11pro box. when i install cyg-x (via https://x.cygwin.com/docs/ug/setup.html#setup-cygwin-x-installing), i get the following error: Package: _/xinit xinit.sh exit code 3 Where are you seeing this error? final error reporting window of setup-x86_64.ext instance the result of the error is no access to any cyg-x apps via start menu, etc. what is the proper way to fix this error? What does it show in /var/log/setup.log.full? attached. relevant lines appear to be: mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin-X/XWin Server.lnk" failed; does the target directory exist? mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin-X/User script.lnk" failed; does the target directory exist? dir permissions are reported as: d---rwxr-x+ 1 userxyz Administrators 0 May 20 10:06 Cygwin-X/ suggestions? Problem is that directory is not created with a User DACL, so its parent probably also lacks a User DACL. First check the X11 directories are okay: $ ls -gloR /etc/X11 /etc/X11: total 23 drwxr-xr-x 10 Jun 15 18:15 app-defaults drwxr-xr-x 10 Aug 2 20:25 fontpath.d -rw-r--r-- 1 3887 Jun 15 18:20 system.XWinrc drwxr-xr-x 10 Dec 26 2022 xinit -rwxr--r-- 1 884 Feb 13 2015 Xloadimage -rw-r--r-- 1 547 Dec 26 2022 Xmodmap -rw-r--r-- 1 493 Dec 26 2022 Xresources drwxrwxr-x 10 Jun 15 18:15 xsm /etc/X11/app-defaults: total 138 -rw-r--r-- 1 9870 Apr 27 11:51 Editres -rw-r--r-- 1 2751 Apr 27 11:51 Editres-color -rw-r--r-- 1 2872 Jul 16 2023 GXditview -rw-r--r-- 1 601 Jul 16 2023 GXditview-color -rw-r--r-- 1 3184 Dec 18 2022 Viewres -rw-r--r-- 1 973 Dec 18 2022 Viewres-color -rw-r--r-- 1 22916 May 20 2023 XCalc -rw-r--r-- 1 11573 May 20 2023 XCalc-color -rw-r--r-- 1 4086 Aug 12 2022 XClipboard -rw-r--r-- 1 754 Dec 18 2022 Xfd -rw-r--r-- 1 4928 Apr 27 12:17 XFontSel -rw-r--r-- 1 106 Apr 27 12:12 XLoad -rw-r--r-- 1 6148 Apr 27 12:13 Xman -rw-r--r-- 1 3871 Apr 27 12:47 XSm -rw-r--r-- 1 11515 Jan 25 2024 XTerm -rw-r--r-- 1 5826 Jan 25 2024 XTerm-color /etc/X11/fontpath.d: total 7 lrwxrwxrwx 1 30 Apr 17 2018 urw-fonts -> /usr/share/X11/fonts/urw-fonts lrwxrwxrwx 1 27 Jun 15 18:13 'xorg-x11-fonts-100dpi:unscaled:pri=30' -> /usr/share/X11/fonts/100dpi lrwxrwxrwx 1 26 Jun 15 18:13 'xorg-x11-fonts-75dpi:unscaled:pri=20' -> /usr/share/X11/fonts/75dpi lrwxrwxrwx 1 25 Jun 15 18:13 'xorg-x11-fonts-misc:unscaled:pri=10' -> /usr/share/X11/fonts/misc lrwxrwxrwx 1 26 Jun 15 18:13 xorg-x11-fonts-Type1 -> /usr/share/X11/fonts/Type1 /etc/X11/xinit: total 28 -rwxr-xr-x 1 3770 Dec 26 2022 startxwinrc -rwxr-xr-x 1 2692 Dec 26 2022 Xclients drwxr-xr-x 10 Apr 24 2023 Xclients.d -rwxr-xr-x 1 1486 Dec 26 2022 xinitrc drwxr-xr-x 10 Mar 10 2024 xinitrc.d -rw-r--r-- 1 1870 Dec 26 2022 xinitrc-common -rwxr-xr-x 1 4740 Dec 26 2022 Xsession /etc/X11/xinit/Xclients.d: total 4 -rwxrwxr-x 1 110 Apr 1 2023 Xclients.openbox.sh -rwxrwxr-x 1 177 Apr 1 2023 Xclients.openbox-gnome.sh -rwxrwxr-x 1 122 Apr 1 2023 Xclients.openbox-kde.sh -rwxr-xr-x 1 121 Dec 18 2022 Xclients.xinit-compat.sh /etc/X11/xinit/xinitrc.d: total 3 -rwxr-xr-x 1 558 Feb 24 2024 00-start-message-bus.sh -rwxr-xr-x 1 543 Dec 26 2022 localuser.sh -rwxr-xr-x 1 537 Sep 4 2017 xdg-user-dirs.sh /etc/X11/xsm: total 1 -rw-r--r-- 1 77 Apr 27 12:47 system.xsm Next go to the Cygwin-X directory and check up the parents in the path until you can see drwxr[-w]xr[-w]x, and check that directory has User DACLs e.g. [sanitized]: $ lsattr -d /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ Readonly, Notindexed $ls -dl /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Dec 7 2019 /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ $ getfacl /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ # file: /proc/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/ # owner: SYSTEM # group: SYSTEM user::rwx group::r-x group:Administrators:rwx#effective:r-x group:Users:r-x mask::r-x other::r-x default:user::rwx <<< default:user:$USER:--- <<< default:user:$Admin:--- <<< default:group::--- default:group:Administrators:rwx#effective:r-x default:group:Users:r-x default:mask::r-x default:other::r-x $ icacls C:/ProgramData/Microsoft/Windows/Start?Menu C:/ProgramData/Microsoft/Windows/Start Menu $HOSTNAME/$USER:(OI)(CI)(IO)(DE,DC) $HOSTNAME/$Admin:(OI)(CI)(IO)(DE,DC) NT AUTHORITY/SYSTEM:(I)(
Re: cyg-x install error
On Fri, 13 Sep 2024, Brian Inglis via Cygwin wrote: On 2024-09-13 14:02, S. Cowles via Cygwin wrote: i have a clean install of cygwin on a win11pro box. when i install cyg-x (via https://x.cygwin.com/docs/ug/setup.html#setup-cygwin-x-installing), i get the following error: Package: _/xinit xinit.sh exit code 3 Where are you seeing this error? final error reporting window of setup-x86_64.ext instance the result of the error is no access to any cyg-x apps via start menu, etc. what is the proper way to fix this error? What does it show in /var/log/setup.log.full? attached. relevant lines appear to be: mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin-X/XWin Server.lnk" failed; does the target directory exist? mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin-X/User script.lnk" failed; does the target directory exist? dir permissions are reported as: d---rwxr-x+ 1 userxyz Administrators 0 May 20 10:06 Cygwin-X/ i was able to do a simple chmod 775 ./Cygwin-X and remove the Cygwin-X directory. next, i reran cygwin setup with no specified packages (to go theough the postinstall routine) and got the error: Package: _/Unknown package xinit.sh exit code 3 at this point, /var/log/setup.log.full reports that Cygwin-X dir exists and fails, again. i then reset permissions and removed the Cygwin-X dir. next, i ran cygwin setup to reinstall package xinit, and setup failed yet again with the error: Package: _/xinit xinit.sh exit code 3 and ./Cygwin-X was created again. suggestions? 2024/09/13 15:47:49 Starting cygwin install, version 2.932 2024/09/13 15:47:49 User has backup/restore rights 2024/09/13 15:47:49 User has symlink creation right 2024/09/13 15:47:49 Current Directory: C:\Users\xyz\Desktop\cygrepo Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. 2024/09/13 15:47:51 source: network install 2024/09/13 15:47:52 root: C:\cygwin64 system 2024/09/13 15:47:52 Changing gid to Administrators 2024/09/13 15:47:52 Selected local directory: C:\Users\xyz\Desktop\cygrepo 2024/09/13 15:47:53 net: Preconfig Loaded cached mirror list User-Agent: default is "Cygwin-Setup/2.932 (Windows NT 10.0.22631;x86_64;0409;SymLinkPriv)" Request for URL https://cygwin.com/mirrors.lst satisfied from cache Fetched URL: https://cygwin.com/mirrors.lst 2024/09/13 15:47:54 site: https://mirrors.xmission.com/cygwin/ 2024/09/13 15:47:54 site: https://mirror.clarkson.edu/cygwin/ 2024/09/13 15:47:54 site: http://www.gtlib.gatech.edu/pub/cygwin/ 2024/09/13 15:47:54 site: https://mirrors.rit.edu/cygwin/ 2024/09/13 15:47:54 site: https://mirror.cs.vt.edu/pub/cygwin/cygwin/ 2024/09/13 15:47:54 site: https://mirrors.sonic.net/cygwin/ 2024/09/13 15:47:54 site: https://mirrors.kernel.org/sourceware/cygwin/ Request for URL https://mirrors.xmission.com/cygwin/x86_64/setup.zst.sig satisfied from cache Fetched URL: https://mirrors.xmission.com/cygwin/x86_64/setup.zst.sig Request for URL https://mirrors.xmission.com/cygwin/x86_64/setup.zst satisfied from cache Fetched URL: https://mirrors.xmission.com/cygwin/x86_64/setup.zst signature: sig_type 0, pk_alg 1, hash_alg 8 signature: tried key cygwin, returned 0x Success Request for URL https://mirror.clarkson.edu/cygwin/x86_64/setup.zst.sig satisfied from cache Fetched URL: https://mirror.clarkson.edu/cygwin/x86_64/setup.zst.sig Request for URL https://mirror.clarkson.edu/cygwin/x86_64/setup.zst satisfied from cache Fetched URL: https://mirror.clarkson.edu/cygwin/x86_64/setup.zst signature: sig_type 0, pk_alg 1, hash_alg 8 signature: tried key cygwin, returned 0x Success Request for URL http://www.gtlib.gatech.edu/pub/cygwin/x86_64/setup.zst.sig satisfied from cache Fetched URL: http://www.gtlib.gatech.edu/pub/cygwin/x86_64/setup.zst.sig Request for URL http://www.gtlib.gatech.edu/pub/cygwin/x86_64/setup.zst satisfied from cache Fetched URL: http://www.gtlib.gatech.edu/pub/cygwin/x86_64/setup.zst signature: sig_type 0, pk_alg 1, hash_alg 8 signature: tried key cygwin, returned 0x Success Request for URL https://mirrors.rit.edu/cygwin/x86_64/setup.zst.sig satisfied from cache Fetched URL: https://mirrors.rit.edu/cygwin/x86_64/setup.zst.sig Request for URL https://mirrors.rit.edu/cygwin/x86_64/setup.zst satisfied from cache Fetched URL: https://mirrors.rit.edu/cygwin/x86_64/setup.zst signature: sig_type 0, pk_alg 1, hash_alg 8 signature: tried key cygwin, returned 0x Success Request for URL https://mirror.cs.vt.edu/pub/cygwin/cygwin/x86_64/setup.zst.sig satisfied from cache Fetched URL: https://mirror.cs.vt.edu/pub/cygwin/cygwin/x86_64/setup.zst.sig Request for URL https://mirror.cs.vt.edu/pub/cygwin/cygwin/x86_64/setup.zst satisfied from cache Fetched URL: https://mirror.cs.vt.edu/pub/cygwin/cygwin/x86_64/setup.zst signatur
Re: cyg-x install error
On 2024-09-13 14:02, S. Cowles via Cygwin wrote: i have a clean install of cygwin on a win11pro box. when i install cyg-x (via https://x.cygwin.com/docs/ug/setup.html#setup-cygwin-x-installing), i get the following error: Package: _/xinit xinit.sh exit code 3 Where are you seeing this error? the result of the error is no access to any cyg-x apps via start menu, etc. what is the proper way to fix this error? What does it show in /var/log/setup.log.full? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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
cyg-x install error
i have a clean install of cygwin on a win11pro box. when i install cyg-x (via https://x.cygwin.com/docs/ug/setup.html#setup-cygwin-x-installing), i get the following error: Package: _/xinit xinit.sh exit code 3 the result of the error is no access to any cyg-x apps via start menu, etc. what is the proper way to fix this error? -- 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: Advice sought: Cygwin or gcc or ???: unable to figure out odd gcc error message [WITHDRAWN]
Richard via Cygwin writes: > As anticipated, after further investigation, it is NOT a > Cygwin-related issue, hence I withdraw my request with apologies for > noise. You didn't say what you are trying to achieve, but since the exercise seems to be to learn something about Linux kernel (module) programming, you could save yourself some bother by doing this on an actual Linux system, in a Linux VM or even in Windows' subsystem for Linux. While you might have pacified the Cygwin compiler for now by changing sone options, you would really need to have a proper cross-compiler to Linux for any of this to result in an actual working Linux kernel module. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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
Advice sought: Cygwin or gcc or ???: unable to figure out odd gcc error message [WITHDRAWN]
Sirs: As anticipated, after further investigation, it is NOT a Cygwin-related issue, hence I withdraw my request with apologies for noise. FWIW and benefit of future readers (or victims), let it be noted that the compiler is reacting to the architecture-related parameter '-mmodel=kernel', as it clearly states in its error message... Once adjusted, there is no issue left. ;) -- 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
Advice sought: Cygwin or gcc or ???: unable to figure out odd gcc error message
Sirs: Please note initially that the error indicated occurs systematically in the actual project, but it was reproduced here using a simpler demonstration case for documentation. I might have to defer to www.kernel.org || gcc.gnu.org depending upon your comments, as I feel that it is not Cygwin-related per se and any advice at this junction is well come. It seems that world knows something about this situation that escapes me entirely... If it is the case, I am happy to offer additional contextual info upon request. As a very important observation, please note that gcc is invoked with '-fno-PIE' as one its arguments, despite the error message! cygcheck.out Description: Binary data 09:22:33 Build of configuration Default for project LinuxDeviceDriversDevelopment-code make /usr/bin/make V=1 -C C:/Users/Richard/progs/Cygwin/cygwin64/usr/src/linux M=$PWD modules /usr/bin/make -f ./scripts/Makefile.build obj=/cygdrive/c/Users/Richard/eclipse-workspace/LinuxDeviceDriversDevelopment-code/Chapter02 \ single-build= \ need-builtin=1 need-modorder=1 gcc -Wp,-MD,/cygdrive/c/Users/Richard/eclipse-workspace/LinuxDeviceDriversDevelopment-code/Chapter02/.helloworld-params.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-cygwin/12/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -Iubuntu/include -include ./include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -O2 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -DMODULE -DKBUILD_BASENAME='"helloworld_params"' -DKBUILD_MODNAME='"helloworld_params"' -c -o /cygdrive/c/Users/Richard/eclipse-workspace/LinuxDeviceDriversDevelopment-code/Chapter02/helloworld-params.o /cygdrive/c/Users/Richard/eclipse-workspace/LinuxDeviceDriversDevelopment-code/Chapter02/helloworld-params.c cc1: error: code model kernel does not support PIC mode make[2]: *** [scripts/Makefile.build:270: /cygdrive/c/Users/Richard/eclipse-workspace/LinuxDeviceDriversDevelopment-code/Chapter02/helloworld-params.o] Error 1 make[1]: *** [Makefile:1778: /cygdrive/c/Users/Richard/eclipse-workspace/LinuxDeviceDriversDevelopment-code/Chapter02] Error 2 make: *** [Makefile:12: modules] Error 2 "make" terminated with exit code 2. Build might be incomplete. 09:23:15 Build Failed. 3 errors, 0 warnings. (took 41s.795ms) -- 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: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"
christianon39--- via Cygwin writes: > /usr/include/sys/signalfd.h:17:17: error: 'O_CLOEXEC' undeclared here (not in > a function); did you mean 'FD_CLOEXEC'? >17 | SFD_CLOEXEC = O_CLOEXEC, > | ^ > | FD_CLOEXEC > --- > Header "sys/signalfd.h" has symbol "SFD_CLOEXEC" : NO > > subprojects/wayland-1.20.0/meson.build:83:3: ERROR: Problem encountered: > SFD_CLOEXEC is needed to compile Wayland libraries > > Is there any solution for this? Or is it a bug that needs to be fixed? The use of O_CLOEXEC in this file is not explicitly guarded by a feature test macro, it is actually defined through sys/_default_fcntl.h, which in turn only does this when __POSIX_VISIBLE >= 200809. Since these are system specific implementation headers there is a reasonable expectation that you've set up the FTM correctly for the system you are working on (which obviously wasn't the case during the compilation whose error you have shown. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"
On 18/06/2024 23:15, christianon39--- via Cygwin wrote: This is a test file I ran so that I didnt need to run the build every time for wlroots. Compiled to exe file with "gcc -o checko test.c". Needs to have a file just called testfile to work Uh, is the claim that this file also produces the same error when compiled? Because that doesn't happen for me... -- 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
Sv: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"
This is a test file I ran so that I didnt need to run the build every time for
wlroots. Compiled to exe file with "gcc -o checko test.c". Needs to have a file
just called testfile to work
Fra: christiano...@outlook.com
Sendt: tirsdag 18. juni 2024 17:07
Til: cygwin@cygwin.com
Emne: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in
a function); did you mean 'FD_CLOEXEC'?"
Hi, I am trying to build wlroots, but get this error in meson logs:
Command line: `cc
/home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c -o
/home/Chris/wlroots/build/meson-private/tmprxphcsub/output.obj -c
-D_FILE_OFFSET_BITS=64 -O0 -std=c11` -> 1
stderr:
In file included from
/home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c:2:
/usr/include/sys/signalfd.h:17:17: error: 'O_CLOEXEC' undeclared here (not in a
function); did you mean 'FD_CLOEXEC'?
17 | SFD_CLOEXEC = O_CLOEXEC,
| ^
| FD_CLOEXEC
---
Header "sys/signalfd.h" has symbol "SFD_CLOEXEC" : NO
subprojects/wayland-1.20.0/meson.build:83:3: ERROR: Problem encountered:
SFD_CLOEXEC is needed to compile Wayland libraries
Is there any solution for this? Or is it a bug that needs to be fixed?
I am using Windows 10 Version 22H2 Build: 19045.3448.
CPU: Ryzen 5 2600
GPU: Nvidia RTX 2070
RAM: 32GB
#include
#include
int main() {
int fd = open("testfile", O_RDONLY);
if (fd == -1) {
perror("open");
return 1;
}
int flags = fcntl(fd, F_GETFD);
if (flags == -1) {
perror("fcntl");
return 1;
}
if (flags & FD_CLOEXEC) {
printf("O_CLOEXEC is supported.\n");
} else {
printf("O_CLOEXEC is not supported.\n");
}
close(fd);
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
Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"
Hi, I am trying to build wlroots, but get this error in meson logs: Command line: `cc /home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c -o /home/Chris/wlroots/build/meson-private/tmprxphcsub/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -std=c11` -> 1 stderr: In file included from /home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c:2: /usr/include/sys/signalfd.h:17:17: error: 'O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'? 17 | SFD_CLOEXEC = O_CLOEXEC, | ^ | FD_CLOEXEC --- Header "sys/signalfd.h" has symbol "SFD_CLOEXEC" : NO subprojects/wayland-1.20.0/meson.build:83:3: ERROR: Problem encountered: SFD_CLOEXEC is needed to compile Wayland libraries Is there any solution for this? Or is it a bug that needs to be fixed? I am using Windows 10 Version 22H2 Build: 19045.3448. CPU: Ryzen 5 2600 GPU: Nvidia RTX 2070 RAM: 32GB -- 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
install error: xinit.sh exit code 3
I don't use those two Cygwin-X shortcuts that failed to be created by mkshortcut when /etc/postinstall/xinit.sh tried to do that. I commented out those two lines near the end of xinit.sh. I hope that has no unwanted side effect(s). -- 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: ntfs-3g/ntfssecaudit build failed with fatal error: linux/fd.h: No such file or directory
On 2024-03-24 12:59, Matthias--- via Cygwin wrote: I downloaded ntfs-3g_ntfsprogs-2022.10.3.tgz from tuxera, extract it and run, in my cygwin 3.5 environment: ./configure make ntfsprogs I got a "fatal error: linux/fd.h: No such file or directory". All ntfsprogs are build in ~/ntfsprogs but not ntfsrecover, ntfssecaudit and ntfsusermap. So do you have any hint where I can find this "linux/fd.h" ? On Linux! Check your config and make logs for questionable defaults or automatic selections. You may want to first try just `make`, to ensure that all subdirectory configs are done properly, as those are often run by the top level make, using the cached results from configure. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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
ntfs-3g/ntfssecaudit build failed with fatal error: linux/fd.h: No such file or directory
Hello, I downloaded ntfs-3g_ntfsprogs-2022.10.3.tgz from tuxera, extract it and run, in my cygwin 3.5 environment: ./configure make ntfsprogs I got a "fatal error: linux/fd.h: No such file or directory". All ntfsprogs are build in ~/ntfsprogs but not ntfsrecover, ntfssecaudit and ntfsusermap. So do you have any hint where I can find this "linux/fd.h" ? Thanks in advance Matthias -- 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: Getting error 60 of curl to cygwin setup
On 2024-03-22 09:49, J M wrote: This is a very painfull and weird failed error of Windows antivirus. I apologize for not having realized before. For other people who may encounter this difficult problem, the key to find this error is (cut connections only for sites that use Letsencrypt certificates), is the strace /usr/bin/curl https://curl.se/ <https://curl.se/> Here, the following line is the key: --- Process 3100 thread 3124 created 1668 16622 [sig] curl (3100) SetThreadName: SetThreadDescription() failed. 1000 This indicate the drop connection. I'm talking to the antivirus people to solve this bug, I don't want to indicate the brand of the antivirus. Many thanks to Brian for you help. Well done for recognizing that failure drops the connection. Boo to the AV co for allowing openssl client test through to retrieve certs, but just dropping the connection on download, without any message to say "Download with Let's Encrypt cert blocked!" An indication whether it is already on our list would be welcome: https://cygwin.com/faq/faq.html#faq.using.bloda and if not, some hint as to its developer, so we can warn others. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Getting error 60 of curl to cygwin setup
Hi, This is a very painfull and weird failed error of Windows antivirus. I apologize for not having realized before. For other people who may encounter this difficult problem, the key to find this error is (cut connections only for sites that use Letsencrypt certificates), is the strace /usr/bin/curl https://curl.se/ Here, the following line is the key: --- Process 3100 thread 3124 created 1668 16622 [sig] curl (3100) SetThreadName: SetThreadDescription() failed. 1000 This indicate the drop connection. I'm talking to the antivirus people to solve this bug, I don't want to indicate the brand of the antivirus. Many thanks to Brian for you help. Cesar Jorge -- 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: Getting error 60 of curl to cygwin setup
xe --norc --noprofile > "/etc/postinstall/ca-certificates-letsencrypt.sh" > 2024/03/19 19:07:43 running: C:\cygwin64\bin\dash.exe > "/etc/postinstall/zp_man-db-update-index.dash" >ManDB index not available. > Program directory for program link: C:\ProgramData\Microsoft\Windows\Start > Menu\Programs > Desktop directory for desktop link: C:\Users\Public\Desktop > Program directory for program link: C:\ProgramData\Microsoft\Windows\Start > Menu\Programs/Cygwin > Desktop directory for desktop link: C:\Users\Public\Desktop > 2024/03/19 19:07:48 note: Installation Complete > 2024/03/19 19:07:48 Ending cygwin install What happens when you try Achim's openssl test: $ openssl s_client -connect cygwin.com:443 and ldd (or cygcheck): $ ldd /usr/bin/curl ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffadca5) KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffadb6d) KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffada49) cygz.dll => /usr/bin/cygz.dll (0x597fd) cygcurl-4.dll => /usr/bin/cygcurl-4.dll (0x482aa) cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffaca81) cygbrotlidec-1.dll => /usr/bin/cygbrotlidec-1.dll (0x42f93) cygcrypto-3.dll => /usr/bin/cygcrypto-3.dll (0x5e01a) cyggsasl-18.dll => /usr/bin/cyggsasl-18.dll (0x5d920) cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3d430) cygidn2-0.dll => /usr/bin/cygidn2-0.dll (0x48488) cygldap-2.dll => /usr/bin/cygldap-2.dll (0x41c39) cyglber-2.dll => /usr/bin/cyglber-2.dll (0x47882) cygpsl-5.dll => /usr/bin/cygpsl-5.dll (0x5d588) cygssl-3.dll => /usr/bin/cygssl-3.dll (0x4ad08) cygzstd-1.dll => /usr/bin/cygzstd-1.dll (0x3a6b3) cygssh2-1.dll => /usr/bin/cygssh2-1.dll (0x458bf) cygbrotlicommon-1.dll => /usr/bin/cygbrotlicommon-1.dll (0x4678a) cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3b824) cyggcrypt-20.dll => /usr/bin/cyggcrypt-20.dll (0x4a445) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x38e6a) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x5ee2d) cygkrb5-3.dll => /usr/bin/cygkrb5-3.dll (0x3b80b) cygkrb5support-0.dll => /usr/bin/cygkrb5support-0.dll (0x3b809) cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3de3c) cygidn-12.dll => /usr/bin/cygidn-12.dll (0x50a91) cygntlm-0.dll => /usr/bin/cygntlm-0.dll (0x3b58f) cygunistring-5.dll => /usr/bin/cygunistring-5.dll (0x38508) cygcrypto-1.1.dll => /usr/bin/cygcrypto-1.1.dll (0x41c65) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x50caa) cyggpg-error-0.dll => /usr/bin/cyggpg-error-0.dll (0x3d55b) cygnghttp2-14.dll => /usr/bin/cygnghttp2-14.dll (0x5ba92) cygsasl2-3.dll => /usr/bin/cygsasl2-3.dll (0x3ae48) -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Getting error 60 of curl to cygwin setup
On 2024-03-19 11:00, J M wrote:
$ file /etc/pki/tls/certs/*
/etc/pki/tls/certs/ca-bundle.crt: symbolic link to
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/etc/pki/tls/certs/ca-bundle.trust.crt: symbolic link to
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
$ grep -c '^-BEGIN.*CERTIFICATE-$'
/etc/pki/ca-trust/extracted/{openssl/*.crt,pem/*.pem}
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:369
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem:116
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem:295
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:145
$ grep '^#\s\(ISRG\|R3\)' /etc/pki/ca-trust/extracted/{openssl/*.crt,pem/*.pem}
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:# ISRG Root X1
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:# ISRG Root X2
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:# R3
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:# ISRG Root X1
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:# ISRG Root X2
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:# R3
Looks the same except the matched number lines of the grep -c.
$ sum /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
22972 630 /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
34027 176 /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem
36930 491 /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
05844 220 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
The following are a bit more useful:
$ wc -lwmcL /etc/pki/ca-trust/extracted/{openssl/*.crt,pem/*.pem}
11307 14152 664107 664142 65
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
33684080 193879 193883 64
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem
8816 10434 512531 512566 65
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
42365094 243623 243627 64
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
27727 33760 1614140 1614218 65 total
$ cksum /etc/pki/ca-trust/extracted/{openssl/*.crt,pem/*.pem}
317625824 664142 /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
382586407 193883 /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem
1244815702 512566 /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
1065593997 243627 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
I would also like to see what you get running:
$ curl -Iv https://8.43.85.97/
* Trying 8.43.85.97:443...
* Connected to 8.43.85.97 (8.43.85.97) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / X25519 /
RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
* subject: CN=cygwin.com
* start date: Jan 21 03:06:49 2024 GMT
* expire date: Apr 20 03:06:48 2024 GMT
* subjectAltName does not match 8.43.85.97
* SSL: no alternative certificate subject name matches target host name
'8.43.85.97'
* Closing connection
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name
'8.43.85.97'
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
and:
$ curl -Iv https://cygwin.com/
* Host cygwin.com:443 was resolved.
* IPv6: 2620:52:3:1:0:246e:9693:128c
* IPv4: 8.43.85.97
* Trying [2620:52:3:1:0:246e:9693:128c]:443...
* Connected to cygwin.com (2620:52:3:1:0:246e:9693:128c) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / X25519 /
RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
* subject: CN=cygwin.com
* start date:
Re: Getting error 60 of curl to cygwin setup
On 2024-03-19 08:02, ASSI via Cygwin wrote:
J M via Cygwin writes:
$ curl - -O https://cygwin.com/setup-x86_64.exe
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0* Host cygwin.com:443 was resolved.
* IPv6: (none)
* IPv4: 8.43.85.97
* Trying 8.43.85.97:443...
* Connected to cygwin.com (8.43.85.97) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [70 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1023 bytes data]
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
} [2 bytes data]
* SSL certificate problem: unable to get local issuer certificate
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
* Closing connection
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Either your cert store is corrupt or something is breaking up the SSL
connection via MITM.
What do you see when you run these commands:
$ file /etc/pki/tls/certs/*
/etc/pki/tls/certs/ca-bundle.crt: symbolic link to
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/etc/pki/tls/certs/ca-bundle.trust.crt: symbolic link to
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
$ grep -c '^-BEGIN.*CERTIFICATE-$'
/etc/pki/ca-trust/extracted/{openssl/*.crt,pem/*.pem}
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:380
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem:124
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem:301
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:156
$ grep '^#\s\(ISRG\|R3\)' /etc/pki/ca-trust/extracted/{openssl/*.crt,pem/*.pem}
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:# ISRG Root X1
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:# ISRG Root X2
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:# R3
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:# ISRG Root X1
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:# ISRG Root X2
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:# R3
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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: Getting error 60 of curl to cygwin setup
J M via Cygwin writes:
> $ curl - -O https://cygwin.com/setup-x86_64.exe
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft
> Speed
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0* Host cygwin.com:443 was resolved.
> * IPv6: (none)
> * IPv4: 8.43.85.97
> * Trying 8.43.85.97:443...
> * Connected to cygwin.com (8.43.85.97) port 443
> * ALPN: curl offers h2,http/1.1
> } [5 bytes data]
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> } [512 bytes data]
> * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> * CApath: none
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0{ [5 bytes data]
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> { [70 bytes data]
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> { [1023 bytes data]
> * TLSv1.2 (OUT), TLS alert, unknown CA (560):
> } [2 bytes data]
> * SSL certificate problem: unable to get local issuer certificate
> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
> 0
> * Closing connection
> curl: (60) SSL certificate problem: unable to get local issuer certificate
> More details here: https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
Either your cert store is corrupt or something is breaking up the SSL
connection via MITM.
--8<---cut here---start->8---
# curl - -O https://cygwin.com/setup-x86_64.exe
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Host cygwin.com:443 was resolved.
* IPv6: 2620:52:3:1:0:246e:9693:128c
* IPv4: 8.43.85.97
* Trying 8.43.85.97:443...
* Connected to cygwin.com (8.43.85.97) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [106 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4010 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / X25519 /
RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
* subject: CN=cygwin.com
* start date: Jan 21 03:06:49 2024 GMT
* expire date: Apr 20 03:06:48 2024 GMT
* subjectAltName: host "cygwin.com" matched cert's "cygwin.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed
using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed
using sha256WithRSAEncryption
{ [5 bytes data]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://cygwin.com/setup-x86_64.exe
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: cygwin.com]
* [HTTP/2] [1] [:path: /setup-x86_64.exe]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: */*]
} [5 bytes data]
> GET /setup-x86_64.exe HTTP/2
> Host: cygwin.com
> User-Agent: curl/8.6.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/2 200
< date: Tue, 19 Mar 2024 13:59:14 GMT
< server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_qos/11.74
mod_wsgi/4.6.4 Python/3.6 mod_perl/2.0.12 Perl/v5.26.3
< vary: User-Agent
< last-modified: Sat, 24 Feb 2024 16:07:44 GMT
< etag: "157c13-61222e0778290"
< accept-ranges: bytes
< content-length: 1408019
< cache-control: max-age=0
< expires: Tue, 19 Mar 2024 13:59:14 GMT
< content-security-policy: default-src 'self' http: https:
< strict-transport-security: max-age=16070400
< content-type: application/octet-stream
<
{ [10024 bytes data]
100 1375k 100 1375k0 0 1034k 0 0:00:01 0:00:01 --:--:-- 1034k
* Connection #0 to host cygwin.com left intact
--8<---cut here---end--->8---
--8<---cut here---start->8---
# openssl s_client -connect cygwin.com:443
CONNECTED(0004)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = cygwin.com
verify return:1
---
Certific
Re: Getting error 60 of curl to cygwin setup
://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> El lun, 18 mar 2024 a las 23:19, Brian Inglis via Cygwin () escribió: > On 2024-03-18 15:21, J M via Cygwin wrote: > > With a fresh install of Cygwin then I launch (with package curl > installed): > > > > curl -O https://www.cygwin.com/setup-x86_64.exe > > > > Shows a curl 60 error ssl problem. > > Using -k or --insecure works, but is not recomended. > > Howto fix it? > > WJFFM! > > That error implies that the version of curl you are running or the > certificate > store you are using does not include the Let's Encrypt CA used by > Cygwin.com. > > From what shell do you launch curl? > > Please run: > > which -a curl > > and ensure that /usr/bin/curl precedes /cygdrive/c/WINDOWS/system32/curl > then > run: > > $ curl -V > curl 8.6.0 (x86_64-pc-cygwin) libcurl/8.6.0 OpenSSL/3.0.13 zlib/1.3.1 > brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0 > nghttp2/1.60.0 libgsasl/2.2.1 OpenLDAP/2.6.7 > Release-Date: 2024-01-31 > Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs > ipns > ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp > Features: alt-svc AsynchDNS brotli gsasl GSS-API HSTS HTTP2 HTTPS-proxy > IDN IPv6 > Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets > zstd > > and check you get the same output as above, then run: > > cygcheck -c ca-certificates ca-certificates-letsencrypt curl cygwin \ > libbrotlidec1 libcurl4 libgsasl18 libgssapi_krb5_2 libidn2_0 libnghttp2_14 > \ > libopenldap2 libpsl5 libssh2_1 libssl3 libzstd1 zlib0 > > and ensure all packages show Status OK. > > If that is the case, please follow the problem reporting guidelines below, > and > attach the output from running > > cygcheck -hrsv > cygcheck-hrsv.log > > as a text attachment to your reply. > > -- > Take care. Thanks, Brian Inglis Calgary, Alberta, Canada > > La perfection est atteinte Perfection is achieved > non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to > add > mais lorsqu'il n'y a plus rien à retirer but when there is no more to > cut > -- Antoine de Saint-Exupéry > > -- > 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 > cygcheck-hrsv.log 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: Getting error 60 of curl to cygwin setup
On 2024-03-18 15:21, J M via Cygwin wrote: With a fresh install of Cygwin then I launch (with package curl installed): curl -O https://www.cygwin.com/setup-x86_64.exe Shows a curl 60 error ssl problem. Using -k or --insecure works, but is not recomended. Howto fix it? WJFFM! That error implies that the version of curl you are running or the certificate store you are using does not include the Let's Encrypt CA used by Cygwin.com. From what shell do you launch curl? Please run: which -a curl and ensure that /usr/bin/curl precedes /cygdrive/c/WINDOWS/system32/curl then run: $ curl -V curl 8.6.0 (x86_64-pc-cygwin) libcurl/8.6.0 OpenSSL/3.0.13 zlib/1.3.1 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.60.0 libgsasl/2.2.1 OpenLDAP/2.6.7 Release-Date: 2024-01-31 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli gsasl GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd and check you get the same output as above, then run: cygcheck -c ca-certificates ca-certificates-letsencrypt curl cygwin \ libbrotlidec1 libcurl4 libgsasl18 libgssapi_krb5_2 libidn2_0 libnghttp2_14 \ libopenldap2 libpsl5 libssh2_1 libssl3 libzstd1 zlib0 and ensure all packages show Status OK. If that is the case, please follow the problem reporting guidelines below, and attach the output from running cygcheck -hrsv > cygcheck-hrsv.log as a text attachment to your reply. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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
Getting error 60 of curl to cygwin setup
Hi, With a fresh install of Cygwin then I launch (with package curl installed): curl -O https://www.cygwin.com/setup-x86_64.exe Shows a curl 60 error ssl problem. Using -k or --insecure works, but is not recomended. Howto fix it? Regards, Cesar Jorge -- 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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
On Feb 26 20:08, Dimitry Andric via Cygwin wrote:
> On 26 Feb 2024, at 20:03, Corinna Vinschen wrote:
> >
> > On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> >> Hi,
> >>
> >> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> >> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> >> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
> >> GNU make 4.4.1-2, when it starts external processes and those external
> >> processes exit with a zero exit code.
> >>
> >> For example, a very simple Makefile:
> >>
> >> all:
> >> cmd /c echo done
> >>
> >> Running this a few times in a Cygwin bash prompt, gives:
> >> [...]
> >> make: *** [Makefile:2: all] Error 127
> >
> > This is probably what has been fixed for 3.5.1 already in patch
> > aa73e1152426 ("Cygwin: console: Fix exit code for non-cygwin process.")
> >
> > For testing, please install the most recent test release
> > cygwin-3.6.0-0.62.gc2f6c0415501 via the Cygwin installer and try again.
>
> Yes, I tried that and it fixes it, thanks!
Great, thanks for your feedback!
Corinna
--
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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
On 26 Feb 2024, at 20:03, Corinna Vinschen wrote:
>
> On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
>> Hi,
>>
>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
>> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
>> GNU make 4.4.1-2, when it starts external processes and those external
>> processes exit with a zero exit code.
>>
>> For example, a very simple Makefile:
>>
>> all:
>> cmd /c echo done
>>
>> Running this a few times in a Cygwin bash prompt, gives:
>> [...]
>> make: *** [Makefile:2: all] Error 127
>
> This is probably what has been fixed for 3.5.1 already in patch
> aa73e1152426 ("Cygwin: console: Fix exit code for non-cygwin process.")
>
> For testing, please install the most recent test release
> cygwin-3.6.0-0.62.gc2f6c0415501 via the Cygwin installer and try again.
Yes, I tried that and it fixes it, thanks!
-Dimitry
--
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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> Hi,
>
> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
> GNU make 4.4.1-2, when it starts external processes and those external
> processes exit with a zero exit code.
>
> For example, a very simple Makefile:
>
> all:
> cmd /c echo done
>
> Running this a few times in a Cygwin bash prompt, gives:
> [...]
> make: *** [Makefile:2: all] Error 127
This is probably what has been fixed for 3.5.1 already in patch
aa73e1152426 ("Cygwin: console: Fix exit code for non-cygwin process.")
For testing, please install the most recent test release
cygwin-3.6.0-0.62.gc2f6c0415501 via the Cygwin installer and try again.
Corinna
--
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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
On 26 Feb 2024, at 18:30, Marco Atzeri via Cygwin wrote:
>
> On 26/02/2024 18:16, Dimitry Andric via Cygwin wrote:
>> On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote:
>>>
>>> On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
>>>> Hi,
>>>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>>>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
>>>> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
>>>> GNU make 4.4.1-2, when it starts external processes and those external
>>>> processes exit with a zero exit code.
>>>> For example, a very simple Makefile:
>>>> all:
>>>> cmd /c echo done
>>>> Running this a few times in a Cygwin bash prompt, gives:
>>>> Dim@kilchoman ~/foobar
>>>> $ make
>>>> cmd /c echo done
>>>> done
>>>> Dim@kilchoman ~/foobar
>>>> $ make
>>>> cmd /c echo done
>>>> done
>>>> make: *** [Makefile:2: all] Error 127
>>>
>>> this smells as a lost race with your AV
>>> can you tell it to not bother the Cygwin directory ?
>> I have no antivirus program except Microsoft's built-in thing, but even
>> if I completely disable that, it makes no difference.
>
> can you follow https://cygwin.com/problems.html and:
> Run cygcheck -s -v -r > cygcheck.out and include that file as an attachment
> in your report.
> maybe we found some additional suggestion for you
I don't think that will be needed, cygwin1-3.6.0-0.32.g10c8c1cf4f94.dll
seems to solve the issue. I can reproduce with cygwin1-3.5.0-1.dll, but
not with 3.4.10-1, nor any dll after 3.6.0-0.32.g10c8c1cf4f94. (I tried
the whole range, from 3.6.0-0.32.g10c8c1cf4f94 through
3.6.0-0.58.g4af5f9d51e1d.dll and they all work.)
My best guess is on
https://www.cygwin.com/cgit/newlib-cygwin/commit/?id=084f848ab9a51d0125491a6f2a7a741f9df73218
("Cygwin: console: Fix exit code for non-cygwin process") by Takashi
Yano, who I've CC'd for confirmation. Indeed, the specific ingredient
for my issue was starting a non Cygwin console binary such as cmd.exe.
-Dimitry
--
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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
On 26/02/2024 18:16, Dimitry Andric via Cygwin wrote: On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote: On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote: Hi, After a recent upgrade of a Cygwin installation, including cygwin1.dll (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of) GNU make 4.4.1-2, when it starts external processes and those external processes exit with a zero exit code. For example, a very simple Makefile: all: cmd /c echo done Running this a few times in a Cygwin bash prompt, gives: Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done make: *** [Makefile:2: all] Error 127 this smells as a lost race with your AV can you tell it to not bother the Cygwin directory ? I have no antivirus program except Microsoft's built-in thing, but even if I completely disable that, it makes no difference. can you follow https://cygwin.com/problems.html and: Run cygcheck -s -v -r > cygcheck.out and include that file as an attachment in your report. maybe we found some additional suggestion for 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
Re: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote: > > On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote: >> Hi, >> After a recent upgrade of a Cygwin installation, including cygwin1.dll >> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to >> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of) >> GNU make 4.4.1-2, when it starts external processes and those external >> processes exit with a zero exit code. >> For example, a very simple Makefile: >> all: >> cmd /c echo done >> Running this a few times in a Cygwin bash prompt, gives: >> Dim@kilchoman ~/foobar >> $ make >> cmd /c echo done >> done >> Dim@kilchoman ~/foobar >> $ make >> cmd /c echo done >> done >> make: *** [Makefile:2: all] Error 127 > > this smells as a lost race with your AV > can you tell it to not bother the Cygwin directory ? I have no antivirus program except Microsoft's built-in thing, but even if I completely disable that, it makes no difference. > Does anybody know if there are intermediate cygwin1.dll copies >> somewhere, so I attempt to bisect where this problem started occurring? >> -Dimitry > > you can test the next snapshots to see if it makes any difference > https://cygwin.com/packages/smmary/cygwin-src.html Thanks, I will try a bunch of those. It might been handy if such files were also available for the commits between 3.4.10 and 3.5.0. Otherwise I'll have to attempt building the DLL myself, but that is a lot more complicated... -Dimitry -- 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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote: Hi, After a recent upgrade of a Cygwin installation, including cygwin1.dll (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of) GNU make 4.4.1-2, when it starts external processes and those external processes exit with a zero exit code. For example, a very simple Makefile: all: cmd /c echo done Running this a few times in a Cygwin bash prompt, gives: Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done make: *** [Makefile:2: all] Error 127 this smells as a lost race with your AV can you tell it to not bother the Cygwin directory ? Does anybody know if there are intermediate cygwin1.dll copies somewhere, so I attempt to bisect where this problem started occurring? -Dimitry you can test the next snapshots to see if it makes any difference https://cygwin.com/packages/summary/cygwin-src.html -- 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
cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1
Hi, After a recent upgrade of a Cygwin installation, including cygwin1.dll (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of) GNU make 4.4.1-2, when it starts external processes and those external processes exit with a zero exit code. For example, a very simple Makefile: all: cmd /c echo done Running this a few times in a Cygwin bash prompt, gives: Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done make: *** [Makefile:2: all] Error 127 Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done make: *** [Makefile:2: all] Error 127 Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done make: *** [Makefile:2: all] Error 127 Dim@kilchoman ~/foobar $ make cmd /c echo done done Dim@kilchoman ~/foobar $ make cmd /c echo done done make: *** [Makefile:2: all] Error 127 So basically, every one in two or three runs randomly gives "error 127". I have not yet figured out what is causing it, but any clue would be nice! In any case, reverting cygwin1.dll back to 3.4.10-1 immediately solves the issue: I can then run this makefile in a loop for 1 times, and it will succeed every time. Does anybody know if there are intermediate cygwin1.dll copies somewhere, so I attempt to bisect where this problem started occurring? -Dimitry -- 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: cl: on failure - there is no shell error code returned with cygwin-3.5.0-1
On Thu, 22 Feb 2024, Takashi Yano wrote: > On Thu, 22 Feb 2024 11:46:39 +0530 (IST) Satish Balay wrote: > > With cygwin upgrade to 3.5.0-1 - I'm not seeing "error return codes" on > > compile failures. > Thanks for the report. > This bug has already has been fixed in current git head and will be > fixed in 3.5.1. > > https://cygwin.com/pipermail/cygwin-patches/2024q1/012612.html Great, thanks! Satish -- 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: cl: on failure - there is no shell error code returned with cygwin-3.5.0-1
On Thu, 22 Feb 2024 11:46:39 +0530 (IST) Satish Balay wrote: > Usage: Invoke 'cl' from cygwin/bash. i.e: > > - run 'Visual Studio CMD' to setup MS compilers in dos shell > - run 'c:\cygwin64\cygwin.bat' [or 'c:\cygwin64\bin\bash --login'] > - run 'cl /c test.c' > > With cygwin upgrade to 3.5.0-1 - I'm not seeing "error return codes" on > compile failures. > > However - this works again after downgrading to 3.4.10-1. > > Note: This works with 3.5.0-1 - if I use 'mintty' - instead of 'cygwin.bat' > or 'bash --login' from 'Compiler CMD' > > Perhaps a bug in current cygwin release? > > thanks, > Satish > > > C:\Program Files\Microsoft Visual Studio\2022\Community>\cygwin64\bin\bash > --login > > balay@ps5 ~ > $ uname -a > CYGWIN_NT-10.0-22631 ps5 3.5.0-1.x86_64 2024-02-01 11:02 UTC x86_64 Cygwin > > balay@ps5 ~ > $ cat test.c > error > > balay@ps5 ~ > $ cl /c test.c > Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33134 for x64 > Copyright (C) Microsoft Corporation. All rights reserved. > > test.c > test.c(2): fatal error C1004: unexpected end-of-file found > > balay@ps5 ~ > $ echo $? > 0 > > C:\Program Files\Microsoft Visual Studio\2022\Community>\cygwin64\bin\bash > --login > > balay@ps5 ~ > $ uname -a > CYGWIN_NT-10.0-22631 ps5 3.4.10-1.x86_64 2023-11-29 12:12 UTC x86_64 Cygwin > > balay@ps5 ~ > $ cl test.c > Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33134 for x64 > Copyright (C) Microsoft Corporation. All rights reserved. > > test.c > test.c(2): fatal error C1004: unexpected end-of-file found > > balay@ps5 ~ > $ echo $? > 2 > Thanks for the report. This bug has already has been fixed in current git head and will be fixed in 3.5.1. https://cygwin.com/pipermail/cygwin-patches/2024q1/012612.html -- Takashi Yano -- 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
cl: on failure - there is no shell error code returned with cygwin-3.5.0-1
Usage: Invoke 'cl' from cygwin/bash. i.e: - run 'Visual Studio CMD' to setup MS compilers in dos shell - run 'c:\cygwin64\cygwin.bat' [or 'c:\cygwin64\bin\bash --login'] - run 'cl /c test.c' With cygwin upgrade to 3.5.0-1 - I'm not seeing "error return codes" on compile failures. However - this works again after downgrading to 3.4.10-1. Note: This works with 3.5.0-1 - if I use 'mintty' - instead of 'cygwin.bat' or 'bash --login' from 'Compiler CMD' Perhaps a bug in current cygwin release? thanks, Satish C:\Program Files\Microsoft Visual Studio\2022\Community>\cygwin64\bin\bash --login balay@ps5 ~ $ uname -a CYGWIN_NT-10.0-22631 ps5 3.5.0-1.x86_64 2024-02-01 11:02 UTC x86_64 Cygwin balay@ps5 ~ $ cat test.c error balay@ps5 ~ $ cl /c test.c Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33134 for x64 Copyright (C) Microsoft Corporation. All rights reserved. test.c test.c(2): fatal error C1004: unexpected end-of-file found balay@ps5 ~ $ echo $? 0 C:\Program Files\Microsoft Visual Studio\2022\Community>\cygwin64\bin\bash --login balay@ps5 ~ $ uname -a CYGWIN_NT-10.0-22631 ps5 3.4.10-1.x86_64 2023-11-29 12:12 UTC x86_64 Cygwin balay@ps5 ~ $ cl test.c Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33134 for x64 Copyright (C) Microsoft Corporation. All rights reserved. test.c test.c(2): fatal error C1004: unexpected end-of-file found balay@ps5 ~ $ echo $? 2 -- 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: I am getting an error trying to use openssl 1.1.1v in cygwin
On Sun, Feb 18, 2024 at 3:40 PM Cary Lewis via Cygwin wrote: > > Attempting to run: > > openssl enc -base64 -i file > > gives the following error: > > 42949672976:error:25066067:DSO support routines:dlfcn_load:could not load > the shared library:crypto/dso/dso_dlfcn.c:118:filename(libproviders.dll): > No such file or directory > 42949672976:error:25070067:DSO support routines:DSO_load:could not load the > shared library:crypto/dso/dso_lib.c:162: > 42949672976:error:0E07506E:configuration file > routines:module_load_dso:error loading > dso:crypto/conf/conf_mod.c:224:module=providers, path=providers > 42949672976:error:0E076071:configuration file routines:module_run:unknown > module name:crypto/conf/conf_mod.c:165:module=providers > > I removed openssl 1.1.1v with apt-cyg remove openssl and reinstalled it > with apt-cyg install openssl, and now I have version 3.0.13 30 which > resolves the problem. > > I had version OpenSSL 1.1.1f installed on another machine, which did not > display the error. > > I am just posting here in case someone else runs into this issue. > what about to use the Cygwin setup so that all the dependencies are properly updated ? My guess is that that you have not updated the cygwin1.dll Regards Marco PS: apt-cyg is not supported by cygwin maintainers (and the last time I checked was also not updated by long time) -- 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
I am getting an error trying to use openssl 1.1.1v in cygwin
Attempting to run: openssl enc -base64 -i file gives the following error: 42949672976:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:118:filename(libproviders.dll): No such file or directory 42949672976:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:162: 42949672976:error:0E07506E:configuration file routines:module_load_dso:error loading dso:crypto/conf/conf_mod.c:224:module=providers, path=providers 42949672976:error:0E076071:configuration file routines:module_run:unknown module name:crypto/conf/conf_mod.c:165:module=providers I removed openssl 1.1.1v with apt-cyg remove openssl and reinstalled it with apt-cyg install openssl, and now I have version 3.0.13 30 which resolves the problem. I had version OpenSSL 1.1.1f installed on another machine, which did not display the error. I am just posting here in case someone else runs into this issue. -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Sat, 3 Feb 2024 at 19:25, Corinna Vinschen wrote: > > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we > > want them to do. I just tested this myself with a modified Cygwin DLL > > (code below) and it turns out that the child process error mode is > > the same as the parent's process error mode. Changing the thread > > error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS | > > SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect. > > [...etc.] Oh dear, what a mess! > MSYS2 has introduced the environment variable option CYGWIN=winjitdebug. > I backported this patch now. So default is back to propagating Cygwin's > error mode and if you want to reset the error mode of a non-Cygwin child > process back to OS default, just set the option, for instance, like > this: > > $ CYGWIN=winjitdebug env > > This patch will be in Cygwin 3.5.1. For the time being, it will be > available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as > well. This completely fixes it for us, thank you very much Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 3 13:39, Corinna Vinschen via Cygwin wrote: > On Feb 2 19:51, Corinna Vinschen via Cygwin wrote: > > On Feb 2 18:22, Corinna Vinschen via Cygwin wrote: > > > On Feb 2 14:56, David Allsopp via Cygwin wrote: > > > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > > > > Is it actually a safe bet that the error mode set by > > > > > SetThreadErrorMode > > > > > is then propagated as process error mode to the child process? > > > > > > > > > > I have to ask that because Microsoft conveniently forgot to document > > > > > this scenario in the MSDN docs. > > > > > > > > :o) Never knowingly clear, are they! It would seem to be the intent of > > > > SetThreadErrorMode that it would behave that way but who knows. > > > > > > > > Happy to set up a quick experiment to check that it does work (i.e. > > > > [...] > > > Wanna try this? > > [...] > > However, it occured to me that this won't work at all. > > [...] > > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we > want them to do. I just tested this myself with a modified Cygwin DLL > (code below) and it turns out that the child process error mode is > the same as the parent's process error mode. Changing the thread > error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS | > SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect. > [...etc.] MSYS2 has introduced the environment variable option CYGWIN=winjitdebug. I backported this patch now. So default is back to propagating Cygwin's error mode and if you want to reset the error mode of a non-Cygwin child process back to OS default, just set the option, for instance, like this: $ CYGWIN=winjitdebug env This patch will be in Cygwin 3.5.1. For the time being, it will be available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as well. HTH, Corinna -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024, Corinna Vinschen wrote: > On Feb 2 09:43, David Allsopp via Cygwin wrote: > > However, this patch came from MSYS2, and subsequently they seem to > > have found it problematic for the same reason as me > > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > > and have just recently reintroduced the flag > > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > > to control it. > > > > The reasoning in > > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > > valid now as it did in 2006. > > > > Is it possible to revisit having the flag, or even just reverting the > > behaviour? > > > > I'm sympathetic, and personally I would prefer to revert the patch and > stick to SEM_FAILCRITICALERRORS by default. > > The question is this: Why does, apparently, everybody expect Cygwin to > do the "right thing", with different definitions of "right", when in > fact the executable in question can easily call SetErrorMode by itself? The different definitions of "right" is the reason the flag/option was re-added in MSYS2. I think the most "right" thing Cygwin could do (if it were to only do one thing, rather than having an option) would be to somehow have native processes inherit the error mode as though Cygwin were not in the mix. The issue with that, as you've seen, is that there are any number of Cygwin processes in the hierarchy. As far as the executable being able to call SetErrorMode itself, that would be OK except for when the error is coming from the loader, before anything from the executable is run (such as for missing DLL or missing export from DLL). I do like the idea of a native Windows program like "nohup" that sets the error mode and then runs a subprocess. Why doesn't Windows come with something like that? ;) -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 19:51, Corinna Vinschen via Cygwin wrote:
> On Feb 2 18:22, Corinna Vinschen via Cygwin wrote:
> > On Feb 2 14:56, David Allsopp via Cygwin wrote:
> > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > > is then propagated as process error mode to the child process?
> > > >
> > > > I have to ask that because Microsoft conveniently forgot to document
> > > > this scenario in the MSDN docs.
> > >
> > > :o) Never knowingly clear, are they! It would seem to be the intent of
> > > SetThreadErrorMode that it would behave that way but who knows.
> > >
> > > Happy to set up a quick experiment to check that it does work (i.e.
> > > [...]
> > Wanna try this?
> [...]
> However, it occured to me that this won't work at all.
> [...]
Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
want them to do. I just tested this myself with a modified Cygwin DLL
(code below) and it turns out that the child process error mode is
the same as the parent's process error mode. Changing the thread
error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS |
SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect.
Check the below Cygwin patch and look at output ("gem" is my MingW test
app just printing the process error mode retrieved via GetErrorMode):
$ ./gem
0 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (0,
0) GT:0 GP:3
16158 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (3,
0)
Error mode 0x3
$
The terrible thing here is the output of the old thread error mode
from GetThreadErrorMode as well as from SetThreadErrorMode.
MSDN says:
Each process has an associated error mode that indicates to the system
how the application is going to respond to serious errors. A thread
inherits the error mode of the process in which it is running. To
retrieve the process error mode, use the GetErrorMode function. To
retrieve the error mode of the calling thread, use the
GetThreadErrorMode function.
What that means is, even though the process error mode is 3 , and even
though "A thread inherits the error mode of the process in which it is
running", GetThreadErrorMode/SetThreadErrorMode return a thread error
code of 0!!!
So if GetThreadErrorMode returns 0, you *have* to call GetErrorMode to
retrieve the *actual* thread error mode, because the thread error mode
just says "yo man, it's default".
In extension this probably *also* means, setting the thread error mode
to 0 does NOT mean "set it to system default" as MSDN claims, but it
means "set it to process default".
But in fact, even if I set a non-0 thread error mode, this has no effect
on the child process. I forced the thread error mode to 1 before calling
CreateProcess, and the resulting child process error mode was still the
Cygwin process error mode 3.
Isn't that completely screwed up?
Ok, my Cygwin DLL test patch follows below.
Corinna
diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index a40129c22232..14ba4e3769f1 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -718,7 +718,8 @@ dll_crt0_0 ()
init_windows_system_directory ();
initial_env ();
- SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
+ UINT proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
+ | SEM_NOGPFAULTERRORBOX);
lock_process::init ();
user_data->impure_ptr = _impure_ptr;
@@ -738,6 +739,13 @@ dll_crt0_0 ()
if (!child_proc_info)
{
setup_cygheap ();
+ /* Memorize the original error mode when this Cygwin process
+has been called from a non-Cygwin process. We restore to
+this error mode on spawning a non-Cygwin process. This allows
+to set a non-default error mode prior to calling the first
+Cygwin process and forward it to any subsequent non-Cygwin
+child process at spawn time. */
+ cygheap->orig_proc_error_mode = proc_error_mode;
memory_init ();
}
else
diff --git a/winsup/cygwin/local_includes/cygheap.h
b/winsup/cygwin/local_includes/cygheap.h
index b6acdf7f18b7..02e3cb4621e3 100644
--- a/winsup/cygwin/local_includes/cygheap.h
+++ b/winsup/cygwin/local_includes/cygheap.h
@@ -517,6 +517,7 @@ struct init_cygheap: public mini_cygheap
mode_t umask;
LONG rlim_as_id;
unsigned long rlim_core;
+ UINT orig_proc_error_mode; /* Set when started from non-Cygwin process */
HANDLE console_h;
cwdstuff cwd;
dtable fdtab;
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..85dbec431b28 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -401,13 +401
Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 18:22, Corinna Vinschen via Cygwin wrote:
> On Feb 2 14:56, David Allsopp via Cygwin wrote:
> > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > On Feb 2 13:35, David Allsopp via Cygwin wrote:
> > > > Not really suggesting it be done this way (it feels more complicated
> > > > than just reverting the change), but in some ways perhaps Cygwin
> > > > should be using GetErrorMode on startup and instead of not inheriting
> > > > it, ensuring that it sets whatever it received? i.e. just before the
> > > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > > error mode (for that thread only) to the value read at startup, calls
> > > > CreateProcess and then sets the error mode back.
> > >
> > > This sounds like a good ide, but...
> > >
> > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > is then propagated as process error mode to the child process?
> > >
> > > I have to ask that because Microsoft conveniently forgot to document
> > > this scenario in the MSDN docs.
> >
> > :o) Never knowingly clear, are they! It would seem to be the intent of
> > SetThreadErrorMode that it would behave that way but who knows.
> >
> > Happy to set up a quick experiment to check that it does work (i.e.
> > the invoked process has GetErrorMode set as expected) and that there's
> > no possible race between two threads in the calling process with
> > differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> > thread and not in another behaves as expected. If it does appear to
> > work consistently, would you be willing to go down this route? Happy
> > to do the patch, although it'd be very helpful to have a couple of
> > pointers: I'm guessing the value would want to be captured just before
> > the one place where SetErrorMode is already called, but in which
> > structure should it then be stashed away to be reused in spawn?
>
> Wanna try this? It ignores the case of starting a process
> under another user account for now, but that can be added easily
> if this proves to work as expected.
During dinner it occured to me that I forgot to remove setting the
default error mode via CreateProcess. So this patch would have
to be applied as well:
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..2e0f0fcf2146 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -401,13 +401,6 @@ child_info_spawn::worker (const char *prog_arg, const char
*const *argv,
c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT;
- /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they
-get the default error mode instead of inheriting the mode Cygwin
-uses. This allows things like Windows Error Reporting/JIT debugging
-to work with processes launched from a Cygwin shell. */
- if (!real_path.iscygexec ())
- c_flags |= CREATE_DEFAULT_ERROR_MODE;
-
/* We're adding the CREATE_BREAKAWAY_FROM_JOB flag here to workaround
issues with the "Program Compatibility Assistant (PCA) Service".
For some reason, when starting long running sessions from mintty(*),
However, it occured to me that this won't work at all.
Consider fork/exec. In Windows terms, the forked process is a child
process started with CreateProcess. The forked child is a Cygwin
process, so at DLL init time, it sets
orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
| SEM_NOGPFAULTERRORBOX);
However, given the parent is always a Cygwin parent, orig_proc_error_mode
will always be SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX.
The following exec starting a non-Cygwin process will set the thread
error mode to the above value. So any non-Cygwin process started from
your typical Cygwin process like bash, will always have the error mode
set to the same mode as any Cygwin application.
Ultimately this means, the effect is the same as if we had just reverted
commit 21ec498d7f912 ("cygwin: use CREATE_DEFAULT_ERROR_MODE in spawn").
Corinna
--
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 14:56, David Allsopp via Cygwin wrote:
> On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > On Feb 2 13:35, David Allsopp via Cygwin wrote:
> > > Not really suggesting it be done this way (it feels more complicated
> > > than just reverting the change), but in some ways perhaps Cygwin
> > > should be using GetErrorMode on startup and instead of not inheriting
> > > it, ensuring that it sets whatever it received? i.e. just before the
> > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > error mode (for that thread only) to the value read at startup, calls
> > > CreateProcess and then sets the error mode back.
> >
> > This sounds like a good ide, but...
> >
> > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > is then propagated as process error mode to the child process?
> >
> > I have to ask that because Microsoft conveniently forgot to document
> > this scenario in the MSDN docs.
>
> :o) Never knowingly clear, are they! It would seem to be the intent of
> SetThreadErrorMode that it would behave that way but who knows.
>
> Happy to set up a quick experiment to check that it does work (i.e.
> the invoked process has GetErrorMode set as expected) and that there's
> no possible race between two threads in the calling process with
> differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> thread and not in another behaves as expected. If it does appear to
> work consistently, would you be willing to go down this route? Happy
> to do the patch, although it'd be very helpful to have a couple of
> pointers: I'm guessing the value would want to be captured just before
> the one place where SetErrorMode is already called, but in which
> structure should it then be stashed away to be reused in spawn?
Wanna try this? It ignores the case of starting a process
under another user account for now, but that can be added easily
if this proves to work as expected.
diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index a40129c22232..f1017e69b6b2 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -718,7 +718,8 @@ dll_crt0_0 ()
init_windows_system_directory ();
initial_env ();
- SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
+ orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
+ | SEM_NOGPFAULTERRORBOX);
lock_process::init ();
user_data->impure_ptr = _impure_ptr;
diff --git a/winsup/cygwin/globals.cc b/winsup/cygwin/globals.cc
index 885ada85e7b8..d2861ba98b42 100644
--- a/winsup/cygwin/globals.cc
+++ b/winsup/cygwin/globals.cc
@@ -28,6 +28,7 @@ PWCHAR windows_directory = windows_directory_buf + 4;
UINT windows_directory_length;
UNICODE_STRING windows_directory_path;
WCHAR global_progname[NT_MAX_PATH];
+UINT orig_proc_error_mode;
/* program exit the program */
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..df83f25d13c6 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -648,6 +648,10 @@ child_info_spawn::worker (const char *prog_arg, const char
*const *argv,
&& !::cygheap->user.groups.issetgroups ()
&& !::cygheap->user.setuid_to_restricted))
{
+ UINT orig_thread_error_mode = SEM_FAILCRITICALERRORS
+ | SEM_NOGPFAULTERRORBOX;
+ if (!iscygwin ())
+ SetThreadErrorMode (orig_proc_error_mode, &orig_thread_error_mode);
rc = CreateProcessW (runpath, /* image name w/ full path */
cmd.wcs (wcmd), /* what was passed to exec */
sa, /* process security attrs */
@@ -658,6 +662,8 @@ child_info_spawn::worker (const char *prog_arg, const char
*const *argv,
NULL,
&si,
&pi);
+ if (!iscygwin ())
+ SetThreadErrorMode (orig_thread_error_mode, NULL);
}
else
{
--
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > On Feb 2 13:35, David Allsopp via Cygwin wrote: > > Jon Turney via Cygwin wrote: > > > > > > I'm sympathetic, and personally I would prefer to revert the patch and > > > > stick to SEM_FAILCRITICALERRORS by default. > > > > > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > > > do the "right thing", with different definitions of "right", when in > > > > fact the executable in question can easily call SetErrorMode by itself? > > > > > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > > > get the behaviour you want? > > > > Ah, but that's how I hit this (and started digging further) - > > precisely because the non-Cygwin program I'm using _has_ called > > SetErrorMode and its direct calls to the faulty program _are_ doing > > what's wanted (no popup dialog) but the calls which happen via Cygwin > > are then torching that preference. > > > > Not really suggesting it be done this way (it feels more complicated > > than just reverting the change), but in some ways perhaps Cygwin > > should be using GetErrorMode on startup and instead of not inheriting > > it, ensuring that it sets whatever it received? i.e. just before the > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > > error mode (for that thread only) to the value read at startup, calls > > CreateProcess and then sets the error mode back. > > This sounds like a good ide, but... > > Is it actually a safe bet that the error mode set by SetThreadErrorMode > is then propagated as process error mode to the child process? > > I have to ask that because Microsoft conveniently forgot to document > this scenario in the MSDN docs. :o) Never knowingly clear, are they! It would seem to be the intent of SetThreadErrorMode that it would behave that way but who knows. Happy to set up a quick experiment to check that it does work (i.e. the invoked process has GetErrorMode set as expected) and that there's no possible race between two threads in the calling process with differing values (i.e. that having SEM_FAILCRITICALERRORS in one thread and not in another behaves as expected. If it does appear to work consistently, would you be willing to go down this route? Happy to do the patch, although it'd be very helpful to have a couple of pointers: I'm guessing the value would want to be captured just before the one place where SetErrorMode is already called, but in which structure should it then be stashed away to be reused in spawn? David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 13:35, David Allsopp via Cygwin wrote: > Jon Turney via Cygwin wrote: > > > > I'm sympathetic, and personally I would prefer to revert the patch and > > > stick to SEM_FAILCRITICALERRORS by default. > > > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > > do the "right thing", with different definitions of "right", when in > > > fact the executable in question can easily call SetErrorMode by itself? > > > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > > get the behaviour you want? > > Ah, but that's how I hit this (and started digging further) - > precisely because the non-Cygwin program I'm using _has_ called > SetErrorMode and its direct calls to the faulty program _are_ doing > what's wanted (no popup dialog) but the calls which happen via Cygwin > are then torching that preference. > > Not really suggesting it be done this way (it feels more complicated > than just reverting the change), but in some ways perhaps Cygwin > should be using GetErrorMode on startup and instead of not inheriting > it, ensuring that it sets whatever it received? i.e. just before the > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > error mode (for that thread only) to the value read at startup, calls > CreateProcess and then sets the error mode back. This sounds like a good ide, but... Is it actually a safe bet that the error mode set by SetThreadErrorMode is then propagated as process error mode to the child process? I have to ask that because Microsoft conveniently forgot to document this scenario in the MSDN docs. Corinna -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
Jon Turney via Cygwin wrote: > > I'm sympathetic, and personally I would prefer to revert the patch and > > stick to SEM_FAILCRITICALERRORS by default. > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > do the "right thing", with different definitions of "right", when in > > fact the executable in question can easily call SetErrorMode by itself? > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > get the behaviour you want? Ah, but that's how I hit this (and started digging further) - precisely because the non-Cygwin program I'm using _has_ called SetErrorMode and its direct calls to the faulty program _are_ doing what's wanted (no popup dialog) but the calls which happen via Cygwin are then torching that preference. Not really suggesting it be done this way (it feels more complicated than just reverting the change), but in some ways perhaps Cygwin should be using GetErrorMode on startup and instead of not inheriting it, ensuring that it sets whatever it received? i.e. just before the call to CreateProcess for a non-Cygwin binary, Cygwin restores the error mode (for that thread only) to the value read at startup, calls CreateProcess and then sets the error mode back. To explain in the context of the actual call chain: - I have opam.exe (compiled with mingw-w64), which is calling SetErrorMode in main - It's calling ocamlc.exe (in PATH) which requires the zstd DLL, but that has not been put in PATH - A direct call - not via Cygwin - to ocamlc -vnum therefore returns an exit code - Another call, already there from the Unix side, instead does sh -c "ocamlc -config | sed ..." but Cygwin has then _removed_ the calling applications preference Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024 at 12:55, Corinna Vinschen via Cygwin wrote: > On Feb 2 09:43, David Allsopp via Cygwin wrote: > > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin > > wrote: > > > > > > The behaviour changed in 2020 > > > > > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > > > > > not without a discussion > > > > > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html > > > > Aha, thank you! (congrats on the 3.5 release, in passing, btw). > > Definitely not a regression, then (subject edited). > > > > However, this patch came from MSYS2, and subsequently they seem to > > have found it problematic for the same reason as me > > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > > and have just recently reintroduced the flag > > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > > to control it. > > > > The reasoning in > > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > > valid now as it did in 2006. > > > > Is it possible to revisit having the flag, or even just reverting the > > behaviour? > > > > FWIW, it's been "hurting" us over in OCaml-land since zstd support was > > added roughly a year ago - configure can tell us that mingw-w64's zstd > > is available, but woe betide us if we run the test program to see if > > it actually works, but the user forgot to add the sys-root into PATH, > > because at that point the CI system is down... > > I'm sympathetic, and personally I would prefer to revert the patch and > stick to SEM_FAILCRITICALERRORS by default. > > The question is this: Why does, apparently, everybody expect Cygwin to > do the "right thing", with different definitions of "right", when in > fact the executable in question can easily call SetErrorMode by itself? The executable can't, though (at least, I'm not aware that it can)? The DLL not found case is being triggered by the loader, before the entrypoint code is running? I did have a look to see if there are manifest flags or some such which can be set to indicate this, but it does seem to be the responsibility of the caller, coupled with a "best practice" recommendation on MSDN to call SetErrorMode (as Cygwin is of course doing). The whole system with it feels like unfortunate Windows legacy, but I guess the behaviour vastly predates Event Viewer, etc., and slightly better (and non-blocking) ways of reporting loader errors. Perils of a nearly 40 year old API, if not OS Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On 02/02/2024 12:55, Corinna Vinschen via Cygwin wrote: On Feb 2 09:43, David Allsopp via Cygwin wrote: On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin wrote: The behaviour changed in 2020 https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 not without a discussion https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html Aha, thank you! (congrats on the 3.5 release, in passing, btw). Definitely not a regression, then (subject edited). However, this patch came from MSYS2, and subsequently they seem to have found it problematic for the same reason as me (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) and have just recently reintroduced the flag (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) to control it. The reasoning in https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as valid now as it did in 2006. Is it possible to revisit having the flag, or even just reverting the behaviour? FWIW, it's been "hurting" us over in OCaml-land since zstd support was added roughly a year ago - configure can tell us that mingw-w64's zstd is available, but woe betide us if we run the test program to see if it actually works, but the user forgot to add the sys-root into PATH, because at that point the CI system is down... I'm sympathetic, and personally I would prefer to revert the patch and stick to SEM_FAILCRITICALERRORS by default. The question is this: Why does, apparently, everybody expect Cygwin to do the "right thing", with different definitions of "right", when in fact the executable in question can easily call SetErrorMode by itself? Yeah, if cygwin wasn't involved in the process ancestry, how would you get the behaviour you want? I guess perhaps what's needed here is a command-wrapper tool like 'nice' or 'env' which lets you run a command with the error-handling mode you want. But that must already exist for Windows, right? :) -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 09:43, David Allsopp via Cygwin wrote: > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin > wrote: > > > > The behaviour changed in 2020 > > > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > > > not without a discussion > > > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html > > Aha, thank you! (congrats on the 3.5 release, in passing, btw). > Definitely not a regression, then (subject edited). > > However, this patch came from MSYS2, and subsequently they seem to > have found it problematic for the same reason as me > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > and have just recently reintroduced the flag > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > to control it. > > The reasoning in > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > valid now as it did in 2006. > > Is it possible to revisit having the flag, or even just reverting the > behaviour? > > FWIW, it's been "hurting" us over in OCaml-land since zstd support was > added roughly a year ago - configure can tell us that mingw-w64's zstd > is available, but woe betide us if we run the test program to see if > it actually works, but the user forgot to add the sys-root into PATH, > because at that point the CI system is down... I'm sympathetic, and personally I would prefer to revert the patch and stick to SEM_FAILCRITICALERRORS by default. The question is this: Why does, apparently, everybody expect Cygwin to do the "right thing", with different definitions of "right", when in fact the executable in question can easily call SetErrorMode by itself? Corinna -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin wrote: > > The behaviour changed in 2020 > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > not without a discussion > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html Aha, thank you! (congrats on the 3.5 release, in passing, btw). Definitely not a regression, then (subject edited). However, this patch came from MSYS2, and subsequently they seem to have found it problematic for the same reason as me (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) and have just recently reintroduced the flag (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) to control it. The reasoning in https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as valid now as it did in 2006. Is it possible to revisit having the flag, or even just reverting the behaviour? FWIW, it's been "hurting" us over in OCaml-land since zstd support was added roughly a year ago - configure can tell us that mingw-w64's zstd is available, but woe betide us if we run the test program to see if it actually works, but the user forgot to add the sys-root into PATH, because at that point the CI system is down... Thanks, David -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On 2024-02-01 01:18, David Allsopp via Cygwin wrote:
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."
My question is not how to fix the problem (I'm well aware of that),
but rather why that message is being displayed at all, and is it a bug
in Cygwin somewhere? All I could find Googling was previous
suggestions that Cygwin routinely calls SetErrorMode with, amongst
other things, SEM_FAILCRITICALERRORS with the intention of suppressing
this dialog.
Is that correct, and if so is this just me? :o)
Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
I also get the same popup if I run C:\cygwin64\bin\sh -c
"/cygdrive/c/path/to/test" either from a Command Prompt or even from
"Start -> Run". Running this via "sh" called from a non-Cygwin process
(itself invoked from a Command Prompt) which has also called
SetErrorMode is how I hit this.
Better to let you know that there is a problem, and what the problem is, so you
can fix it!
Thank you, but no - as I made clear by:
My question is not how to fix the problem (I'm well aware of that)
I'm fully aware what has caused the issue to arise, and how to fix it
- that's not the issue. The problem is that according to previous
messages, and the Cygwin code, my impression was that mintty / bash /
sh (*Cygwin* programs) calling this executable should be returning an
exit code here, not freezing on a message dialog. The problem appears
to be a bug in the Cygwin DLL, and from previous messages on the list,
my question is whether it's a regression, and can be fixed.
The reason it's a problem is, say, a script _in Cygwin_ which is
handed a command to run, runs it, and is then completely blocked by
that popup dialog. It's the responsibility of the _caller_ (a Cygwin
program) to indicate the mode in which a program is executed - the
message box may be owned by the program called, but it's caused by it
being loaded, before it has a chance to run any code.
My understanding, based on this line:
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721
in dll_crt0_0
is that Cygwin executables (in this case mintty / bash / sh, etc.)
should be running with SEM_FAILCRITICALERRORS enabled, following the
best practice recommendations in
https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode
and that that setting should be correctly inherited by processes they
call (including non-Cygwin ones).
Some ancient history, reporting my same issue in 2004:
https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this
thread from 2006
https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly
indicating that that line dcrt0.cc is there precisely to stop this
popup.
I do not see the problem if a native MS Windows program is not properly
installed with native MS Windows library dependencies and MS Windows displays a
popup to inform the user of the missing dependency.
Developer/maintainer/packager/distributor defects are never a downstream issue,
they need to be addressed by the party who caused the failure!
There seems to be a conflict here with some native MS Windows program users
wanting those native MS Windows programs to be able start a debugger and others
wanting a CLI failure message.
ISTM if native MS Windows programs want specific native MS Windows behaviour,
they should set that up before, at, or shortly after startup, as Cygwin does for
its own programs, not rely on a foreign invoker doing so for them.
Could those native MS Windows programs not be run from a native MS Windows shell
or wrapper script to ensure the desired behaviour?
Or just do not run native MS Windows programs, and find or build a Cygwin script
or program to perform the desired function: that's the Cygwin way to avoid
native MS Windows issues! ;^>
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On Feb 1 08:22, David Allsopp via Cygwin wrote: > > x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should > > be involved in the execution ? > > I perhaps should have made that crystal clear - in running "./test", > I'm invoking that excecutable _from_ a Cygwin program (in this case > mintty / bash / sh), so Cygwin is very much involved - it's the > caller. > > In the actual problem which hit this, I have a non-Cygwin executable > which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program > calls test, there is no popup displayed. However, it also calls > Cygwin's sh and _that_ executes that program too, so something like > "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error > message appears. So somewhere along the line, Cygwin appears to be > resetting the system error mode, and that appears contrary to previous > (old) messages on the subject. The behaviour changed in 2020 https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 not without a discussion https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html Corinna -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
> x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should > be involved in the execution ? I perhaps should have made that crystal clear - in running "./test", I'm invoking that excecutable _from_ a Cygwin program (in this case mintty / bash / sh), so Cygwin is very much involved - it's the caller. In the actual problem which hit this, I have a non-Cygwin executable which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program calls test, there is no popup displayed. However, it also calls Cygwin's sh and _that_ executes that program too, so something like "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error message appears. So somewhere along the line, Cygwin appears to be resetting the system error mode, and that appears contrary to previous (old) messages on the subject. Thanks, David -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
>
> On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
> > Starting with this very trivial C program:
> >
> > #include
> > #include
> >
> > int main(void) {
> >printf("Zstandard v%d\n", ZSTD_versionNumber());
> > }
> >
> > and compiling with
> >
> > x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
> >
> > when I then run ./test.exe, I get the Windows critical-error-handler
> > dialog stating "The code execution cannot proceed because
> > libzstd-1.dll was not found. Reinstalling the program may fix this
> > problem."
> >
> > My question is not how to fix the problem (I'm well aware of that),
> > but rather why that message is being displayed at all, and is it a bug
> > in Cygwin somewhere? All I could find Googling was previous
> > suggestions that Cygwin routinely calls SetErrorMode with, amongst
> > other things, SEM_FAILCRITICALERRORS with the intention of suppressing
> > this dialog.
> >
> > Is that correct, and if so is this just me? :o)
> >
> > Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
> > I also get the same popup if I run C:\cygwin64\bin\sh -c
> > "/cygdrive/c/path/to/test" either from a Command Prompt or even from
> > "Start -> Run". Running this via "sh" called from a non-Cygwin process
> > (itself invoked from a Command Prompt) which has also called
> > SetErrorMode is how I hit this.
>
> Better to let you know that there is a problem, and what the problem is, so
> you
> can fix it!
Thank you, but no - as I made clear by:
> My question is not how to fix the problem (I'm well aware of that)
I'm fully aware what has caused the issue to arise, and how to fix it
- that's not the issue. The problem is that according to previous
messages, and the Cygwin code, my impression was that mintty / bash /
sh (*Cygwin* programs) calling this executable should be returning an
exit code here, not freezing on a message dialog. The problem appears
to be a bug in the Cygwin DLL, and from previous messages on the list,
my question is whether it's a regression, and can be fixed.
The reason it's a problem is, say, a script _in Cygwin_ which is
handed a command to run, runs it, and is then completely blocked by
that popup dialog. It's the responsibility of the _caller_ (a Cygwin
program) to indicate the mode in which a program is executed - the
message box may be owned by the program called, but it's caused by it
being loaded, before it has a chance to run any code.
My understanding, based on this line:
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721
in dll_crt0_0
is that Cygwin executables (in this case mintty / bash / sh, etc.)
should be running with SEM_FAILCRITICALERRORS enabled, following the
best practice recommendations in
https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode
and that that setting should be correctly inherited by processes they
call (including non-Cygwin ones).
Some ancient history, reporting my same issue in 2004:
https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this
thread from 2006
https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly
indicating that that line dcrt0.cc is there precisely to stop this
popup.
Thanks,
David
--
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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."
My question is not how to fix the problem (I'm well aware of that),
but rather why that message is being displayed at all, and is it a bug
in Cygwin somewhere? All I could find Googling was previous
suggestions that Cygwin routinely calls SetErrorMode with, amongst
other things, SEM_FAILCRITICALERRORS with the intention of suppressing
this dialog.
Is that correct, and if so is this just me? :o)
Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
I also get the same popup if I run C:\cygwin64\bin\sh -c
"/cygdrive/c/path/to/test" either from a Command Prompt or even from
"Start -> Run". Running this via "sh" called from a non-Cygwin process
(itself invoked from a Command Prompt) which has also called
SetErrorMode is how I hit this.
Better to let you know that there is a problem, and what the problem is, so you
can fix it!
I have spent hours trying to track down initialization failures, when daemons
just ignored that a library they needed was not found or loaded!
Install the following package:
$ cygcheck -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll
mingw64-x86_64-zstd-1.5.5-1
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On Wed, Jan 31, 2024 at 2:41 PM David Allsopp via Cygwin wrote:
>
> Starting with this very trivial C program:
>
> #include
> #include
>
> int main(void) {
> printf("Zstandard v%d\n", ZSTD_versionNumber());
> }
>
> and compiling with
>
> x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
>
> when I then run ./test.exe, I get the Windows critical-error-handler
> dialog stating "The code execution cannot proceed because
> libzstd-1.dll was not found. Reinstalling the program may fix this
> problem."
>
> My question is not how to fix the problem (I'm well aware of that),
> but rather why that message is being displayed at all, and is it a bug
> in Cygwin somewhere? All I could find Googling was previous
> suggestions that Cygwin routinely calls SetErrorMode with, amongst
> other things, SEM_FAILCRITICALERRORS with the intention of suppressing
> this dialog.
>
> Is that correct, and if so is this just me? :o)
>
> Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
> I also get the same popup if I run C:\cygwin64\bin\sh -c
> "/cygdrive/c/path/to/test" either from a Command Prompt or even from
> "Start -> Run". Running this via "sh" called from a non-Cygwin process
> (itself invoked from a Command Prompt) which has also called
> SetErrorMode is how I hit this.
>
> Thanks!
>
>
> David
>
x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
be involved in the execution ?
--
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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On 1/31/2024 7:40 AM, David Allsopp via Cygwin wrote:
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."
[snip]
x86_64-w64-mingw32-gcc is a cross compiler, a.k.a. the Mingw compiler,
not Cygwin's gcc.
It is quite correct for a cross compiler meant to produce Windows
executables to do what you are seeing. The executable is independent of
Cygwin, i.e. doesn't use the Cygwin dll.
--
RB
--
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
Aren't Windows System Error popups meant to be disabled in Cygwin?
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."
My question is not how to fix the problem (I'm well aware of that),
but rather why that message is being displayed at all, and is it a bug
in Cygwin somewhere? All I could find Googling was previous
suggestions that Cygwin routinely calls SetErrorMode with, amongst
other things, SEM_FAILCRITICALERRORS with the intention of suppressing
this dialog.
Is that correct, and if so is this just me? :o)
Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
I also get the same popup if I run C:\cygwin64\bin\sh -c
"/cygdrive/c/path/to/test" either from a Command Prompt or even from
"Start -> Run". Running this via "sh" called from a non-Cygwin process
(itself invoked from a Command Prompt) which has also called
SetErrorMode is how I hit this.
Thanks!
David
--
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: "Internal Error: gcrypt library error 60 illegal tag." when scripting
Thanks, Jon - I've removed the parameter for ' http://cygwinports.org/ports.gpg' and I'm not entirely sure why I had it there in the first place. However, on removing the parameter, I now get the error for every referenced site in the script "Unable to get setup from <https://.../>" for every site referenced in the script except hoobly.com and constant.com - removing those sites from the script allows the script to run properly even though they are listed in "Choose A Download Site" picker and when adding them there, they have no issue - any idea why those sites would have issues in the script but not when selecting from the picker? -Jim On Fri, Dec 22, 2023 at 9:41 AM James Hanley wrote: > when running the following script below - I always get the error indicated > in the subject line. If I click another site from the UI then after it > works fine. If I change the script to reflect that selected site from the > UI and re-run, I get the same error mentioned. Any ideas? > > """ > #!/bin/sh > > ( > cd /usr/local/bin > wget2 -N http://cygwin.com/setup-x86_64.exe > chmod u+x /usr/local/bin/setup-x86_64.exe > ) > > # > # --site http://mathiasw.com > \ > # --site http://mirrors.koehn.com\ > # --site http://cygwin.skazkaforyou.com \ > # --site > http://ftp.mirrorservice.org/sites/sourceware.org/pub/cygwinports \ > # --site http://cygwin.mirrors.pair.com \ > > cygstart -- /usr/local/bin/setup-x86_64.exe \ > --pubkeyhttp://cygwinports.org/ports.gpg\ > --site http://cygwin.mirror.constant.com \ > --site http://cygwin.mirrors.hoobly.com\ > --site https://mirror.clarkson.edu \ > --site http://www.gtlib.gatech.edu \ > --site https://mirrors.rit.edu \ > --site http://mirror.cs.vt.edu \ > -g $* > """ > -- 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: "Internal Error: gcrypt library error 60 illegal tag." when scripting
On 22/12/2023 14:41, James Hanley via Cygwin wrote: when running the following script below - I always get the error indicated in the subject line. If I click another site from the UI then after it works fine. If I change the script to reflect that selected site from the UI and re-run, I get the same error mentioned. Any ideas? Yeah, this error should probably be reported in a clearer fashion. I think what this error is telling you is that 'http://cygwinports.org/ports.gpg' is not a valid gpg key. This is correct. If you open that with your browser, you'll see why. The cygwinports package repo was shut down some time ago (2017 I think). The solution is to remove that key from your setup invocation. -- 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 Error: gcrypt library error 60 illegal tag." when scripting
when running the following script below - I always get the error indicated in the subject line. If I click another site from the UI then after it works fine. If I change the script to reflect that selected site from the UI and re-run, I get the same error mentioned. Any ideas? """ #!/bin/sh ( cd /usr/local/bin wget2 -N http://cygwin.com/setup-x86_64.exe chmod u+x /usr/local/bin/setup-x86_64.exe ) # # --site http://mathiasw.com \ # --site http://mirrors.koehn.com\ # --site http://cygwin.skazkaforyou.com \ # --site http://ftp.mirrorservice.org/sites/sourceware.org/pub/cygwinports \ # --site http://cygwin.mirrors.pair.com \ cygstart -- /usr/local/bin/setup-x86_64.exe \ --pubkeyhttp://cygwinports.org/ports.gpg\ --site http://cygwin.mirror.constant.com \ --site http://cygwin.mirrors.hoobly.com\ --site https://mirror.clarkson.edu \ --site http://www.gtlib.gatech.edu \ --site https://mirrors.rit.edu \ --site http://mirror.cs.vt.edu \ -g $* """ -- 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: Command 'net user' outputs error message if PKA is used
Hi, On 27/11/2023 7:51 pm, tk--- via Cygwin wrote: Any idea why this is happening ? I suspect the reason is related to this long standing understanding of Cygwin: https://sourceware.org/legacy-ml/cygwin/2004-09/msg00087.html On 03/09/2004 2:13 am, Corinna Vinschen wrote: Public Key authentication OTOH is *bypassing* the Windows authentication mechanism, resulting in a very different access token attached to your session. For one, there is no password attached and no network credentials, so you don't have the same automagical access to network shares. Another problem is that you didn't even start a logon session from WinNT's point of view, which has a couple of interesting side effect. The bottom line is, if you need all the user's access rights use password authentication. If that doesn't help, you're out of luck -- Hope that helps, Shaddy -- 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
Command 'net user' outputs error message if PKA is used
Hi, We have observed that the command 'NET USER' issues en error message and doesn't display the computer name, even if it completes the command successfully: >>>>> User accounts for \\ Administratoruser1 user2 The command completed with one or more errors. >>>>> The same command works successfully if password authentication is used: >>>>> User accounts for \\COMPUTER Administratoruser1 user2 The command completed successfully. >>>>> Any idea why this is happening ? Kind regards -- 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 3.4.9 - Error starting cygsshd service
Hello, I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10. After installing defaults plus openssh 9.5p 1-1, I open the Cygwin64-Terminal as Administrator and run ssh-host-config. Answered "yes" to create the /etc/ssh_config and /etc/sshd_config Answered "no" to use StrictMode and "yes" to install sshd as a service I just press for the question for "Value of CYGWIN for the daemon". cygrunsrv -S cygsshd will not start the sshd. "QueryServiceStatus: Win32 error 1062:" I tried "ssh-keygen -A" - but no keys created. I have no $HOME/.ssh or /etc/ssh and create them. Both owned by me with u=rwx,go=rw. I tried ssh- keygen again but without success. I also tried ssh-host-config again. It says "*** Info: Generating missing SSH host keys" but I still have no keys in /etc/ssh or $HOME/.ssh Thanks Matthias -- 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: Another confusing error from someone else's Cygwin setup
Greetings, David Karr!
> I'm seeing a problem with someone else's Cygwin setup, sort of similar to a
> problem I asked about a couple of weeks ago, in that it's a problem with
> the same user, but seemingly a completely different problem.
> He is using a Bash script that I wrote, and he gets a seemingly nonsensical
> error that I don't understand.
> The script starts out pretty simply, just like this:
> --
> #! /bin/bash
> #set -x
> main() {
> if [ "$1" == "" ]; then
> usage;
> exit;
> fi
> ...
> -
> He was getting a weird error on line 3, just saying this:
> -
> ...: line 3: syntax error near unexpected token `$'{\r''
> ...: line 3: `main() {
> ---
Quick and dirty way to solve your issue -
$ tr -d '\r' > script.fixed < script.erring
> This was pretty perplexing,
It is actually pretty clear, though.
$ od -t x1a < script.erring
See the output.
--
With best regards,
Andrey Repin
Wednesday, July 5, 2023 22:22:57
Sorry for my terrible english...
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [pkg cygwin-devel] /usr/include/sys/cpuset.h:52 error: missing return type
Marco Mason via Cygwin wrote: I looked at a couple mailing list archives and saw that the cpuset.h header was worked on recently, but couldn't track it down any closer. I also tried to find a git repository so I could find the commit so I could check for similar errors on other headers, but couldn't find the repo for cygwin-devel anywhere. This error was introduced with the most recent update to cpuset.h. There is a public-visible mirror of the Cygwin tree at https://github.com/cygwin/cygwin/blob/main/winsup/cygwin and the problematic file can be found at include/sys/cpuset.h within. You can also view the official repository at https://www.cygwin.com/cgit/newlib-cygwin/ This is linked to from https://cygwin.com/git.html, which is accessible via "Source in Git" on the sidebar at https://cygwin.com/ If you have any suggestions as to how to structure things to make this more easily discoverable, they are welcome. -- 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: [pkg cygwin-devel] /usr/include/sys/cpuset.h:52 error: missing return type
Hi Marco,
Marco Mason via Cygwin wrote:
I just updated to 3.4.9-1 and compiled some code, and it complained about
cpuset.h.
Specifically, "C++ requires a type specifier for all declarations", and
sure enough, there's no return type on line 52. So I changed my local copy
to the following, and it cleared things up:
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
static __inline /*MCM*/ void /*MCM*/
__cpuset_zero_s (__size_t siz, cpu_set_t *set)
{
Thanks for the report; right you are.
I looked at a couple mailing list archives and saw that the cpuset.h header
was worked on recently, but couldn't track it down any closer. I also
tried to find a git repository so I could find the commit so I could check
for similar errors on other headers, but couldn't find the repo for
cygwin-devel anywhere.
This error was introduced with the most recent update to cpuset.h. There is a
public-visible mirror of the Cygwin tree at
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin
and the problematic file can be found at
include/sys/cpuset.h
within.
Your bug report and proposed correction are all we need for the issue you ran
into. I'll submit a patch shortly.
Thanks again,
..mark
--
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
[pkg cygwin-devel] /usr/include/sys/cpuset.h:52 error: missing return type
I just updated to 3.4.9-1 and compiled some code, and it complained about
cpuset.h.
Specifically, "C++ requires a type specifier for all declarations", and
sure enough, there's no return type on line 52. So I changed my local copy
to the following, and it cleared things up:
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
static __inline /*MCM*/ void /*MCM*/
__cpuset_zero_s (__size_t siz, cpu_set_t *set)
{
I looked at a couple mailing list archives and saw that the cpuset.h header
was worked on recently, but couldn't track it down any closer. I also
tried to find a git repository so I could find the commit so I could check
for similar errors on other headers, but couldn't find the repo for
cygwin-devel anywhere.
--
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
xserver failing on new install - fatal error on xcb connection
I recently installed a fresh copy of cygwin64 on a new Windows 10 box. xserver starts but randomly fails after a few minutes with: waiting for X server to shut down winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. winMultiWindowXMsgProc - Fatal error 1 on xcb connection winDeinitMultiWindowWM - Noting shutdown in progress (II) Server terminated successfully (0). Closing log file. Any pointers for how to troubleshoot? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error
>Not sure if you guys still exist or not? But having a problem porting over >to Windows 10 and getting this error. Any suggestions? >1 [main] bash 9592 find_fst_cwd: WARNING: Couldnt compute FAST_CWD pointer. >Please report this problem to the public mailing list cygwin@cygwin.com >Thanks, >Rich Kent >/Rich Kent/// >RK Racing â Aurora IL >www.RichKentRacing.com <http://www.richkentracing.com/> >rkraci...@aol.com <mailto:rkraci...@aol.com> >630-542-0604 https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Error
Not sure if you guys still exist or not? But having a problem porting over to Windows 10 and getting this error. Any suggestions? 1 [main] bash 9592 find_fst_cwd: WARNING: Couldnt compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com Thanks, -- Rich Kent /Rich Kent/// RK Racing – Aurora IL www.RichKentRacing.com <http://www.richkentracing.com/> rkraci...@aol.com <mailto:rkraci...@aol.com> 630-542-0604 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: error report
>bin/iperf3.exe -c 192.168.1.233 -P 1 -i 1 -p 5201 -f g -t 10   0 [main] >iperf3 17636 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. >Please report this problem tothe public mailing list cygwin@cygwin.com https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
error report
bin/iperf3.exe -c 192.168.1.233 -P 1 -i 1 -p 5201 -f g -t 10 0 [main] iperf3 17636 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem tothe public mailing list cygwin@cygwin.com -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Config error
>I am trying to configure the cntlm for GIT on my machine using the following >instructions: >Configure >1. Open a Command Prompt as Administrator. >a. Type cd "C:\Program Files (x86)\cntlm" and hit >b. Type notepad cntlm.ini and hit to modify the configuration >file. > i. Change > the "Username" entry from testuser to your > ii. Change > the "Domain" entry from corp-uk to MAIL > iii. Change > the "Password" entry from "password" to > iv. There are > two "Proxy" entries. >1. In the first change 10.0.0.41:8080 to 172.16.0.13:8080 >2. Delete the second entry. > v. Save, but > leave the cntlm.ini file open and move to the next step. >c. Type cntlm -c cntlm.ini -I -M http://google.ro and hit > i. Type > your network password when prompted and hit > ii. Copy the > entire line with (PassNTLMv2) in it. >d. Paste the text copied in "c." to the cntlm.ini file below the >following line: > i. # > PassNTLMv2 D5826E9C665C37C80B53397D5C07BBCB >e. Save and Close the cntlm.ini file. >When I press enter at the end of this line, cntlm -c cntlm.ini -I -M >http://google.ro, it returns the following error. >4 [main] cntlm 5768 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. > Please report this problem to >the public mailing list cygwin@cygwin.com<mailto:cygwin@cygwin.com> >Can you help? I am following the instructions from >https://intranet.madonna.local/teams/commandinfotech/its/ha/Shared%20Documents/VSTS_Install.docx. >Mary Pleas >SQL Server Database Warehouse Developer >Madonna Rehabilitation Hospitals >402.413.4471 >mpl...@madonna.org<mailto:mpl...@madonna.org> >Madonna.org<http://www.madonna.org/> | >Facebook<https://www.facebook.com/Madonna.Rehabilitation.Hospitals/> | >Twitter<https://twitter.com/Madonnarehab> >Confidential: This email and any files transmitted with it are private, >confidential and solely for the use of the designated recipient(s). It may >contain material that is legally privileged. If you are not the designated >recipient, be advised that any use of it is strictly prohibited. If you >received the email in error, please notify the sender by return email and >delete the message and any attachments from your email system. https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Config error
I am trying to configure the cntlm for GIT on my machine using the following instructions: Configure 1. Open a Command Prompt as Administrator. a. Type cd "C:\Program Files (x86)\cntlm" and hit b. Type notepad cntlm.ini and hit to modify the configuration file. i. Change the "Username" entry from testuser to your ii. Change the "Domain" entry from corp-uk to MAIL iii. Change the "Password" entry from "password" to iv. There are two "Proxy" entries. 1. In the first change 10.0.0.41:8080 to 172.16.0.13:8080 2. Delete the second entry. v. Save, but leave the cntlm.ini file open and move to the next step. c. Type cntlm -c cntlm.ini -I -M http://google.ro and hit i. Type your network password when prompted and hit ii. Copy the entire line with (PassNTLMv2) in it. d. Paste the text copied in "c." to the cntlm.ini file below the following line: i. # PassNTLMv2 D5826E9C665C37C80B53397D5C07BBCB e. Save and Close the cntlm.ini file. When I press enter at the end of this line, cntlm -c cntlm.ini -I -M http://google.ro, it returns the following error. 4 [main] cntlm 5768 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com<mailto:cygwin@cygwin.com> Can you help? I am following the instructions from https://intranet.madonna.local/teams/commandinfotech/its/ha/Shared%20Documents/VSTS_Install.docx. Mary Pleas SQL Server Database Warehouse Developer Madonna Rehabilitation Hospitals 402.413.4471 mpl...@madonna.org<mailto:mpl...@madonna.org> Madonna.org<http://www.madonna.org/> | Facebook<https://www.facebook.com/Madonna.Rehabilitation.Hospitals/> | Twitter<https://twitter.com/Madonnarehab> Confidential: This email and any files transmitted with it are private, confidential and solely for the use of the designated recipient(s). It may contain material that is legally privileged. If you are not the designated recipient, be advised that any use of it is strictly prohibited. If you received the email in error, please notify the sender by return email and delete the message and any attachments from your email system. -- 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: Another confusing error from someone else's Cygwin setup
The line endings were the issue, thanks. They were that way because I
didn't realize I should force those files in git to have eol=lf in a
.gitattributes file. This is now all fixed.
On Mon, Jun 26, 2023 at 7:08 PM Mike Gran wrote:
> > On Monday, June 26, 2023 at 04:36:30 PM PDT, David Karr via Cygwin <
> cygwin@cygwin.com> wrote:
>
> > m seeing a problem with someone else's Cygwin setup, sort of similar to a
> > problem I asked about a couple of weeks ago, in that it's a problem with
> > the same user, but seemingly a completely different problem.
>
> ...
>
> > He was getting a weird error on line 3, just saying this:
> > -
> > ...: line 3: syntax error near unexpected token `$'{\r''
> > ...: line 3: `main() {
> > ---
>
> If you run bash with the "-o igncr" option, it will ignore extraneous
> carriage return characters.
>
> But the characters are there in the first place because your
> script has been converted into using Windows line endings:
> carriage return + linefeed.
>
> You didn't say how the script was transferred, but lots
> of programs could add returns when you transfer something
> to windows: git or ftp just to name a few.
>
> You both could try running "bash --version". The first line should
> say something like
> "GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)"
>
> Note the "pc-cygwin" at the end.
>
> HTH,
> Mike Gran
>
--
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: Another confusing error from someone else's Cygwin setup
> On Monday, June 26, 2023 at 04:36:30 PM PDT, David Karr via Cygwin
> wrote:
> m seeing a problem with someone else's Cygwin setup, sort of similar to a
> problem I asked about a couple of weeks ago, in that it's a problem with
> the same user, but seemingly a completely different problem.
...
> He was getting a weird error on line 3, just saying this:
> -----
> ...: line 3: syntax error near unexpected token `$'{\r''
> ...: line 3: `main() {
> ---
If you run bash with the "-o igncr" option, it will ignore extraneous
carriage return characters.
But the characters are there in the first place because your
script has been converted into using Windows line endings:
carriage return + linefeed.
You didn't say how the script was transferred, but lots
of programs could add returns when you transfer something
to windows: git or ftp just to name a few.
You both could try running "bash --version". The first line should
say something like
"GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)"
Note the "pc-cygwin" at the end.
HTH,
Mike Gran
--
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: Another confusing error from someone else's Cygwin setup
On 6/26/2023 4:58 PM, Dan Harkless via Cygwin wrote:
On 6/26/2023 4:35 PM, David Karr via Cygwin wrote:
> > He was getting a weird error on line 3, just saying this:
> > -
> > ...: line 3: syntax error near unexpected token `$'{\r''
> > ...: line 3: `main() {
> > ---
Apologies, I don't remember your other report, but this one kind of
sounds like an end-of-line characters problem. Try installing
(Cygwin's) dos2unix, if you don't already have it, then try running
dos2unix on the script. If it still doesn't work, try then running
unix2dos. If you have binutils installed, you can also use the 'file'
command for a quick report on whether files have lines terminated with
CR (macOS), CRLF (Windows), or LF (UNIX/Linux). 'file' might not
realize when you have files with inconsistent line-terminators, though.
And I forgot dos2unix also includes a 'mac2unix' command these days
(though not a mac2dos), so maybe try that first.
--
Dan Harkless
http://harkless.org/dan/
--
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: Another confusing error from someone else's Cygwin setup
On 6/26/2023 4:35 PM, David Karr via Cygwin wrote:
> He was getting a weird error on line 3, just saying this:
> -
> ...: line 3: syntax error near unexpected token `$'{\r''
> ...: line 3: `main() {
> ---
Apologies, I don't remember your other report, but this one kind of
sounds like an end-of-line characters problem. Try installing
(Cygwin's) dos2unix, if you don't already have it, then try running
dos2unix on the script. If it still doesn't work, try then running
unix2dos. If you have binutils installed, you can also use the 'file'
command for a quick report on whether files have lines terminated with
CR (macOS), CRLF (Windows), or LF (UNIX/Linux). 'file' might not
realize when you have files with inconsistent line-terminators, though.
--
Dan Harkless
http://harkless.org/dan/
--
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
Another confusing error from someone else's Cygwin setup
I'm seeing a problem with someone else's Cygwin setup, sort of similar to a
problem I asked about a couple of weeks ago, in that it's a problem with
the same user, but seemingly a completely different problem.
He is using a Bash script that I wrote, and he gets a seemingly nonsensical
error that I don't understand.
The script starts out pretty simply, just like this:
--
#! /bin/bash
#set -x
main() {
if [ "$1" == "" ]; then
usage;
exit;
fi
...
-----
He was getting a weird error on line 3, just saying this:
-----
...: line 3: syntax error near unexpected token `$'{\r''
...: line 3: `main() {
---
This was pretty perplexing, so I asked him to uncomment the "set -x" line
to see if that provided any useful information, and that fails with a
different error:
---
: invalid option...: line 2: set: -
set: usage: set [-abefhkmnptuvxBCEHPT] [-o option-name] [--] [-] [arg ...]
--
This also makes no sense to me. I compared our "uname -a" outputs, and
they are almost identical. However, I then had him run "bash --version",
and I compared it to mine. Ironically, I'm using an OLDER version of bash
than he is. I'm on v4.4.12(3)-release, and he's on v5.2.15(3)-release. Is
there something in 5.x versions of Bash that could cause these issues?
--
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 test 3.5.0 tar symlinks error messages and failure status
Achim Gratz wrote: > Brian Inglis writes: > > Problem writing tar (with Cygwin default sys) symlinks before target > > created under Cygwin 3.5.0 - error messages are issued and tar exits > > with failure status! > […] > > The only likely culprit between 3.4.6 and that commit seems to be > > commit 2023-04-18 fa84aa4dd2fb43eaf7fcdfb040aef854f2f19d01 Cygwin: fix > > errno values set by readlinkat. > > > > Still seems to work as expected despite the error messages and failure > > status. > > > > Runs without any messages or failure under Cygwin stable 3.4.6. > > The interface mentioned above is known to be wonky on various systems. > You might need to re-build tar in oder for it to detect any changed > level of wonkiness and adapt accordingly. On Cygwin 3.4.7, recompiling tar from the source package fixes this problem; the resulting binary then seems to be fine on Cygwin 3.4.6 as well. Please could tar 1.34 be re-packaged? All best, David -- 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 test 3.5.0 tar symlinks error messages and failure status
("Manually" replying to an email in the archive
(https://cygwin.com/pipermail/cygwin/2023-May/253742.html) since I don't have
the original email anymore).
Achim Gratz wrote:
> Brian Inglis via Cygwin writes:
> > Problem writing tar (with Cygwin default sys) symlinks before target
> > created under Cygwin 3.5.0 - error messages are issued and tar exits
> > with failure status!
> […]
> > The only likely culprit between 3.4.6 and that commit seems to be
> > commit 2023-04-18 fa84aa4dd2fb43eaf7fcdfb040aef854f2f19d01 Cygwin: fix
> > errno values set by readlinkat.
> >
> > Still seems to work as expected despite the error messages and failure
> > status.
> >
> > Runs without any messages or failure under Cygwin stable 3.4.6.
We started seeing the same problem after cygwin 3.4.7 was released (I note it
includes the commit Brian mentions). As a workaround, we just ignore the exit
code of the tar command, but understandably we would rather not do that.
Extracting the same archive works fine without warnings or errors on Linux.
> The interface mentioned above is known to be wonky on various systems.
> You might need to re-build tar in oder for it to detect any changed
> level of wonkiness and adapt accordingly.
Do you mean that the tar package would need an update?
// Daniel
--
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 test 3.5.0 tar symlinks error messages and failure status
Brian Inglis via Cygwin writes: > Problem writing tar (with Cygwin default sys) symlinks before target > created under Cygwin 3.5.0 - error messages are issued and tar exits > with failure status! […] > The only likely culprit between 3.4.6 and that commit seems to be > commit 2023-04-18 fa84aa4dd2fb43eaf7fcdfb040aef854f2f19d01 Cygwin: fix > errno values set by readlinkat. > > Still seems to work as expected despite the error messages and failure status. > > Runs without any messages or failure under Cygwin stable 3.4.6. The interface mentioned above is known to be wonky on various systems. You might need to re-build tar in oder for it to detect any changed level of wonkiness and adapt accordingly. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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 test 3.5.0 tar symlinks error messages and failure status
Problem writing tar (with Cygwin default sys) symlinks before target created under Cygwin 3.5.0 - error messages are issued and tar exits with failure status! Also failed with the same issues under my own dev build based off origin/main commit 2023-05-01 3bee68248fc8e164a8bb6bba3f105b10fdec8a71 Cygwin: Fix compiling with w32api-headers v11.0.0. The only likely culprit between 3.4.6 and that commit seems to be commit 2023-04-18 fa84aa4dd2fb43eaf7fcdfb040aef854f2f19d01 Cygwin: fix errno values set by readlinkat. Still seems to work as expected despite the error messages and failure status. Runs without any messages or failure under Cygwin stable 3.4.6. Symlinks are captoinfo and infotocap -> tic, reset -> tset, ncurses6-config -> ncursesw6-config. $ uname -srvmo CYGWIN_NT-10.0-19044 3.5.0-0.303.g4840a5632520.x86_64 2023-05-24 21:41 UTC x86_64 Cygwin $ tar -xvf ncurses-6.4-6.20230520.x86_64/dist/ncurses/ncurses-6.4-6.20230520.tar.xz usr/bin/captoinfo /bin/tar: usr/bin/captoinfo: Cannot change mode to rwxr-xr-x: Not a directory usr/bin/clear.exe usr/bin/infocmp.exe usr/bin/infotocap /bin/tar: usr/bin/infotocap: Cannot change mode to rwxr-xr-x: Not a directory usr/bin/reset /bin/tar: usr/bin/reset: Cannot change mode to rwxr-xr-x: Not a directory usr/bin/tabs.exe usr/bin/tic.exe usr/bin/toe.exe usr/bin/tput.exe usr/bin/tset.exe usr/share/doc/ncurses/ usr/share/doc/ncurses/ANNOUNCE usr/share/doc/ncurses/AUTHORS usr/share/doc/ncurses/COPYING usr/share/doc/ncurses/NEWS usr/share/doc/ncurses/README usr/share/man/man1/captoinfo.1m.gz usr/share/man/man1/clear.1.gz usr/share/man/man1/infocmp.1m.gz usr/share/man/man1/infotocap.1m.gz usr/share/man/man1/reset.1.gz usr/share/man/man1/tabs.1.gz usr/share/man/man1/tic.1m.gz usr/share/man/man1/toe.1m.gz usr/share/man/man1/tput.1.gz usr/share/man/man1/tset.1.gz /bin/tar: Exiting with failure status due to previous errors $ tar -xvf ncurses-6.4-6.20230520.x86_64/dist/ncurses/libncurses-devel/libncurses-devel-6.4-6.20230520.tar.xz: extracting... usr/bin/ncurses6-config /bin/tar: usr/bin/ncurses6-config: Cannot change mode to rwxr-xr-x: Not a directory -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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
dd: error reading '/proc/sys/Device/HarddiskVolumeShadowCopy9': No space left on device
Hello, I'm trying to create a volume shadow copy image using $ dd if=/proc/sys/Device/HarddiskVolumeShadowCopy9 of=/dev/null bs=4096 status=progress but it ends prematurely with 116923437056 bytes (117 GB, 109 GiB) copied, 65 s, 1.8 GB/s dd: error reading '/proc/sys/Device/HarddiskVolumeShadowCopy9': No space left on device 29139072+0 records in 29139072+0 records out 119353638912 bytes (119 GB, 111 GiB) copied, 65.5664 s, 1.8 GB/s If i use Windows Command Prompt then it finishes successfully: C:\tmp>\cygwin64\bin\dd if=//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy9 of=/dev/null bs=4096 status=progress 119288205312 bytes (119 GB, 111 GiB) copied, 471 s, 253 MB/s 29139074+0 records in 29139074+0 records out 119353647104 bytes (119 GB, 111 GiB) copied, 471.14 s, 253 MB/s If I use count=29139071 then it works in both environments. Any ideas? I haven't subscribed yet so Cc me please. Regards, Opty -- 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
git-send-email --confirm=always error after perl upgrade
On 2023-05-02 13:36, Achim Gratz via Cygwin wrote:
Perl 5.36.1-1 is now available on Cygwin, replacing perl-5.32.1. Most
Perl distributions and dependent packages have been either re-released
or updated in conjunction with this update. The following packages have
been released for Cygwin:
Hi folks,
Just updated everything including perl and now git send-email fails with error
without prompting or requesting input for sendemail.confirm = always - address
headers have been sanitized and perl indents have been reduced:
$ git send-email --to=patches
0001-fhandler-proc.cc-format_proc_cpuinfo-Add-Linux-6.3-cpuinfo.patch
0001-fhandler-proc.cc-format_proc_cpuinfo-Add-Linux-6.3-cpuinfo.patch
(mbox) Adding to: patches from line 'To: patches'
From: user.name
To: patches
Subject: [PATCH] fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo
Date: Sun, 7 May 2023 16:07:20 -0600
Message-Id: <68bbf3607bdf37fcd32613aa962abe50846d968a.1682994011.git.user.email>
X-Mailer: git-send-email 2.39.0
MIME-Version: 1.0
Bcc: user.name
Reply-To: patches
Content-Transfer-Encoding: 8bit
Send this email reply required at /usr/libexec/git-core/git-send-email line
1585.
$
git-send-email:
1561if ($needs_confirm && !$dry_run) {
1562print "\n$header\n";
1563if ($needs_confirm eq "inform") {
1564$confirm_unconfigured = 0; # squelch this message for the rest
of this run
1565 $ask_default = "y"; # assume yes on EOF since user hasn't explicitly asked
for confirmation
1566print __ < qr/^(?:yes|y|no|n|edit|e|quit|q|all|a)/i,
1584default => $ask_default);
1585die __("Send this email reply required") unless defined $_;
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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: reporting error
>pwd 2444 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
reporting error
pwd 2444 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error running setup-x86_64.exe: syntax error in setup.zst
On Fri, Apr 7, 2023 at 2:40 AM Jon Turney wrote: > > On 07/04/2023 02:44, Keith Thompson via Cygwin wrote: > > Running setup-x86_64.exe on a Windows 10 laptop, I get this error message: > > > > https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line > > 30182: syntax error, unexpected $undefined, expecting COMMA or NL > > https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line > > 30182: unrecognized line 30183 (do you have the latest setup?) > > https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line > > 30203: syntax error, unexpected $undefined, expecting COMMA or NL > > https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line > > 30203: unrecognized line 30204 (do you have the latest setup?) > > > > (I can't copy the text from the message box so I retyped it.) > > Protip: Ctrl-C should work on a message box. Yes, it does! You can't select part of the text and there's no visual feedback, but if you select the message box and type Ctrl-C, it works. That's going to be useful. > > I re-downloaded setup-x86_64.exec, and it's identical to the one on my > > laptop. > > > > I'm using the mirrors.kernel.org mirror. > > The setup.zst from mirrors.dotsrc.org is identical. > > I decompressed setup.zst and I do see something suspicious on the > > indicated lines. > > > > Here's line 30182: > > > > build-depends: \, bison, cygport, dblatex, docbook2X, flex, > > gettext-devel, libGLU-devel, libcairo-devel, libcanberra-gtk-devel, > > libcurl-devel, libfreetype-devel, libglib2.0-devel, libgmp-devel, > > libgtk2.0-devel, libgtkglext1.0-devel, libpango1.0-devel, > > libpng-devel, libreadline-devel, libsqlite3-devel, libxslt, > > python3-devel, texinfo > > > > Line 30203 is similar. I don't see a lone backslash anywhere else in the > > file. > > Yeah, this is wrong. > > I need to investigate further why the mechanisms which should have > caught this didn't. > > > The setup.zst from mirrors.sonic.net does *not* have problematic > > build-depends lines. > > (Switching to a different mirror might be a workaround, but I haven't > > tried it yet.) > > > > The "bad" setup.zst has "setup-timestamp: 1680813730" (Thu 2023-04-06 > > 20:42:10 UTC). > > The "good" setup.zst has "setup-timestamp: 1680795371" (Thu 2023-04-06 > > 15:36:11 UTC). > > The bad one is about 5 hours newer than the good one. > > I'm concerned that the bad setup.zst might propagate to other mirrors. > This is fixed as of setup-timestamp: 1680860048 > > Thanks very much for reporting this. > > Apologies for the inconvenience. The mirror I use (mirrors.kernel.org) now has a setup.zst with a newer timestamp (1680869581) and without the stray backslashes. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error running setup-x86_64.exe: syntax error in setup.zst
On 07/04/2023 02:44, Keith Thompson via Cygwin wrote: Running setup-x86_64.exe on a Windows 10 laptop, I get this error message: https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30182: syntax error, unexpected $undefined, expecting COMMA or NL https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30182: unrecognized line 30183 (do you have the latest setup?) https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30203: syntax error, unexpected $undefined, expecting COMMA or NL https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30203: unrecognized line 30204 (do you have the latest setup?) (I can't copy the text from the message box so I retyped it.) Protip: Ctrl-C should work on a message box. I re-downloaded setup-x86_64.exec, and it's identical to the one on my laptop. I'm using the mirrors.kernel.org mirror. The setup.zst from mirrors.dotsrc.org is identical. I decompressed setup.zst and I do see something suspicious on the indicated lines. Here's line 30182: build-depends: \, bison, cygport, dblatex, docbook2X, flex, gettext-devel, libGLU-devel, libcairo-devel, libcanberra-gtk-devel, libcurl-devel, libfreetype-devel, libglib2.0-devel, libgmp-devel, libgtk2.0-devel, libgtkglext1.0-devel, libpango1.0-devel, libpng-devel, libreadline-devel, libsqlite3-devel, libxslt, python3-devel, texinfo Line 30203 is similar. I don't see a lone backslash anywhere else in the file. Yeah, this is wrong. I need to investigate further why the mechanisms which should have caught this didn't. The setup.zst from mirrors.sonic.net does *not* have problematic build-depends lines. (Switching to a different mirror might be a workaround, but I haven't tried it yet.) The "bad" setup.zst has "setup-timestamp: 1680813730" (Thu 2023-04-06 20:42:10 UTC). The "good" setup.zst has "setup-timestamp: 1680795371" (Thu 2023-04-06 15:36:11 UTC). The bad one is about 5 hours newer than the good one. I'm concerned that the bad setup.zst might propagate to other mirrors. This is fixed as of setup-timestamp: 1680860048 Thanks very much for reporting this. Apologies for the inconvenience. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error running setup-x86_64.exe: syntax error in setup.zst
>> I'm concerned that the bad setup.zst might propagate to other mirrors. Yes, identical error arising at https://cygwin.mirror.uk.sargasso.net/x86_64/setup.zst and elsewhere. -- 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
Error running setup-x86_64.exe: syntax error in setup.zst
Running setup-x86_64.exe on a Windows 10 laptop, I get this error message: https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30182: syntax error, unexpected $undefined, expecting COMMA or NL https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30182: unrecognized line 30183 (do you have the latest setup?) https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30203: syntax error, unexpected $undefined, expecting COMMA or NL https://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.zst line 30203: unrecognized line 30204 (do you have the latest setup?) (I can't copy the text from the message box so I retyped it.) I re-downloaded setup-x86_64.exec, and it's identical to the one on my laptop. I'm using the mirrors.kernel.org mirror. The setup.zst from mirrors.dotsrc.org is identical. I decompressed setup.zst and I do see something suspicious on the indicated lines. Here's line 30182: build-depends: \, bison, cygport, dblatex, docbook2X, flex, gettext-devel, libGLU-devel, libcairo-devel, libcanberra-gtk-devel, libcurl-devel, libfreetype-devel, libglib2.0-devel, libgmp-devel, libgtk2.0-devel, libgtkglext1.0-devel, libpango1.0-devel, libpng-devel, libreadline-devel, libsqlite3-devel, libxslt, python3-devel, texinfo Line 30203 is similar. I don't see a lone backslash anywhere else in the file. The setup.zst from mirrors.sonic.net does *not* have problematic build-depends lines. (Switching to a different mirror might be a workaround, but I haven't tried it yet.) The "bad" setup.zst has "setup-timestamp: 1680813730" (Thu 2023-04-06 20:42:10 UTC). The "good" setup.zst has "setup-timestamp: 1680795371" (Thu 2023-04-06 15:36:11 UTC). The bad one is about 5 hours newer than the good one. I'm concerned that the bad setup.zst might propagate to other mirrors. -- 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: Getting Error while connect to DB2 from Cygwin 64-bit
On 2023-04-04 13:55, Brian Inglis via Cygwin wrote: On 2023-04-04 01:54, Andrey Repin wrote: I'm getting below errors while trying to connect IBM DB2 from 64-bit Cygwin. Please find the below mentioned details. 1)Trying to compile the program using DB2_LIBRARY="C:/Program Files/IBM/SQLLIB/lib/db2api.lib" on 64-bit Cygwin. Is this a Cygwin or native target binary? *ERROR:* /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: *internal error:* aborting at /mnt/share/cygpkgs/binutils/binutils.x86_64/src/binutils-2.40/ld/ldlang.c:527 in compare_section /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: *please report this bug* It seems to me you are trying to mix Cygwin and native Windows code. Don't do that without a very, very good understanding of implications. If you are building using binary code provided by 3rd party vendor, chances are high you are looking at native code and you have to use mingw32 cross-compiler for that build. Presumably these are Windows libraries so you liekly have to use Mingw binutils mingw64-x86_64-binutils /usr/x86_64-w64-mingw32/bin/ and mingw64-x86_64-gcc-core /usr/lib/gcc/x86_64-w64-mingw32/11/ packages under their respective paths, after reading up more about how to use them. Or not: https://www.ibm.com/docs/en/db2/11.5?topic=compilers-c -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Getting Error while connect to DB2 from Cygwin 64-bit
On 2023-04-04 01:54, Andrey Repin wrote: I'm getting below errors while trying to connect IBM DB2 from 64-bit Cygwin. Please find the below mentioned details. 1)Trying to compile the program using DB2_LIBRARY="C:/Program Files/IBM/SQLLIB/lib/db2api.lib" on 64-bit Cygwin. Is this a Cygwin or native target binary? *ERROR:* /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: *internal error:* aborting at /mnt/share/cygpkgs/binutils/binutils.x86_64/src/binutils-2.40/ld/ldlang.c:527 in compare_section /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: *please report this bug* It seems to me you are trying to mix Cygwin and native Windows code. Don't do that without a very, very good understanding of implications. If you are building using binary code provided by 3rd party vendor, chances are high you are looking at native code and you have to use mingw32 cross-compiler for that build. Presumably these are Windows libraries so you liekly have to use Mingw binutils mingw64-x86_64-binutils /usr/x86_64-w64-mingw32/bin/ and mingw64-x86_64-gcc-core /usr/lib/gcc/x86_64-w64-mingw32/11/ packages under their respective paths, after reading up more about how to use them. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Getting Error while connect to DB2 from Cygwin 64-bit
Greetings, rajesh kesavan! > I'm getting below errors while trying to connect IBM DB2 from 64-bit > Cygwin. Please find the below mentioned details. > 1)Trying to compile the program using DB2_LIBRARY="C:/Program > Files/IBM/SQLLIB/lib/db2api.lib" on 64-bit Cygwin. Is this a Cygwin or native target binary? > *ERROR:* > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: > *internal > error:* aborting at > /mnt/share/cygpkgs/binutils/binutils.x86_64/src/binutils-2.40/ld/ldlang.c:527 > in compare_section > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: *please > report this bug* It seems to me you are trying to mix Cygwin and native Windows code. Don't do that without a very, very good understanding of implications. If you are building using binary code provided by 3rd party vendor, chances are high you are looking at native code and you have to use mingw32 cross-compiler for that build. > 3)Compilation is done but getting an error while Trying to connect IBM DB2 > using DB2_LIBRARY="C:/Program Files/IBM/SQLLIB/BIN/db2app64.dll" on 64-bit > Cygwin. > *ERROR:* > sqlcode=*808517647* > This "*sqlcode=808517647*" error code looks like an abnormal error and it > is not present in db2 documents. > *Details:* > $ gcc --version > *gcc (GCC) 11.3.0* > Copyright (C) 2021 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > $ ld --version > *GNU ld (GNU Binutils) 2.40* > Copyright (C) 2023 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later > version. > This program has absolutely no warranty. > Please let me know if you want more details. -- With best regards, Andrey Repin Tuesday, April 4, 2023 10:33:35 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Getting Error while connect to DB2 from Cygwin 64-bit
Hi, I'm getting below errors while trying to connect IBM DB2 from 64-bit Cygwin. Please find the below mentioned details. 1)Trying to compile the program using DB2_LIBRARY="C:/Program Files/IBM/SQLLIB/lib/db2api.lib" on 64-bit Cygwin. *ERROR:* /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: *internal error:* aborting at /mnt/share/cygpkgs/binutils/binutils.x86_64/src/binutils-2.40/ld/ldlang.c:527 in compare_section /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: *please report this bug* 2)When Trying to compile using DB2_LIBRARY="C:/Program Files/IBM/SQLLIB/lib/Win32/db2api.lib" on 64-bit Cygwin. *ERROR:* undefined reference to `sqlacall' undefined reference to `sqlastop' undefined reference to `sqlaaloc' undefined reference to `sqlasetdata' undefined reference to `sqlastrt' [*Note :* the same is working fine on 32 bit Cygwin using DB2_LIBRARY="C:/Program Files/IBM/SQLLIB/lib/Win32/db2api.lib"] 3)Compilation is done but getting an error while Trying to connect IBM DB2 using DB2_LIBRARY="C:/Program Files/IBM/SQLLIB/BIN/db2app64.dll" on 64-bit Cygwin. *ERROR:* sqlcode=*808517647* This "*sqlcode=808517647*" error code looks like an abnormal error and it is not present in db2 documents. *Details:* $ gcc --version *gcc (GCC) 11.3.0* Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ld --version *GNU ld (GNU Binutils) 2.40* Copyright (C) 2023 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Please let me know if you want more details. Thanks and Regards, Rajesh K. -- 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: 'tac' trying to use "/tmp"; Error: not found
On 2023-04-02 21:22, marco atzeri wrote:
On Sun, Apr 2, 2023 at 9:43 PM Prof. Luis G. Uribe C. wrote:
*| 'tac' utility dies with a not found "/tmp" error. |*
It is preferable to copy the exact command(s) and output into your problem
report. Presumably the input is a pipe or non-seekable device which needs
buffered in a temp file.
I didn't see this problem in older 'tac' versions...
I created "/tmp" under my root directory:
*"c:\tmp"* (Windows 10), *to no avail*.
I make a *tmp* dir directly *above*, in the *parent's 'tac' dir*:
*"../tmp"*, at the same level as other usual folders like:
*bin*, *dev*, *etc*, *lib*, *sbin*...,
and now: *'**tac' works fine**!*
The /tmp directory needs to be created in the Cygwin POSIX root directory "/".
[I am surprised GNU tac does not yet use mmap where available, as an alternative
to seek, as mmap has been around for decades, since 4.4BSD, SysVr4, and Solaris
2.0 days, and should be faster on huge files.]
The expectation for the existence of /tmp directory is well founded
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I assume by accident your installation pruned the directory.
I will not be surprised if other programs also complain, not only tac
You can point to another dir under a shell (or export the env var) using e.g.
$ export TMPDIR=${TMP:-${TEMP:-/tmp}}
or
$ TMPDIR=. tac ...
If you have Cygwin bash and coreutils installed, under bash or a similar shell
with brace expansion you can restore the install directories with:
$ /bin/mkdir -pv -m 0755 /{bin,dev,etc,lib} \
/usr/{bin,lib,local/{bin,etc,lib},src}
$ /bin/mkdir -pv -m 01777 /dev/{mqueue,shm} /etc/fstab.d \
/{home,{,usr/}tmp} /var/{log,run,tmp}
$ /bin/mkdir -pv -m 0666 /var/run/utmp
see:
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=install.cc#l156
If the directories do not have the correct permissions, use chmod to fix them.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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: 'tac' trying to use "/tmp"; Error: not found
On Sun, Apr 2, 2023 at 9:43 PM Prof. Luis G. Uribe C. via Cygwin wrote: > > *Bogotá, Sunday April 2nd, 2023* > > *REF: 'tac' trying to use "/tmp"; Error: not found* > *___* > *| 'tac' utility dies with a not found "/tmp" error. |* > *¯¯¯* > I didn't see this problem in older 'tac' versions... > > I created "/tmp" under my root directory: > *"c:\tmp"* (Windows 10), *to no avail*. > > I make a *tmp* dir directly *above*, in the *parent's 'tac' dir*: > *"../tmp"*, at the same level as other usual folders like: > *bin*, *dev*, *etc*, *lib*, *sbin*..., > and now: *'**tac' works fine**!* The expectation for the existence of /tmp directory is well founded https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard I assume by accident your installation pruned the directory. I will not be surprised if other programs also complain, not only tac > Best regards, > > *Eng. Luis G. Uribe C.* > Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
'tac' trying to use "/tmp"; Error: not found
*Bogotá, Sunday April 2nd, 2023* *REF: 'tac' trying to use "/tmp"; Error: not found* *___* *| 'tac' utility dies with a not found "/tmp" error. |* *¯¯¯* I didn't see this problem in older 'tac' versions... I created "/tmp" under my root directory: *"c:\tmp"* (Windows 10), *to no avail*. I make a *tmp* dir directly *above*, in the *parent's 'tac' dir*: *"../tmp"*, at the same level as other usual folders like: *bin*, *dev*, *etc*, *lib*, *sbin*..., and now: *'**tac' works fine**!* I think that in *line 70 of "tac.c"*: *ID: tac (GNU coreutils) 9.0Packaged by Cygwin (9.0-1)Copyright (C) 2021 Free Software Foundation, Inc.* ...if it is defined as: *#define DEFAULT_TMPDIR "**..**/tmp"* *instead of* the *actual*: *#define DEFAULT_TMPDIR "/tmp"* it could work fine! Best regards, *Eng. Luis G. Uribe C.* -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ERROR] Locale Monetary Symbol Prints Wrongly on Windows : Cygwin
On Mar 14 09:30, Yeo Kai Wei via Cygwin wrote: > Hi Corinna, > > I can't update to 3.5+, I tried reinstalling using the Cygwin setup > > Using "uname -a", my current version is 3.4.6-1.x86_64. > > I assume 3.5 hasn't been released officially. > > May I know where to get the test release? In setup. Use the version pulldown menu on the right side of the "New" column, or the "Test" check mark at the top right. Corinna -- 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
