Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On Feb 7 16:12, Denis Excoffier wrote: > On Tue, Feb 07, 2012 at 03:25:20PM +0100, Corinna Vinschen wrote: > >> On Feb 7 15:09, Denis Excoffier wrote: > >> > On Sun, Feb 05, 2012 at 05:29:27PM +0100, Corinna Vinschen wrote: > >> So, here are two questions: > >> > >> - Since you *knew* that the process.h header had moved for a month > >> (after all, it is "as for every snapshot"), why didn't you say a single > >> word that this may result in a problem with building gcc? > I didn't know because /usr/include/process.h was still there. Only a > "tar tvf" told me this today. Perhaps we should do: > > rm `tar tf ` # you got the idea > before > tar xf # here also > > at any cygwin package switch? Or at least compare the respective > results of "tar tf". What do you think? > >> > >> - Why is that such a big problem? Changing process.h to cygwin/process.h > >> should work, right? > Oh yes, sure. When you have the necessary pieces it's rather easy. > For the record, also perl-5.14.2 seems broken. I moved the file back to /usr/include for the next release, which will probably not be too far in the future... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On Tue, Feb 07, 2012 at 03:25:20PM +0100, Corinna Vinschen wrote: >> On Feb 7 15:09, Denis Excoffier wrote: >> > On Sun, Feb 05, 2012 at 05:29:27PM +0100, Corinna Vinschen wrote: >> So, here are two questions: >> >> - Since you *knew* that the process.h header had moved for a month >> (after all, it is "as for every snapshot"), why didn't you say a single >> word that this may result in a problem with building gcc? I didn't know because /usr/include/process.h was still there. Only a "tar tvf" told me this today. Perhaps we should do: rm `tar tf ` # you got the idea before tar xf # here also at any cygwin package switch? Or at least compare the respective results of "tar tf". What do you think? >> >> - Why is that such a big problem? Changing process.h to cygwin/process.h >> should work, right? Oh yes, sure. When you have the necessary pieces it's rather easy. For the record, also perl-5.14.2 seems broken. Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
Hi Denis, On Tue, Feb 7, 2012 at 3:10 PM, Denis Excoffier wrote: > On Sun, Feb 05, 2012 at 05:29:27PM +0100, Corinna Vinschen wrote: >>> >>> I just released 1.7.10-1. > Fine. > After all these snapshots, i've still 1.7.9-1 officially installed. > > So setup.exe uninstalls 1.7.9-1, therefore removes /usr/include/process.h > And setup.exe then installs 1.7.10-1, therefore installs > /usr/include/cygwin/process.h (as for every snapshot). > > Now, compilation of GCC 4.7.0 (snapshot here also) is broken due to > absence of /usr/include/process.h. Your system changed. Did you try re-running configure? Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On Feb 7 15:09, Denis Excoffier wrote: > On Sun, Feb 05, 2012 at 05:29:27PM +0100, Corinna Vinschen wrote: > >> > >> I just released 1.7.10-1. > Fine. > After all these snapshots, i've still 1.7.9-1 officially installed. > > So setup.exe uninstalls 1.7.9-1, therefore removes /usr/include/process.h > And setup.exe then installs 1.7.10-1, therefore installs > /usr/include/cygwin/process.h (as for every snapshot). > > Now, compilation of GCC 4.7.0 (snapshot here also) is broken due to > absence of /usr/include/process.h. > > It's a pity that the Cygwin snapshot "system", while being fairly able > to test installation of new Cygwin releases, cannot test at the same > time the disinstallation of the associated previous releases. Huh? The move of process.h from /usr/include to /usr/include/cygwin was a deliberate move. The header only declares the Cygwin-specific spawn familiy of functions. So, here are two questions: - Since you *knew* that the process.h header had moved for a month (after all, it is "as for every snapshot"), why didn't you say a single word that this may result in a problem with building gcc? - Why is that such a big problem? Changing process.h to cygwin/process.h should work, right? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On Sun, Feb 05, 2012 at 05:29:27PM +0100, Corinna Vinschen wrote: >> >> I just released 1.7.10-1. Fine. After all these snapshots, i've still 1.7.9-1 officially installed. So setup.exe uninstalls 1.7.9-1, therefore removes /usr/include/process.h And setup.exe then installs 1.7.10-1, therefore installs /usr/include/cygwin/process.h (as for every snapshot). Now, compilation of GCC 4.7.0 (snapshot here also) is broken due to absence of /usr/include/process.h. It's a pity that the Cygwin snapshot "system", while being fairly able to test installation of new Cygwin releases, cannot test at the same time the disinstallation of the associated previous releases. Regards, Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On Feb 6 21:39, Magnus Holmgren wrote: > Corinna Vinschen cygwin.com> writes: > > > - Improve fork/exec performance on 64 bit systems. > > If fork/exec became faster, something else has slowed down noticeably on my > 64-bit Vista system. Using a fairly fork-heavy build script as the benchmark > (and running it when nothing needs to be re-built), 1.7.10 is about 25% > slower. > Switching to cygwin1.dll 1.7.9 speeds things up again (and I only changed the > DLL; it seemed to work fine for this test at least). > > The "while [ 1 ]; do date; done | uniq -c" loop is about 15% faster with > 1.7.10 > though. I can't reproduce this. I tested with `make clean; make' in a tcsh build tree, and the 1.7.9 build is always slower, about 20%. > Lines like these stand out in a quick look in the strace log (about 75 MB): > > 1172898 1173730 [main] sh 1484 child_copy: dll bss - hp 0xEC low 0x611FC000, > high 0x61230770, res 1 > > Every 4-5 print of "child_copy: dll bss" starts with a big number like that > (values in the 5-10 range are more common). Don't know if this is > relevant... That hasn't changed between 1.7.9 and 1.7.0. We always have to copy parent data to the child in fork. Sigh. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On Feb 7 19:01, jojelino wrote: > 2012-02-07 PM 3:49, Daniel Colascione 쓴 글: > >On 2/6/12 8:35 PM, jojelino wrote: > >>2012-02-06 AM 1:29, Corinna Vinschen 쓴 글: > >>>Hi Cygwin friends and users, > >>> > >> > >>C:\Documents and Settings\Administrator>base64 oso|base64 -d - > >>base64: write error: Bad file descriptor > >>base64: write error > >> > >>C:\Documents and Settings\Administrator>uname -a > >>CYGWIN_NT-5.2 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin > >> > >>please check this problem. > > > >Worksforme after creating a file called "oso". > > (And if I don't have > >such a file, the command fails in the expected way.) > > > sorry for confusion > > rem make empty file > C:\>touch boa > > C:\>base64 boa|base64 -d - > rem make non empty file > C:\>echo blahblah >oso > > C:\>base64 boa|base64 -d - > > C:\>base64 boa|base64 -d - > > C:\>base64 oso|base64 -d - > blahblah > > C:\>base64 oso|base64 -d - > base64: write error: Bad file descriptor > base64: write error Looks like this happens if the pipe has not been created by a Cygwin process (cmd.exe in this case). For the time being, start that from a real shell, like bash or tcsh. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
2012-02-07 PM 3:49, Daniel Colascione 쓴 글: On 2/6/12 8:35 PM, jojelino wrote: 2012-02-06 AM 1:29, Corinna Vinschen 쓴 글: Hi Cygwin friends and users, C:\Documents and Settings\Administrator>base64 oso|base64 -d - base64: write error: Bad file descriptor base64: write error C:\Documents and Settings\Administrator>uname -a CYGWIN_NT-5.2 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin please check this problem. Worksforme after creating a file called "oso". (And if I don't have such a file, the command fails in the expected way.) sorry for confusion rem make empty file C:\>touch boa C:\>base64 boa|base64 -d - rem make non empty file C:\>echo blahblah >oso C:\>base64 boa|base64 -d - C:\>base64 boa|base64 -d - C:\>base64 oso|base64 -d - blahblah C:\>base64 oso|base64 -d - base64: write error: Bad file descriptor base64: write error C:\>base64 oso|base64 -d - base64: write error: Bad file descriptor base64: write error C:\>base64 oso|base64 -d - base64: write error: Bad file descriptor base64: write error C:\>base64 oso|base64 -d - base64: write error: Bad file descriptor base64: write error empty file always worked. for non-empty file it does worked or not. strace for base64 -d solved the write error. so i couldn't figure it out quite well. -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On 2/6/12 8:35 PM, jojelino wrote: > 2012-02-06 AM 1:29, Corinna Vinschen 쓴 글: >> Hi Cygwin friends and users, >> > > C:\Documents and Settings\Administrator>base64 oso|base64 -d - > base64: write error: Bad file descriptor > base64: write error > > C:\Documents and Settings\Administrator>uname -a > CYGWIN_NT-5.2 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin > > please check this problem. Worksforme after creating a file called "oso". (And if I don't have such a file, the command fails in the expected way.) signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
2012-02-06 AM 1:29, Corinna Vinschen 쓴 글: Hi Cygwin friends and users, C:\Documents and Settings\Administrator>base64 oso|base64 -d - base64: write error: Bad file descriptor base64: write error C:\Documents and Settings\Administrator>uname -a CYGWIN_NT-5.2 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin please check this problem. -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
Corinna Vinschen cygwin.com> writes: > - Improve fork/exec performance on 64 bit systems. If fork/exec became faster, something else has slowed down noticeably on my 64-bit Vista system. Using a fairly fork-heavy build script as the benchmark (and running it when nothing needs to be re-built), 1.7.10 is about 25% slower. Switching to cygwin1.dll 1.7.9 speeds things up again (and I only changed the DLL; it seemed to work fine for this test at least). The "while [ 1 ]; do date; done | uniq -c" loop is about 15% faster with 1.7.10 though. Lines like these stand out in a quick look in the strace log (about 75 MB): 1172898 1173730 [main] sh 1484 child_copy: dll bss - hp 0xEC low 0x611FC000, high 0x61230770, res 1 Every 4-5 print of "child_copy: dll bss" starts with a big number like that (values in the 5-10 range are more common). Don't know if this is relevant... Magnus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On 2/6/2012 4:34 AM, Corinna Vinschen wrote: Help? Is anybody else seeing this behavior? I just tried to start the sshd and cygserver services and it worked without problems. So it's not exactly a generic problem. Do you have more information in /var/log/sshd.log or /var/log/cygserver.log? Neither sshd.log nor cygserver.log has anything informative (timestamp on cygserver.log is last October...) I'm running something I can't interrupt at the moment, but I'll try rebooting soon. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1
On Feb 5 16:18, Charles Wilson wrote: > As per my usual procedure, I halted the three cygwin services: > > cygserver > syslogd > sshd > > ...installed the new version of cygwin (and cygserver.exe), and then > attempted to restart: > > Administrator@my_pc[1.7] ~ > $ cygrunsrv -S cygserver > cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: > The service has not been started. > [...] > cygserver: PID 7696: starting service `cygserver' failed: fork: 11, > Resource temporarily unavailable > [...] > FWIW, I get similar event log messages and failures with the syslogd > and sshd services -- which leads me to think the problem is with > (the spawned) cygrunsrv.exe process. > > Help? Is anybody else seeing this behavior? I just tried to start the sshd and cygserver services and it worked without problems. So it's not exactly a generic problem. Do you have more information in /var/log/sshd.log or /var/log/cygserver.log? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: cygwin-1.7.10-1
Hi Cygwin friends and users, I just released 1.7.10-1. It introduces a couple of new APIs and some changes which are supposed to reduce fork problems. And lots of other stuff. Just read on. for a start, here are the most distinct changes from old behaviour: - 1.7.10 drops support for Windows NT4 to reduce the amount of legacy code. - The CYGWIN=tty mode has been removed. Either just use the normal Windows console as is, or use a terminal application like mintty. - New heap management. Drop registry setting "heap_chunk_in_mb" entirely in favor of a new per-executable setting in the executable file header which can be set using the peflags tool (see `peflags --cygwin-heap'). As always, please have another look into the documentation at http://cygwin.com/docs.html. It contains a few improvements and the description for new features and changes from old behaviour. What's new: --- - New getconf tool for querying confstr(3), pathconf(3), sysconf(3), and limits.h configuration. - New tzset utility to generate a POSIX-compatible TZ environment variable from the Windows timezone settings. - The passwd tool now allows an administrator to use the -R command for other user accounts: passwd -R username. - Experimental: Change the way sockets are created so that Cygwin always circumvents so-called "layered service providers" (LSPs) starting with Windows Vista. - signal handler functions are now dispatched in threads other than the main thread. - Support NcFsd filesystem. - clock_gettime(3) and clock_getres(3) accept per-process and per-thread CPU-time clocks, including CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID. - New pthread functions: - Spin Locks: pthread_spin_destroy, pthread_spin_init, pthread_spin_lock, pthread_spin_trylock, pthread_spin_unlock. - Stack management: pthread_attr_getstack, pthread_attr_getstackaddr, pthread_attr_getguardsize, pthread_attr_setstack, pthread_attr_setstackaddr, pthread_attr_setguardsize, pthread_getattr_np. - Clock Selection: pthread_getcpuclockid, pthread_condattr_getclock, pthread_condattr_setclock. - Scheduling: pthread_setschedprio. - Signalling: pthread_sigqueue. - Add /proc/devices, /proc/misc, /proc/sysvipc, /proc/swaps. - Make various system functions thread cancelation points per POSIX. - Add ioctl FIONREAD handling for non-sockets. - dlopen now supports the Glibc-specific RTLD_NODELETE and RTLD_NOOPEN flags. - The printf and wprintf families of functions now support the %m conversion flag. - Execed processes now inherit the children of their predecessor. - Fifos have been rewritten and should now be more reliable. - GNU/glibc error.h error reporting functions: error, error_at_line, error_message_count, error_one_per_line, error_print_progname. - C99 type-generic macros. - Other new API: clock_getcpuclockid, clock_nanosleep, clock_settime, __fpurge, get_current_dir_name, getgrouplist, getpt, ppoll, psiginfo, psignal, ptsname_r, sys_siglist, sysinfo. - cygwin_conv_path_list finally supports CCP_WIN_W_TO_POSIX and CCP_POSIX_TO_WIN_W conversions. What changed: - - Drop support for Windows NT4. - The CYGWIN=tty mode using pipes to communicate with the console in a pseudo tty-like mode has been removed. Either just use the normal Windows console as is, or use a terminal application like mintty. - The CYGWIN environment variable options "envcache", "strip_title", "title", "tty", and "upcaseenv" have been removed. - New heap management. Drop registry setting "heap_chunk_in_mb" in favor of a new per-executable setting in the executable file header which can be set using the peflags tool. Drop registry setting "heap_slop_in_mb" entirely. - Revamp console and pseudo tty handling. Rename /dev/ttyX to /dev/consX, /dev/ttyX to /dev/ptyX. - Improve fork/exec performance on 64 bit systems. - Improve Ctrl-C handling in console. - Try harder to let fork not fail if DLLs are moved in memory which should, in some cases, minimize the need for rebaseall. - Try harder to send SIGHUP to children when process group leader fails. - Deal with Windows problem where non-blocking pipe I/O was not flushed properly on close. - Attempt to regularize most syscall-related strace output. - Improve behavior of Cygwin when started from a 64-bit process, especially under Windows 2003. - Improve multi-thread/reentrancy safety with syscalls that deal with fds. - dlopen can now find "cygFOO.dll", even if the caller specified "libFOO.so". This is supposed to support applications which are no aware of Windows DLLs. - Make accept(2), poll(2) and shutdown(2) behave more like on Linux. - Raise max number of mount points from 30 to 64. - Output of /proc/maps is closer to what Linux prints and much more useful to examine process VM layout. - /proc/loadavg now shows the number of currently running processes and the total number of processes. - /pro
