Executables fail to run when they are named as 'setlang.exe'
Hi
I've noticed that executables fail to run when they are named as
'setlang.exe'.
Is this a known problem, or something related to BLODA ?
* Example 1) This will output 'no'.
```
cp /usr/bin/ls setlang
./setlang && echo ok || echo no
```
* Example 2) This will output 'ok' and 'no'.
```
echo "int main () {}" > z.c
gcc z.c
cp a setlang
./a && echo ok || echo no
./setlang && echo ok || echo no
```
In my environment, `uname -srvmo` is:
CYGWIN_NT-10.0 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
Regards,
Lem
--
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: Executables fail to run when they are named as 'setlang.exe'
On 18.01.2021 09:51, Lemures Lemniscati via Cygwin wrote: Hi I've noticed that executables fail to run when they are named as 'setlang.exe'. Is this a known problem, or something related to BLODA ? * Example 1) This will output 'no'. ``` cp /usr/bin/ls setlang ./setlang && echo ok || echo no ``` it is a BLODA. May be MS itself $ cd /tmp $ cp /usr/bin/ls setlang $ ./setlang.exe - exitmap.text.gzip acrocef_lowfam-Marco map.text2 acrord32_sbx. -- 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: Executables fail to run when they are named as 'setlang.exe'
On Mon, 18 Jan 2021 10:43:55 +0100, Marco Atzeri via Cygwin > On 18.01.2021 09:51, Lemures Lemniscati via Cygwin wrote: > > Hi > > > > I've noticed that executables fail to run when they are named as > > 'setlang.exe'. > > > > Is this a known problem, or something related to BLODA ? > > > > > > * Example 1) This will output 'no'. > > > > ``` > > cp /usr/bin/ls setlang > > ./setlang && echo ok || echo no > > ``` > > it is a BLODA. May be MS itself > Thank you. I've found that 'Exploit Protection' by /DYNAMICBASE interferes it. Regards, Lem -- 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 have a problem with some applications in Cygwin (SOLVED)
> -Original Message- > From: Eirik Nordbrøden > Sent: torsdag 22. oktober 2020 16:16 > To: Cygwin (cygwin@cygwin.com) > Subject: I have a problem with some applications in Cygwin > > Hello > > I have been using for many years and have not really had any major > problems, but now I have run into a problem with some of the applications in > Cygwin that I have been struggling with for some time without being able to > solve it. Hopefully someone in this list can point me in the right direction > to > fix the problem. > > I have a new Windows 10 PC with a fresh Cygwin installation, but struggles > with some of the applications that I have installed. When I try to use > applications like ssh, ssh-keygen, git, snmpwalk, snmpnext etc. they all just > hangs and I am not able to stop them through CTRL-C. I need to use Task > Manager to kill the application (kill -9 does not work either). But if I run > the > application from gdb (like 'gdb ssh-keygen' and the 'run') they seem to work. > Most applications seems to work as expected, but not the ones I have listed > (and maybe some more applications as well). > > I think that this might be due to something in my PC, but are not able to > pinpoint it. At one point I thought that this was due to the virus control in > the > PC (Trend), but now I have uninstalled this and just uses Windows defender. > > Eirik Nordbrøden, Netnordic AS > (+47) 90174789 Hello I have now found the cause of this problem. As suspected it was a problem on my PC, but I would like to inform about the cause in case other people have a similar problem. The root cause was that the Citrix Workspace app installed on my PC had application protection enabled. This interfered with some of the Cygwin apps (mainly ssh and apps using ssh, but also others) so I had to reinstall this app without application protection enabled. Eirik Nordbrøden, Netnordic AS (+47) 90174789 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: gdb not working
On Friday, January 15, 2021 9:02 PM Ken Brown wrote: >On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote: >> On Friday, January 15, 2021 4:45 PM Jon Turney wrote: >>> On 15/01/2021 12:28, Lemke, Michael wrote: I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe. However, gdb does not produce any output. Installing gdb versions 7.9.1-1 and 7.10.1-1 work, anything newer doesn't. Any ideas why? >>> [...] >>> Install gdb 7.12.1-2 pc> gdb -v Install gdb 8.0.1-1 pc> gdb -v pc> cygcheck -c gdb Cygwin Package Information Package VersionStatus gdb 8.0.1-1OK >>> >>> You might try 'strace gdb' and see if that sheds any light on what's >>> failing. >> >> I tried that but I couldn't see anything strange. > >No error code? Please show the output. pc> gdb -v pc> echo $? 0 > >> Also ldd `which gdb` is >> fine. > >Please show the output. pc> ldd `which gdb` ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffde2c) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffdce4) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fffdb57) cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x3fe90) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3fc1b) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3fe77) cygwin1.dll => /usr/bin/cygwin1.dll (0x18004) cygmpfr-6.dll => /usr/bin/cygmpfr-6.dll (0x3f9db) cyglzma-5.dll => /usr/bin/cyglzma-5.dll (0x3fa16) libpython3.6m.dll => /usr/bin/libpython3.6m.dll (0x3f78d) cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x3fbd7) cygreadline7.dll => /usr/bin/cygreadline7.dll (0x3f90d) cygz.dll => /usr/bin/cygz.dll (0x3f7e1) cygsource-highlight-4.dll => /usr/bin/cygsource-highlight-4.dll (0x3f8c7) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884) cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3fd8e) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360) cygboost_regex-1_66.dll => /usr/bin/cygboost_regex-1_66.dll (0x3ff52) cygicui18n61.dll => /usr/bin/cygicui18n61.dll (0x3fc3e) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360) cygicudata61.dll => /usr/bin/cygicudata61.dll (0x3fa3c) > >> I tried the cygcheck Marco Atzeri suggested. I am not comfortable to send >> the result to the list but I checked it. > >Can you remove the sensitive parts and then send it? It's hard for anyone on >the list to help you if you don't provide information about your installation. I'll see what I can do. > >> As a result I cleaned up my path to just /bin which removed some duplicate >> entries in cygcheck.out but gdb still doesn't work. >> >> The only strange part I see in cygcheck.out is a slight mess up with my >> installation, a result of my moving /c/cygwin64 to /c/mystuff/ncygwin64 >> after my first run of setup.exe, see below. So what has changed between >> gdb 7.10.1-1 and gdb 7.12.1-2? > >Dependencies may have changed. Have you checked that you have all >dependencies >of whatever version you're trying to run? Just re-running setup should take >care of that if that's the problem. I've always installed every version with setup so the dependencies should have been taken care of. And pc> cygcheck -c gdb Cygwin Package Information Package VersionStatus gdb 9.2-1 OK And one more: pc> gdb -v >& blah pc> cat blah pc> i.e. empty file blah. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: gdb not working
On 18.01.2021 14:08, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 9:02 PM Ken Brown wrote: On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 4:45 PM Jon Turney wrote: On 15/01/2021 12:28, Lemke, Michael wrote: I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe. However, gdb does not produce any output. Also ldd `which gdb` is fine. Please show the output. pc> ldd `which gdb` cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) this is very low cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360) I do not see duplicate entries on my system. it seems a BLODA is interfering with dll's loading -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: gdb not working
On Monday, January 18, 2021 2:23 PM Marco Atzeri wrote: >On 18.01.2021 14:08, Lemke, Michael SF/HZA-ZIC2 wrote: >> On Friday, January 15, 2021 9:02 PM Ken Brown wrote: >>> On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 4:45 PM Jon Turney wrote: > On 15/01/2021 12:28, Lemke, Michael wrote: >> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe. >> However, gdb does not produce any output. >> >> >>> Also ldd `which gdb` is fine. >>> >>> Please show the output. >> >> pc> ldd `which gdb` > >> cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) >> cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884) > >> cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) >this is very low >> cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360) > >> cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24) >> cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360) > > >I do not see duplicate entries on my system. it seems a BLODA >is interfering with dll's loading > It might very well be. I also noticed the output of ldd is not reproducible. It shows different duplicate entries when run repeatedly and the load address you marked is also a duplicate: pc> ldd `which gdb`|grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0xa) Hm, is gdb dependent on gcc? I just noticed my gcc is apparently broken: pc> cygcheck -c gcc Cygwin Package Information Package VersionStatus pc> Other than going through the published BLODA list is there a way I could test and find out what is interfering? I ask because we have a lot of stuff installed for teleworking, especially on the network side. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: gdb not working
On Monday, January 18, 2021 2:54 PM Lemke, Michael SF/HZA-ZIC2 wrote: >On Monday, January 18, 2021 2:23 PM Marco Atzeri wrote: >On 18.01.2021 14:08, Lemke, Michael SF/HZA-ZIC2 wrote: >> On Friday, January 15, 2021 9:02 PM Ken Brown wrote: >>> On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 4:45 PM Jon Turney wrote: > On 15/01/2021 12:28, Lemke, Michael wrote: >> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe. >> However, gdb does not produce any output. >> >> >>> Also ldd `which gdb` is fine. >>> >>> Please show the output. >> >> pc> ldd `which gdb` > >> cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) >> cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884) > >> cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) >this is very low >> cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360) > >> cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24) >> cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360) > > >I do not see duplicate entries on my system. it seems a BLODA >is interfering with dll's loading > It might very well be. I also noticed the output of ldd is not reproducible. It shows different duplicate entries when run repeatedly and the load address you marked is also a duplicate: pc> ldd `which gdb`|grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0xa) Hm, is gdb dependent on gcc? I just noticed my gcc is apparently broken: pc> cygcheck -c gcc Cygwin Package Information Package VersionStatus pc> P.S.: pc> cygcheck -c gcc Cygwin Package Information Package VersionStatus pc> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/10/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0/configure --srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --with-gcc-major-version-only --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-l inker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) And I can compile C programs. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygssh-4.dll
Hi all- Thanks Marco for helping with ssh! I get error cygssh_threads-4.dll cant open when I try to launch remmina. Can someone help me fix? I am missing a package. Have cool Monday! Robo-loki -- 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: Cygssh-4.dll
On Mon, Jan 18, 2021, 11:09 AM Jim McNamara wrote: > Hi all- > > Thanks Marco for helping with ssh! > > I get error cygssh_threads-4.dll cant open when I try to launch remmina. > Can someone help me fix? > > I am missing a package. > > Have cool Monday! > > Robo-loki > > Hi all- > Just needed to update package that provides cygssh-4.dll Thanks, Roboloki > -- 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: Cygssh-4.dll
On Mon, Jan 18, 2021, 11:41 AM Jim McNamara wrote: > > > On Mon, Jan 18, 2021, 11:09 AM Jim McNamara > wrote: > >> Hi all- >> >> Thanks Marco for helping with ssh! >> >> I get error cygssh_threads-4.dll cant open when I try to launch remmina. >> Can someone help me fix? >> >> I am missing a package. >> >> Have cool Monday! >> >> Robo-loki >> >> Hi all- >> > Just needed to update package that provides cygssh-4.dll > > Thanks, > Roboloki > I had older version... Roboloki > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: gdb not working
On 1/18/2021 8:54 AM, Lemke, Michael SF/HZA-ZIC2 wrote: On Monday, January 18, 2021 2:23 PM Marco Atzeri wrote: On 18.01.2021 14:08, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 9:02 PM Ken Brown wrote: On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 4:45 PM Jon Turney wrote: On 15/01/2021 12:28, Lemke, Michael wrote: I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe. However, gdb does not produce any output. Also ldd `which gdb` is fine. Please show the output. pc> ldd `which gdb` cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) this is very low cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360) I do not see duplicate entries on my system. it seems a BLODA is interfering with dll's loading It might very well be. I also noticed the output of ldd is not reproducible. It shows different duplicate entries when run repeatedly and the load address you marked is also a duplicate: pc> ldd `which gdb`|grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) pc> ldd `which gdb` | grep --color gcc cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0xa) Hm, is gdb dependent on gcc? I just noticed my gcc is apparently broken: pc> cygcheck -c gcc Cygwin Package Information Package VersionStatus The package containing gcc is called "gcc-core", not "gcc": $ cygcheck -f /usr/bin/gcc.exe gcc-core-10.2.0-1 $ cygcheck -c gcc-core Cygwin Package Information Package VersionStatus gcc-core 10.2.0-1 OK Other than going through the published BLODA list is there a way I could test and find out what is interfering? I ask because we have a lot of stuff installed for teleworking, especially on the network side. You can sometimes catch BLODA by running strace. It may show some DLL being loaded that shouldn't be, typically from security software. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: gdb not working
[Resending. Accidentally sent to OP instead of list.] On 1/18/2021 8:08 AM, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 9:02 PM Ken Brown wrote: On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote: On Friday, January 15, 2021 4:45 PM Jon Turney wrote: On 15/01/2021 12:28, Lemke, Michael wrote: I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe. However, gdb does not produce any output. Installing gdb versions 7.9.1-1 and 7.10.1-1 work, anything newer doesn't. Any ideas why? [...] Install gdb 7.12.1-2 pc> gdb -v Install gdb 8.0.1-1 pc> gdb -v pc> cygcheck -c gdb Cygwin Package Information Package VersionStatus gdb 8.0.1-1OK You might try 'strace gdb' and see if that sheds any light on what's failing. I tried that but I couldn't see anything strange. No error code? Please show the output. pc> gdb -v pc> echo $? 0 I was asking for the strace output. It might just show the same DLL loading issues that Marco noticed, or it might show something more. Also ldd `which gdb` is fine. Please show the output. pc> ldd `which gdb` ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffde2c) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffdce4) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fffdb57) cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x3fe90) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3fc1b) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3fe77) cygwin1.dll => /usr/bin/cygwin1.dll (0x18004) cygmpfr-6.dll => /usr/bin/cygmpfr-6.dll (0x3f9db) cyglzma-5.dll => /usr/bin/cyglzma-5.dll (0x3fa16) libpython3.6m.dll => /usr/bin/libpython3.6m.dll (0x3f78d) cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x3fbd7) cygreadline7.dll => /usr/bin/cygreadline7.dll (0x3f90d) cygz.dll => /usr/bin/cygz.dll (0x3f7e1) cygsource-highlight-4.dll => /usr/bin/cygsource-highlight-4.dll (0x3f8c7) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fdf6) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3f884) cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3fd8e) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x17) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x360) cygboost_regex-1_66.dll => /usr/bin/cygboost_regex-1_66.dll (0x3ff52) cygicui18n61.dll => /usr/bin/cygicui18n61.dll (0x3fc3e) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x3fc24) cygicuuc61.dll => /usr/bin/cygicuuc61.dll (0x360) cygicudata61.dll => /usr/bin/cygicudata61.dll (0x3fa3c) I tried the cygcheck Marco Atzeri suggested. I am not comfortable to send the result to the list but I checked it. Can you remove the sensitive parts and then send it? It's hard for anyone on the list to help you if you don't provide information about your installation. I'll see what I can do. As a result I cleaned up my path to just /bin which removed some duplicate entries in cygcheck.out but gdb still doesn't work. The only strange part I see in cygcheck.out is a slight mess up with my installation, a result of my moving /c/cygwin64 to /c/mystuff/ncygwin64 after my first run of setup.exe, see below. So what has changed between gdb 7.10.1-1 and gdb 7.12.1-2? Dependencies may have changed. Have you checked that you have all dependencies of whatever version you're trying to run? Just re-running setup should take care of that if that's the problem. I've always installed every version with setup so the dependencies should have been taken care of. And pc> cygcheck -c gdb Cygwin Package Information Package VersionStatus gdb 9.2-1 OK cygcheck doesn't check dependencies. But that doesn't appear to be the issue anyway. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: gdb not working
On Monday, January 18, 2021 5:53 PM Ken Brown wrote:
>
>[Resending. Accidentally sent to OP instead of list.]
{Happens here too. Reply All or Reply (in Outlook) both send to OP instead of
list.]
>
>On 1/18/2021 8:08 AM, Lemke, Michael SF/HZA-ZIC2 wrote:
>> On Friday, January 15, 2021 9:02 PM Ken Brown wrote:
>>> On 1/15/2021 1:47 PM, Lemke, Michael SF/HZA-ZIC2 wrote:
On Friday, January 15, 2021 4:45 PM Jon Turney wrote:
> On 15/01/2021 12:28, Lemke, Michael wrote:
>> I just installed a fresh copy of Cygwin and gdb with setup-x86_64.exe.
>> However, gdb does not produce any output.
>>
>> Installing gdb versions 7.9.1-1 and 7.10.1-1 work, anything newer
>> doesn't.
>> Any ideas why?
> [...]
>
>> Install gdb 7.12.1-2
>> pc> gdb -v
>> Install gdb 8.0.1-1
>> pc> gdb -v
>> pc> cygcheck -c gdb
>> Cygwin Package Information
>> Package VersionStatus
>> gdb 8.0.1-1OK
>
> You might try 'strace gdb' and see if that sheds any light on what's
> failing.
I tried that but I couldn't see anything strange.
>>>
>>> No error code? Please show the output.
>>
>> pc> gdb -v
>> pc> echo $?
>> 0
>
>I was asking for the strace output. It might just show the same DLL loading
>issues that Marco noticed, or it might show something more.
>
Ok, here are the first 100 lines, the whole thing is over 2MB. To me this
looks strange already (cygstdc++-6.dll).
--- Process 32204 created
--- Process 32204 loaded C:\Windows\System32\ntdll.dll at 7fffde2c
--- Process 32204 loaded C:\Windows\System32\kernel32.dll at 7fffdce4
--- Process 32204 loaded C:\Windows\System32\KernelBase.dll at 7fffdb57
--- Process 32204 thread 13420 created
--- Process 32204 thread 32700 created
--- Process 32204 thread 25220 created
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygwin1.dll at
00018004
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygintl-8.dll at
0003fbff
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygiconv-2.dll at
0003fe77
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygncursesw-10.dll at
0003fbd7
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygexpat-1.dll at
0003fe90
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cyglzma-5.dll at
0003f9e6
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygmpfr-6.dll at
0003f9aa
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygz.dll at 0003f7b0
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\libpython3.6m.dll at
0003f75c
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygreadline7.dll at
0003f8dc
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cyggcc_s-seh-1.dll at
0003fdf6
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygsource-highlight-4.dll at
0003f896
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygstdc++-6.dll at
0003f853
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cyggmp-10.dll at
0003fd72
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygboost_regex-1_66.dll at
0003ff52
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygstdc++-6.dll at
034d
--- Process 32204 unloaded DLL at 034d
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicui18n61.dll at
0003fc22
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicuuc61.dll at
0003fc08
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicudata61.dll at
0003fa3c
--- Process 32204 loaded C:\MyStuff\NCygwin64\bin\cygicuuc61.dll at
034d
--- Process 32204 unloaded DLL at 034d
3 3 [main] gdb (32204) **
654 657 [main] gdb (32204) Program name: C:\MyStuff\NCygwin64\bin\gdb.exe
(windows pid 32204)
180 837 [main] gdb (32204) OS version: Windows NT-10.0
141 978 [main] gdb (32204) **
--- Process 32204 loaded C:\Windows\System32\advapi32.dll at 7fffdd70
--- Process 32204 loaded C:\Windows\System32\msvcrt.dll at 7fffdc5a
--- Process 32204 loaded C:\Windows\System32\sechost.dll at 7fffdc6f
--- Process 32204 loaded C:\Windows\System32\rpcrt4.dll at 7fffdd7b
--- Process 32204 loaded C:\Windows\System32\cryptbase.dll at 7fffdab8
--- Process 32204 loaded C:\Windows\System32\bcryptprimitives.dll at
7fffdb35
58966874 [main] gdb (32204) sigprocmask: 0 = sigprocmask (0, 0x0,
0x180324D70)
3918 10792 [main] gdb (32204) open_shared: name shared.5, n 5, shared
0x18003 (wanted 0x18003), h 0xF0, *m 6
143 10935 [main] gdb (32204) user_heap_info::init: heap base 0x8,
heap top 0x8, heap size 0x2000 (536870912)
182 7 [main] gdb (32204) open_shared: name
S-1-5-21-435809281-806517502-2525237208-127212.1, n 1, shared 0x18002
Re: gdb not working
On 1/18/2021 12:35 PM, Lemke, Michael SF/HZA-ZIC2 wrote: On Monday, January 18, 2021 5:53 PM Ken Brown wrote: I was asking for the strace output. It might just show the same DLL loading issues that Marco noticed, or it might show something more. Ok, here are the first 100 lines, the whole thing is over 2MB. To me this looks strange already (cygstdc++-6.dll). [...] --- Process 32204 loaded C:\Program Files\Common Files\McAfee\SystemCore\mfehcthe.dll at 52b5 --- Process 32204 loaded C:\Program Files\McAfee\Endpoint Security\Adaptive Threat Protection\mfedeeprem64.dll at 7fffcc70 This could be the culprit. Can you exclude your Cygwin directory from McAfee? Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: gdb not working
On Monday, January 18, 2021 6:42 PM Ken Brown wrote: >On 1/18/2021 12:35 PM, Lemke, Michael SF/HZA-ZIC2 wrote: >> On Monday, January 18, 2021 5:53 PM Ken Brown wrote: >>> I was asking for the strace output. It might just show the same DLL loading >>> issues that Marco noticed, or it might show something more. >>> >> >> Ok, here are the first 100 lines, the whole thing is over 2MB. To me this >> looks strange already (cygstdc++-6.dll). >[...] >> --- Process 32204 loaded C:\Program Files\Common >> Files\McAfee\SystemCore\mfehcthe.dll at 52b5 >> --- Process 32204 loaded C:\Program Files\McAfee\Endpoint Security\Adaptive >> Threat Protection\mfedeeprem64.dll at 7fffcc70 > >This could be the culprit. Can you exclude your Cygwin directory from McAfee? Unfortunately not. It is managed centrally. But then good to know I can't use gdb here. I feel safe now... Thanks for all your help. Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: fontforge-20201107p8-1 (promoted to current)
The following packages have been promoted from test to current: * fontforge-20201107p8-1 * fontforge-common-20201107p8-1 * fontforge-doc-20201107p8-1 * libfontforge4-20201107p8-1 * libfontforge-devel-20201107p8-1 * python38-fontforge-20201107p8-1 * fontforge-20201107p8-1-src * fontforge-debuginfo-20201107p8-1 This is an update to the latest upstream release, which is the Anniversary release with additional bug fixes. -- FontForge 20201107 at 7aeed0d93 (8 commits after 20201107) An outline font editor that lets you create your own postscript, truetype, opentype, cid-keyed, multi-master, cff, svg and bitmap (bdf, FON, NFNT) fonts, or edit existing ones. Also lets you convert one format to another. Home Page: https://fontforge.org/ Source: https://github.com/fontforge/fontforge/tree/7aeed0d936590093c6c4a827c6cd85c60ebabc0f News: https://github.com/fontforge/fontforge/releases/tag/20201107 License: Revised BSD License GNU General Public License v3.0 The Open Group License https://github.com/fontforge/fontforge/blob/20201107/LICENSE Cygwin Package Summary: https://www.cygwin.com/packages/summary/fontforge-src.html Cygport Source: https://cygwin.com/git/?p=git/cygwin-packages/fontforge.git -- Lemures Lemniscati -- 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: How to reinstall everything?
On 2021-01-17 13:53, matthew patton via Cygwin wrote: On Sunday, January 17, 2021, 02:44:37 PM EST, Achim Gratz wrote: matthew patton via Cygwin writes: can we fix setup.exe to read STDIN with '-P', like so? echo 'pkg1,pkg2,pkg3' | setup.exe -P - You probably forgot that setup is a Windows program. besides, you must not start it from the Cygwin that you are about to install a package into. For years I've run Cygwin Setup from a script that: * checks if a new version gets downloaded and verifies it; * downloads and verifies setup.ini, checking if my nearby mirror is up and up to date; * starts Task Scheduler to allow me to run elevated shut down tasks for old cron processes, Cygwin services, remaining detached processes; * starts Task Manager/Details/order by Image Path to check all processes are gone and allow me to deal with any left; * starts Cygwin Setup with my setup.rc parameters and any new packages to install; * kills off interactive mintty, console and pty X, bash, and its own process. so Windows programs can't be written to read from STDIN? I can't think of any Unix utility that uses commas to delimit. And any Windows one that uses commas is clearly improper/wrong as well. If "you're not supposed to invoke setup.exe from within cygwin" were true then all the 'xargs' and 'paste' workarounds are null and void. And no, I don't automatically reach for xargs to bandaid around poorly written programs that violate 50 years of convention. It's a Windows program with 20 years of its own history built with no proprietary tools! You can change it. Remember it was only recently that Windows gained support for quoted command line and long args, so work arounds to allow running with argument lists from command.com and .bat scripts were required, and have been retained for compatibility with downstream usages. Window utilities with similar requirements have each added their own unique option handling quirks to deal with them e.g. > sc = ... -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
