FPE_FLTSUB where FLT_FLTINV is expected

2018-06-25 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C]
Hello, The following code produces FPE_FLTSUB(22) for the signal code whereas all platforms (Linux, Mac, FreeBSD) where I tested it, consistently yield FPE_FLTINV (which on CYGWIN has a value of 21): #define _GNU_SOURCE #include #include #include #include #include void sigfpe(int signo, si

Re: Date field of ls -l command is garbled in latest cygwin1.dll snapshot.

2018-06-25 Thread Thomas Wolff
Am 25.06.2018 um 13:20 schrieb Takashi Yano: Hi Corinna, On Mon, 25 Jun 2018 11:14:32 +0200 Corinna Vinschen wrote: Takashi, does your patch on cygwin-patches take this into account? I think Thomas has a good point here, the generated files should always match a single version. I submitted a

Re: sshd issues on Windows 10 version 1803

2018-06-25 Thread Hiya Z
>Btw., I can't reproduce this problem. Cygwin's sshd service always >starts for me at boottime as expected. >Did you check if the log file in /var/log contains any more info? I see nothing in /var/log/sshd.log. Windows event log shows following errors: -- Error 6/20/2018 3:45:19 PM Servi

Re: UTF-8 character encoding

2018-06-25 Thread Lee
On 6/24/18, L A Walsh wrote: > Lee wrote: >> So... keep it simple, set >> LANG=en_US.UTF-8 >> and use vi or something else that comes with cygwin to create the file >> and I'll have a file with UTF-8 character encoding - correct? > --- > The first 127 characters of UTF-8 are identical to t

Re: sshd issues on Windows 10 version 1803

2018-06-25 Thread Corinna Vinschen
On Jun 25 16:08, Corinna Vinschen wrote: > On Jun 25 14:10, Corinna Vinschen wrote: > > On Jun 22 11:27, Hiya Z wrote: > > > Hello, > > > > > > Now that Microsoft has bundled OpenSSH for Windows in update 1803 (see > > > https://blogs.msdn.microsoft.com/commandline/2018/03/07/windows10v1803/), > >

Re: sshd issues on Windows 10 version 1803

2018-06-25 Thread Corinna Vinschen
On Jun 25 14:10, Corinna Vinschen wrote: > On Jun 22 11:27, Hiya Z wrote: > > Hello, > > > > Now that Microsoft has bundled OpenSSH for Windows in update 1803 (see > > https://blogs.msdn.microsoft.com/commandline/2018/03/07/windows10v1803/), > > here are some observations and the resulting unfortu

Re: linker error with gcc flag -mfunction-return=thunk

2018-06-25 Thread Corinna Vinschen
[Cc'ing JonY and Yaakov, just for pinging] On Jun 25 14:41, Corinna Vinschen wrote: > On Jun 25 14:16, Corinna Vinschen wrote: > > On Jun 25 14:08, Michael Haubenwallner wrote: > > > Hi, > > > > > > I'm encountering a package's configure script (openssh-7.7p1) that > > > successfully tests for th

Re: linker error with gcc flag -mfunction-return=thunk

2018-06-25 Thread Corinna Vinschen
On Jun 25 14:16, Corinna Vinschen wrote: > On Jun 25 14:08, Michael Haubenwallner wrote: > > Hi, > > > > I'm encountering a package's configure script (openssh-7.7p1) that > > successfully tests for the compiler flag "-mfunction-return=thunk", > > which causes subsequent linker errors (and fails t

Re: linker error with gcc flag -mfunction-return=thunk

2018-06-25 Thread Corinna Vinschen
On Jun 25 14:08, Michael Haubenwallner wrote: > Hi, > > I'm encountering a package's configure script (openssh-7.7p1) that > successfully tests for the compiler flag "-mfunction-return=thunk", > which causes subsequent linker errors (and fails to identify zlib): > relocation truncated to fit: R_X

Re: sshd issues on Windows 10 version 1803

2018-06-25 Thread Corinna Vinschen
On Jun 22 11:27, Hiya Z wrote: > Hello, > > Now that Microsoft has bundled OpenSSH for Windows in update 1803 (see > https://blogs.msdn.microsoft.com/commandline/2018/03/07/windows10v1803/), > here are some observations and the resulting unfortunate behavior: > > - On a clean vanilla 1803 instal

linker error with gcc flag -mfunction-return=thunk

2018-06-25 Thread Michael Haubenwallner
Hi, I'm encountering a package's configure script (openssh-7.7p1) that successfully tests for the compiler flag "-mfunction-return=thunk", which causes subsequent linker errors (and fails to identify zlib): relocation truncated to fit: R_X86_64_32S against `.text' The compiler used is gcc-7.3.0

Re: Date field of ls -l command is garbled in latest cygwin1.dll snapshot.

2018-06-25 Thread Takashi Yano
Hi Corinna, On Mon, 25 Jun 2018 11:14:32 +0200 Corinna Vinschen wrote: > Takashi, does your patch on cygwin-patches take this into account? > > I think Thomas has a good point here, the generated files should > always match a single version. I submitted a new patch taking that point into account

Re: Date field of ls -l command is garbled in latest cygwin1.dll snapshot.

2018-06-25 Thread Takashi Yano
Hi Thomas, On Sun, 24 Jun 2018 18:34:06 +0200 Thomas Wolff wrote: > I would have chosen other markers than 0/1 for the two cases (maybe > "firstlast" for the new one), and not put it in the middle, but you > fixed it anyway; except for the Private Use ranges E000..F8FF, > F..D, 10..

Re: mt LTO 6 Unknown type of tape device AND online status not correct

2018-06-25 Thread Corinna Vinschen
On Jun 22 14:33, Timo Maier wrote: > Hello, > > the following is done with: mt V2.5.2, Corinna Vinschen, Aug 26 2013 > > I have a Quantum LTO 6 Tape Drive (QUANTUM_ULTRIUM-HH6) which works in > general with the latest cygwin64. I can use mt to rewind or eject and tar can > write and read the ta

Re: Date field of ls -l command is garbled in latest cygwin1.dll snapshot.

2018-06-25 Thread Corinna Vinschen
On Jun 24 18:34, Thomas Wolff wrote: > Am 24.06.2018 um 00:32 schrieb Thomas Wolff: > > Am 23.06.2018 um 20:46 schrieb Brian Inglis: > > > On 2018-06-22 17:06, Takashi Yano wrote: > > > > On Sat, 23 Jun 2018 05:39:27 +0900 > > > > Takashi Yano wrote: > > > > > I looked into this problem, and found