[ANNOUNCEMENT] Updated: openjpeg-1.5.1-3

The following packages have been updated for the Cygwin distribution: *** openjpeg-1.5.1-3 *** libopenjpeg1-1.5.1-3 *** libopenjpeg-devel-1.5.1-3 The OpenJPEG library is an open-source JPEG 2000 codec written in C language. This release adds Fedora's patches for CVE-2013-1447, CVE-2013-6052,

[ANNOUNCEMENT] Updated: libyaml-0.1.4-2

The following packages have been updated for the Cygwin distribution: *** libyaml0_2-0.1.4-1 *** libyaml-devel-0.1.4-1 LibYAML is a YAML 1.1 parser and emitter library written in C. This release includes Fedora's patchset for CVE-2013-6393. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INF

[ANNOUNCEMENT] Updated: lighttpd-1.4.34-1

The following package has been updated in the Cygwin distribution: *** lighttpd-1.4.34-1 lighttpd is a web server designed and optimized for high performance environments, with a small memory footprint, effective management of the cpu-load, and advanced feature set. This is an update to the

Re: Scrollback buffer broken with snapshot

On 31/01/2014 03:57, Steven Penny wrote: On Thu, Jan 30, 2014 at 8:44 PM, Steven Penny wrote However using this snapshot http://cygwin.com/snapshots/x86_64/cygwin1-20140128.dll.xz it now only clears the screen More info cygwin1-20140128.dll.xz BAD cygwin1-20140124.dll.xz BAD

Re: Scrollback buffer broken with snapshot

On Thu, Jan 30, 2014 at 8:44 PM, Steven Penny wrote > However using this snapshot > http://cygwin.com/snapshots/x86_64/cygwin1-20140128.dll.xz > > it now only clears the screen More info cygwin1-20140128.dll.xz BAD cygwin1-20140124.dll.xz BAD cygwin1-20140118.dll.xz BAD cygwin1

Scrollback buffer broken with snapshot

Normally if you run this command printf '\ec' it will clear the screen and scrollback buffer http://stackoverflow.com/a/5367075 However using this snapshot http://cygwin.com/snapshots/x86_64/cygwin1-20140128.dll.xz it now only clears the screen -- Problem reports: http://cygwin.com/p

Re: ssh fails to start on Windows XP

On 1/30/2014 7:19 PM, Greg Couch wrote: So recompiling opensll and openssh didn't fix the problem, but switching to a cygwin1.dll snapshot that I downloaded debugging an earlier problem from Nov 29, 2013 did fix the problem. The 1.7.26-1 version of cygwin package available via the current se

Re: ssh fails to start on Windows XP

So recompiling opensll and openssh didn't fix the problem, but switching to a cygwin1.dll snapshot that I downloaded debugging an earlier problem from Nov 29, 2013 did fix the problem. "cygcheck -s -v -r" for the working cygwin1.dll gives: 3043k 2013/11/29 C:\cygwin\bin\cygwin1.dll - os=4.0

Re: ssh fails to start on Windows XP

On 1/29/2014 5:02 PM, Greg Couch wrote: FYI, I just upgraded cygwin on my Windows XP system from 1.7.18 to 1.7.27 and ssh no longer works. Runing under gdb gives: $ gdb /bin/ssh.exe (gdb) run gdb: unknown target exception 0xc139 at 0x7c9673be During startup program exite

ssh fails to start on Windows XP

FYI, I just upgraded cygwin on my Windows XP system from 1.7.18 to 1.7.27 and ssh no longer works. Runing under gdb gives: $ gdb /bin/ssh.exe (gdb) run gdb: unknown target exception 0xc139 at 0x7c9673be During startup program exited with code 0xc139. Installing openssh-de

Re: Problem running git submodule init: "error while loading shared libraries: ?"

On Thu, Jan 30, 2014 at 08:49:58PM +0100, Marco Atzeri wrote: > > >On 30/01/2014 19:51, jones.noamle wrote: >> Fixed by installing gettext. >> >> Why doesn't it print out the name of the missing library? > >MS bug Not really. There just is no way that I'm aware of to get the name of a shared libr

Re: second call to mmap() results in error

On 1/30/2014 2:46 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: OP privately wrote: The problem is also fixed by correct type-casting in the calls to mmap() ... mmap1 = mmap(NULL, (size_t) 524304, PROT_WRITE | PROT_READ, MAP_SHARED, shm_fd1, 0); The address returned from the call to mmap

Re: Problem running git submodule init: "error while loading shared libraries: ?"

On 30/01/2014 19:51, jones.noamle wrote: Fixed by installing gettext. Why doesn't it print out the name of the missing library? MS bug -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html

RE: second call to mmap() results in error

> So if the question is why do you need to include ftruncate() in the code, > take a look here: No, that was not the question. W/o ftruncate(), _referencing_ the memory becomes a problem (and the original code did not do that, but simply mmap'ed two files). > > Adding the fixes the problem in a

Re: second call to mmap() results in error

On 1/30/2014 2:04 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Forget mmap(). Why? The response was: Adding the fixes the problem in all its iterations -- the original mmap() test works (without the call to ftruncate()), as well as the second one. Note *the original*.

RE: second call to mmap() results in error

> Forget mmap(). Why? The response was: > Adding the fixes the problem in all its iterations -- the original > mmap() > test works (without the call to ftruncate()), as well as the second one. Note *the original*. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://c

Re: second call to mmap() results in error

On 1/30/2014 1:52 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Try adding -Wall to your compile line. I did. There was no warning (and it should not have because #include is there). Why ? It's not needed to compile and run the original code. Forget mmap(). That's not the issue here.

RE: dircolors generates output with '\r\n' ?

> Then one possibility is that you redirected it to a file that is mounted on > a file system that isn't binary. There it was, indeed. Thanks. And sorry about my brain-f@rt. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ:

RE: second call to mmap() results in error

> Try adding -Wall to your compile line. I did. There was no warning (and it should not have because #include is there). Why ? It's not needed to compile and run the original code. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: Problem running git submodule init: "error while loading shared libraries: ?"

Fixed by installing gettext. Why doesn't it print out the name of the missing library? On 1/29/2014 8:24 PM, Kal Sze wrote: On 30 January 2014 05:46, Marco Atzeri wrote: On 29/01/2014 22:35, jones.noamle wrote: Intro: If you don't know/have time to solve it, I'd still appreciate a few point

Re: second call to mmap() results in error

On 1/30/2014 1:44 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: #if*n*def __INSIDE_CYGWIN__ Alright, I can't read, sorry. Still, I can't figure out why adding has fixed the initial program made it run successfully (as the OP reported). Try adding -Wall to your compile line. -- Larry ___

RE: second call to mmap() results in error

> #if*n*def __INSIDE_CYGWIN__ Alright, I can't read, sorry. Still, I can't figure out why adding has fixed the initial program made it run successfully (as the OP reported). Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: second call to mmap() results in error

On Thu, Jan 30, 2014 at 06:36:34PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >> Maybe you missed Corinna's reply? >> >> > >No, I did not. She was going after ftruncate() there. > >Yet, the problem seems to be in cygwin's , which does t

Re: dircolors generates output with '\r\n' ?

On 1/30/2014 1:30 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: I did not edit anything, I just ran "dircolors", and it's output contains "\r\n"s. Then one possibility is that you redirected it to a file that is mounted on a file system that isn't binary. -- Larry _

RE: second call to mmap() results in error

> Maybe you missed Corinna's reply? > > No, I did not. She was going after ftruncate() there. Yet, the problem seems to be in cygwin's , which does this: #ifndef __INSIDE_CYGWIN__ extern void *mmap (void *__addr, size_t __len, int __prot, int

RE: dircolors generates output with '\r\n' ?

> If you edit the file with a native Windows editor, it will typically > introduce the Windows-style EOL characters. I did not edit anything, I just ran "dircolors", and it's output contains "\r\n"s. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.h

Re: second call to mmap() results in error

On 1/30/2014 12:24 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Adding the fixes the problem in all its iterations I must be missing a point here, so what was the problem with the original test program (which BTW worked fine on my CYGWIN installation). Seems like was not needed there? An

Re: dircolors generates output with '\r\n' ?

On 1/30/2014 12:04 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Hi, I was trying to use the dircolor command on CYGWIN, and it did not work because the two lines, which this command produces are separated by CRLF (which when sourced by bash are not understood, bash seems to expect single LFs)

RE: second call to mmap() results in error

> Adding the fixes the problem in all its iterations I must be missing a point here, so what was the problem with the original test program (which BTW worked fine on my CYGWIN installation). Seems like was not needed there? And how adding just (w/o adding ftruncate(), IIUC) has made it work?

dircolors generates output with '\r\n' ?

Hi, I was trying to use the dircolor command on CYGWIN, and it did not work because the two lines, which this command produces are separated by CRLF (which when sourced by bash are not understood, bash seems to expect single LFs): LS_OPTIONS='...';\r\n export LS_OPTIONS\r\n Why there are Windows

Re: second call to mmap() results in error

On Jan 30 08:19, Steven Bardwell wrote: > > On Jan 30 07:25, Steven Bardwell wrote: > > > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > > > > > >On Jan 29 09:00, Steven Bardwell wrote: > > > > > >>My application needs several areas of shared memory, and I am > > getting > > > > an > > > > > >>

Re: 64-bit bash/readline: vi-mode "dd" command fails

On Fri, Jan 24, 2014 at 11:12:32AM -0600, Jason Bucata wrote: > I'm having the same trouble under 64-bit bash/readline as this thread from > October: > http://cygwin.com/ml/cygwin/2013-10/msg00165.html > > Briefly, under vi mode ("set -o vi") the "dd" command doesn't delete the > entire line

RE: second call to mmap() results in error

> On Jan 30 07:25, Steven Bardwell wrote: > > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > > > > >On Jan 29 09:00, Steven Bardwell wrote: > > > > >>My application needs several areas of shared memory, and I am > getting > > > an > > > > >>error ("No such device") on the second call to mmap().

[ANNOUNCEMENT] Updated: OpenSSH-6.5p1-1

I've just updated the Cygwin version of OpenSSH to 6.5p1-1. Here's the official release message: = Changes since OpenSSH 6.4 = This is a feature-focused release. New features: * ssh(1), sshd(8): Ad

Re: second call to mmap() results in error

On Jan 30 07:25, Steven Bardwell wrote: > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > > > >On Jan 29 09:00, Steven Bardwell wrote: > > > >>My application needs several areas of shared memory, and I am getting > > an > > > >>error ("No such device") on the second call to mmap(). The first cal

RE: second call to mmap() results in error

> > On 29/01/2014 19:12, Corinna Vinschen wrote: > > >On Jan 29 09:00, Steven Bardwell wrote: > > >>My application needs several areas of shared memory, and I am getting > an > > >>error ("No such device") on the second call to mmap(). The first call > works > > >>fine. > > Sorry guys, but it stil

Re: second call to mmap() results in error

On Jan 29 20:33, Marco Atzeri wrote: > > > On 29/01/2014 19:12, Corinna Vinschen wrote: > >On Jan 29 09:00, Steven Bardwell wrote: > >>My application needs several areas of shared memory, and I am getting an > >>error ("No such device") on the second call to mmap(). The first call works > >>fine.