Re: xorg-server-1.9.2-1 Fullscreen Issue
On Mon, Jan 24, 2011 at 05:48:44PM +, Jon TURNEY wrote: On 21/01/2011 04:38, Frederick D. Hansen wrote: On Fri, 2010-11-19 at 13:37 +, Jon TURNEY wrote: On 18/11/2010 12:33, Frederick Hansen wrote: Just FYI, after upgrading to xorg-server 1.9.2, any attempt to run in fullscreen results in an error. Downgrading to version 1.8.2 seems to correct the issue. Running either version in multiwindow also works. The contents of Xwin.log are shown below: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.9.2.0 (10902000) Build Date: 2010-11-03 XWin was started with the following command line: /usr/bin/XWin -fullscreen -depth 8 -clipboard -silent-dup-error By the way, on my machine, this is just: X :0 -multiwindow [snip] [ 30091.406] (EE) XKB: Could not invoke xkbcomp [ 30091.406] (EE) XKB: Couldn't compile keymap [ 30091.406] XKB: Failed to compile keymap [ 30091.406] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [ 30091.406] Fatal server error: [ 30091.406] Failed to activate core devices. This was the same for me. Are you sure that removing -fullscreen allows the X server to start properly? I didn't have it in the first place. I use XP SP3. I can't reproduce this problem. The problem going away when you remove (and hence prevent from loading) the dynamically loaded swrast_dri.so *really* makes this look like a remap problem. I'm on Windows 7. Renaming /usr/lib/dri/swrast_dri.so fixed the problem for me. I then renamed it back and ran rebase on it with the defaults used in rebaseall. X is still starting up. I then created rebase.lst using the commands used in rebaseall. /usr/lib/dri/swrast_dri.so is in there. But I have run rebaseall immediately prior to starting X and it was still failing to start. So it does appear to be a rebase problem, and I have no clue why rebaseall couldn't fix it. (It was completing successfully.) There is some work upstream to remove this rather pointless fork/exec of xkbcomp and replace it with libxkbcommon, but that now seems unlikely to appear in X server 1.10. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Reinier Post -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-01-26 10:55:13 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (fhandler_base::fstat_by_nfs_ea): Fix computation of st_blocks. (fhandler_base::fstat_helper): Fix formatting. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5132r2=1.5133 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.347r2=1.348
Re: 1.7.7: stdio functions block each other in a multithreaded program
On Jan 25 14:31, cornware...@lavabit.com wrote: I am trying to make a multi-threaded application, where one thread reads commands from stdin, and another thread is doing other things, such as reading files and printing messages to stdout. The problem I have is that the thread that reads files and writes to stdout locks while the other thread is reading from stdin. To demonstrate this, I created a small program that has this behavior. The C-code is present at the end of this e-mail. [...] Thanks for the testcase! First of all, I can confirm your observation and your testcase easily allows to debug what happens. What happens is that the read operation in scanf and the read operation in fgetc are blocking each other out because they access the same global lock. I could track down this behaviour to a specific change in newlib from 2009, which also explains why this still worked in 1.5 (which I tested as well). So, the next task for me is to find out why this change has been made and to talk to the contributor of the change to come to a solution which does not show this unfortunate behaviour. What you can do for the time being is to use the low-level IO functions read and write, rather than the stdio functions fgetc and putchar, since only the stdio functions are affected by this. I hope to find a solution soon and the bugfix will definitely be in 1.7.8. Again, thanks for testcase. It's highly appreciated. 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: Still on target for imminent 1.7.8 release? [was Re: Enable dfp routines in compiler support lib]
On Jan 26 03:53, Dave Korn wrote: Hey cygwin-devel, any plans for fenv.h release in 1.7.8? We already have fenv.h in CVS, so it will be in 1.7.8 automatically. That means this isn't really a -devel thing, so redirecting: Hey, main list! Are we still expecting 1.7.8 by the end of this month? Early Feb is more likely. From my POV there's just that new issue with stdio blocking each other. Chris, are you still working on something for 1.7.8? Other than that, I'd appreciate if lots of people would start testing developer snapshots. There were some changes to the path handling code which *might* break handling of unusual filesystems. I guess we should make a test announcement... 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: du weird results under samba share
On Jan 26 01:27, Cyrille Lefevre wrote: Hi, v2$ uname -a CYGWIN_NT-5.1 PC213736 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin aka Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 samba is : Samba version 2.2.8a based HP CIFS Server A.01.10 aka samba 2.2.8a under HP-UX 11.11 (11iv1) Ouch. Wasn't that the Samba version Fred Flintstone used at work? in some words : there is a factor 8 between the reality and du ! v2$ du --version du (GNU coreutils) 7.0 same results w/ : v2$ /tmp/du --version du (GNU coreutils) 8.8 v2$ ll total 3556352 -rwxr--r-- 1 expl786432 2011-01-25 20:24 archive.pst -rwxr--r-- 1 expl 109216768 2011-01-25 20:23 ratp 2006-2007.pst -rwxr--r-- 1 expl 115834880 2011-01-25 20:23 ratp 2008.pst -rwxr--r-- 1 expl 90718208 2011-01-25 20:23 ratp 2009.pst -rwxr--r-- 1 expl 138297344 2011-01-25 20:23 ratp 2010.pst What does `ls -s' return? The return value in st_blocks is always a multiple of 1K(*), which in turn is computed from the AllocationSize value returned by the NtQueryInformationFile function. Compare that with `ls -s' on the HP machine. I wouldn't be surprised if that's a bug in that Samba version. Corinna (*) Well, except on NFS, which I just fixed in CVS. -- 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: Bug in libiconv?
Here's what happens on Cygwin: $ gcc -g -o ic ic.c -liconv $ ./ic iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 480 So, AFAICS, there are two problems: - Even though iconv_open has been opened explicitely with UTF-8 as input string, the conversion still depends on the current application codeset. That dsoesn't make sense. - Even though the last parameter to iconv is defined in bytes, the value of outbytesleft after the conversion is the number of remaining wchart's, not the number of remaining bytes. That's contrary to what POSIX defines, see http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html IMHO, the count is correct. On Windows/Cygwin, wchar_t is 2 bytes, on Linux, 4 bytes. So the buffer is 512 bytes. In the first 3 cases, 10 input bytes were consumed so that there remains in the buffer (512 - 20) = 492 bytes. In the last case all 16 bytes are consumed so there remains in the buffer (512 - 32) = 480 bytes. Roger -- 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: du weird results under samba share
Le 26/01/2011 12:06, Corinna Vinschen a écrit : What does `ls -s' return? The return value in st_blocks is always a multiple of 1K(*), which in turn is computed from the AllocationSize value returned by the NtQueryInformationFile function. Compare that with `ls -s' on the HP machine. I wouldn't be surprised if that's a bug in that Samba version. same result v2$ ls -ls total 3556352 6144 -rwxr--r-- 1 expl786432 2011-01-25 20:24 archive.pst 854016 -rwxr--r-- 1 expl 109216768 2011-01-25 20:33 ratp 2006-2007.pst 905216 -rwxr--r-- 1 expl 115834880 2011-01-25 20:33 ratp 2008.pst 709632 -rwxr--r-- 1 expl 90718208 2011-01-25 20:33 ratp 2009.pst 1081344 -rwxr--r-- 1 expl 138297344 2011-01-25 20:33 ratp 2010.pst Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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: Bug in libiconv?
On Jan 26 13:15, si...@sim-basis.de wrote: Here's what happens on Cygwin: $ gcc -g -o ic ic.c -liconv $ ./ic iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 480 So, AFAICS, there are two problems: - Even though iconv_open has been opened explicitely with UTF-8 as input string, the conversion still depends on the current application codeset. That dsoesn't make sense. - Even though the last parameter to iconv is defined in bytes, the value of outbytesleft after the conversion is the number of remaining wchart's, not the number of remaining bytes. That's contrary to what POSIX defines, see http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html IMHO, the count is correct. On Windows/Cygwin, wchar_t is 2 bytes, on Linux, 4 bytes. So the buffer is 512 bytes. In the first 3 cases, 10 input bytes were consumed so that there remains in the buffer (512 - 20) = 492 bytes. In the last case all 16 bytes are consumed so there remains in the buffer (512 - 32) = 480 bytes. Yes, you're right. Quite obviously I misinterpreted the results without realizing that the buffer is smaller under Cygwin. Thanks, 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: du weird results under samba share
On Jan 26 13:28, Cyrille Lefevre wrote: Le 26/01/2011 12:06, Corinna Vinschen a écrit : What does `ls -s' return? The return value in st_blocks is always a multiple of 1K(*), which in turn is computed from the AllocationSize value returned by the NtQueryInformationFile function. Compare that with `ls -s' on the HP machine. I wouldn't be surprised if that's a bug in that Samba version. same result v2$ ls -ls total 3556352 6144 -rwxr--r-- 1 expl786432 2011-01-25 20:24 archive.pst 854016 -rwxr--r-- 1 expl 109216768 2011-01-25 20:33 ratp 2006-2007.pst 905216 -rwxr--r-- 1 expl 115834880 2011-01-25 20:33 ratp 2008.pst 709632 -rwxr--r-- 1 expl 90718208 2011-01-25 20:33 ratp 2009.pst 1081344 -rwxr--r-- 1 expl 138297344 2011-01-25 20:33 ratp 2010.pst And on the HP machine? That really looks like a Samba problem. 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: Still on target for imminent 1.7.8 release? [was Re: Enable dfp routines in compiler support lib]
On 1/26/2011 5:33 AM, Corinna Vinschen wrote: On Jan 26 03:53, Dave Korn wrote: Hey, main list! Are we still expecting 1.7.8 by the end of this month? Early Feb is more likely. Dave, I'd recommend allowing that patch to gcc, which requires fenv.h, to be committed, given that the 4.6 window is closing soon... Other than that, I'd appreciate if lots of people would start testing developer snapshots. ...and it'll force the two people who might actually try to compile bleeding edge gcc 4.6 to go ahead and install -- and test -- the cygwin dev snaps. -- 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: Bug in libiconv?
On 1/26/2011 8:26 AM, Corinna Vinschen wrote: On Jan 26 13:15, si...@sim-basis.de wrote: Here's what happens on Cygwin: $ gcc -g -o ic ic.c -liconv $ ./ic iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 480 So, AFAICS, there are two problems: - Even though iconv_open has been opened explicitely with UTF-8 as input string, the conversion still depends on the current application codeset. That dsoesn't make sense. - Even though the last parameter to iconv is defined in bytes, the value of outbytesleft after the conversion is the number of remaining wchart's, not the number of remaining bytes. That's contrary to what POSIX defines, see http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html IMHO, the count is correct. On Windows/Cygwin, wchar_t is 2 bytes, on Linux, 4 bytes. So the buffer is 512 bytes. In the first 3 cases, 10 input bytes were consumed so that there remains in the buffer (512 - 20) = 492 bytes. In the last case all 16 bytes are consumed so there remains in the buffer (512 - 32) = 480 bytes. Yes, you're right. Quite obviously I misinterpreted the results without realizing that the buffer is smaller under Cygwin. Sure, but there ARE still bugs in libiconv on Cygwin -- specifically: - Even though iconv_open has been opened explicitely with UTF-8 as input string, the conversion still depends on the current application codeset. That doesn't make sense. and - 'iconv_close ((iconv_t) -1);' crashes the application with a SEGV. -- 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: run ./ChangeLog ./NEWS src/run.c src/run.h
Hi Charles, 2011/1/26 cwilson@: CVSROOT: /cvs/cygwin-apps Module name: run Changes by: cwil...@sourceware.org 2011-01-26 04:02:39 Modified files: . : ChangeLog NEWS src : run.c run.h Log message: Clean up cygwin_conv_* path handling a bit Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/run/ChangeLog.diff?cvsroot=cygwin-appsr1=1.16r2=1.17 http://sourceware.org/cgi-bin/cvsweb.cgi/run/NEWS.diff?cvsroot=cygwin-appsr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/run/src/run.c.diff?cvsroot=cygwin-appsr1=1.11r2=1.12 And what about unicode paths? (utf-8 translation) cygwin_conv_path (CCP_WIN_A_TO_POSIX ... I wrote a lame patch to support that also for perl https://github.com/rurban/perl/commit/1e8a170cc32a40589bb8ffd32b39f5ca62a08dca http://sourceware.org/cgi-bin/cvsweb.cgi/run/src/run.h.diff?cvsroot=cygwin-appsr1=1.3r2=1.4 -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: run ./ChangeLog ./NEWS src/run.c src/run.h
On 1/26/2011 8:50 AM, Reini Urban wrote: And what about unicode paths? (utf-8 translation) cygwin_conv_path (CCP_WIN_A_TO_POSIX ... I wrote a lame patch to support that also for perl https://github.com/rurban/perl/commit/1e8a170cc32a40589bb8ffd32b39f5ca62a08dca See this: http://cygwin.com/ml/cygwin/2011-01/msg00321.html Changes in 1.1.13... * For cygwin-1.7, avoid deprecated cygwin_conv_* functions. NOTE: Only the barest minimal changes were made, so (a) non-ascii characters still not supported, and (b) long pathnames are not yet supported. This will occur on the new 1.2 development stream. For run-1.2.x (cvs HEAD), PTC (esp. for long path and/or wide char support). cvs -d:pserver:anon...@cygwin.com:/cvs/cygwin-apps co run -- 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: Bug in libiconv?
On Jan 26 08:43, Charles Wilson wrote: On 1/26/2011 8:26 AM, Corinna Vinschen wrote: On Jan 26 13:15, si...@sim-basis.de wrote: Here's what happens on Cygwin: - Even though the last parameter to iconv is defined in bytes, the value of outbytesleft after the conversion is the number of remaining wchart's, not the number of remaining bytes. That's contrary to what POSIX defines, see http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html IMHO, the count is correct. On Windows/Cygwin, wchar_t is 2 bytes, on Linux, 4 bytes. So the buffer is 512 bytes. In the first 3 cases, 10 input bytes were consumed so that there remains in the buffer (512 - 20) = 492 bytes. In the last case all 16 bytes are consumed so there remains in the buffer (512 - 32) = 480 bytes. Yes, you're right. Quite obviously I misinterpreted the results without realizing that the buffer is smaller under Cygwin. Sure, but there ARE still bugs in libiconv on Cygwin -- specifically: - Even though iconv_open has been opened explicitely with UTF-8 as input string, the conversion still depends on the current application codeset. That doesn't make sense. and - 'iconv_close ((iconv_t) -1);' crashes the application with a SEGV. Indeed. But it was an important hint, nevertheless. It just didn't occur to me that the buffer size is different between Cygwin and Linux. 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
vim wraps lines
I'm using the latest cygwin, min-tty and vim But when I open vim, lines seem to wrap. Here is the image: http://i.imgur.com/oC8lo.png Is that a configuration issue? how do I fix it? Daniel -- 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: CUPS development for cygwin
On Wed, Jan 26, 2011 at 08:07:16AM +0100, Gyurmo wrote: Hello; I can see the http://cygwin-ports.git.sourceforge.net/git/gitweb-index.cgi CUPS. Hello, Questions regarding cygwinports should go to the cygwin-ports-general maillist: cygwin-ports-general AT lists DOT sourceforge DOT net Thanks. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: 1.7.7: stdio functions block each other in a multithreaded program
[...] What you can do for the time being is to use the low-level IO functions read and write, rather than the stdio functions fgetc and putchar, since only the stdio functions are affected by this. I hope to find a solution soon and the bugfix will definitely be in 1.7.8. Again, thanks for testcase. It's highly appreciated. Nice to hear you appreciate it. I can confirm that using the low-level IO function 'read' instead of the scanf function avoids the issue. For now, I will use this approach. So for me the issue is solved. Thanks, and good luck finding a solution for version 1.7.8. -- 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: du weird results under samba share
Le 26/01/2011 14:27, Corinna Vinschen a écrit : On Jan 26 13:28, Cyrille Lefevre wrote: Le 26/01/2011 12:06, Corinna Vinschen a écrit : What does `ls -s' return? The return value in st_blocks is always a multiple of 1K(*), which in turn is computed from the AllocationSize value returned by the NtQueryInformationFile function. Compare that with `ls -s' on the HP machine. I wouldn't be surprised if that's a bug in that Samba version. same result v2$ ls -ls total 3556352 6144 -rwxr--r-- 1 expl786432 2011-01-25 20:24 archive.pst 854016 -rwxr--r-- 1 expl 109216768 2011-01-25 20:33 ratp 2006-2007.pst 905216 -rwxr--r-- 1 expl 115834880 2011-01-25 20:33 ratp 2008.pst 709632 -rwxr--r-- 1 expl 90718208 2011-01-25 20:33 ratp 2009.pst 1081344 -rwxr--r-- 1 expl 138297344 2011-01-25 20:33 ratp 2010.pst And on the HP machine? That really looks like a Samba problem. looks good (in 512c blocks) : bl03tea4:/divers/archive/perso/x2000818/outlook # ls -ls total 888592 1536 -rwxr--r-- 1 x2000818 expl786432 Jan 25 20:24 archive.pst 213344 -rwxr--r-- 1 x2000818 users 109216768 Jan 26 14:31 ratp 2006-2007.pst 226256 -rwxr--r-- 1 x2000818 users 115834880 Jan 26 14:31 ratp 2008.pst 177264 -rwxr--r-- 1 x2000818 expl 90718208 Jan 26 14:31 ratp 2009.pst 270192 -rwxr--r-- 1 x2000818 expl 138297344 Jan 26 14:31 ratp 2010.pst Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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: Still on target for imminent 1.7.8 release? [was Re: Enable dfp routines in compiler support lib]
On Wed, 2011-01-26 at 08:39 -0500, Charles Wilson wrote: Dave, I'd recommend allowing that patch to gcc, which requires fenv.h, to be committed, given that the 4.6 window is closing soon... ...and it'll force the two people who might actually try to compile bleeding edge gcc 4.6 to go ahead and install -- and test -- the cygwin dev snaps. +1 I see no reason why cutting edge GCC can't require a cutting edge Cygwin. Yaakov -- 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: Still on target for imminent 1.7.8 release? [was Re: Enable dfp routines in compiler support lib]
On Wed, 2011-01-26 at 11:33 +0100, Corinna Vinschen wrote: On Jan 26 03:53, Dave Korn wrote: Hey, main list! Are we still expecting 1.7.8 by the end of this month? Early Feb is more likely. From my POV there's just that new issue with stdio blocking each other. Chris, are you still working on something for 1.7.8? How about this issue since 1.7.7: http://cygwin.com/ml/cygwin/2010-12/msg00450.html Yaakov -- 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: cygport-0.10.3
I have updated the cygport to version 0.10.3 with the following changes: * Scripts with erroneous .exe extension are automatically renamed. * Fixed default excludes where libtool is used without automake. * apache2.cygclass: fixes for module name detection * autotools.cygclass: handle configure.ac with subdir configure.in; make sure ACLOCAL_AMFLAGS directories exist * berkdb.cygclass: support BDB 5.x * nant.cygclass: NEW cygclass for NAnt-based builds * php.cygclass: update for PHP 5.3; canonicalize all known PHP_CHANNELs * waf.cygclass: fix libexecdir, sysconfdir, and localstatedir * xfce4.cygclass: update for Xfce 4.8 Yaakov -- CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Bug in libiconv?
On 1/24/2011 10:09 PM, Charles Wilson wrote: Now, since there has not yet been an updated upstream release of libiconv, my first step would be to simply rebuild our existing libiconv-1.13.1 on a platform with current cygwin (1.7.7-1), and try the test case again. Rebuilt libiconv against 20110117 snapshot. Built test case. Still see erroneous behavior: iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 iconv: 138 Invalid or incomplete multibyte or wide character in = Liian pitkä sana, inbuf = ä sana, inbytesleft = 7, outbytesleft = 492 in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 480 If that doesn't correct the issue...then I'd try to run your test case on linux, but *explicitly* using libiconv on that system, rather than (as is typically the case on linux) relying on the underlying glibc implementation of iconv functionality. Did this. Here are the characteristics of the test case object and executable: $ ldd ./foo linux-vdso.so.1 = (0x7fff51928000) libiconv.so.2 = /home/me/libiconv/_inst/lib/libiconv.so.2 (0x7f0b7d7dd000) libc.so.6 = /lib64/libc.so.6 (0x003d5b40) /lib64/ld-linux-x86-64.so.2 (0x003d5b00) $ nm foo.o | grep ' U ' U __errno_location U exit U fprintf U iconv U iconv_close U iconv_open U printf U setlocale U stderr U strerror U strlen It works fine: in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 960 in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 960 in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 960 in = Liian pitkä sana, inbuf = , inbytesleft = 0, outbytesleft = 960 If the test case fails there, then we've got a presumption that the problem is in the (generic, cross-platform bits of) libiconv library itself. Well, apparently the problem is not the generic, cross-platform bits of libiconv. It's in the cygwin-specific bits, and/or how it interfaces with cygwin's underlying charset manips. So... Then, it's debugging time... :-( ...it's still debugging time. Sigh. -- 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: vim wraps lines
On 1/26/2011 12:00 PM, Daniel Ajoy wrote: I'm using the latest cygwin, min-tty and vim But when I open vim, lines seem to wrap. Here is the image: http://i.imgur.com/oC8lo.png Is that a configuration issue? how do I fix it? I can't reproduce that behavior. What's your TERM environment variable set to? In case you missed it, below is the link to the problem reporting guidelines. Problem reports: http://cygwin.com/problems.html -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Bug in libiconv?
On 1/25/2011 6:15 AM, Corinna Vinschen wrote: - lib/iconv_open1.h and lib/iconv.c exclude Cygwin from the usage of the ei_ucs2internal encoding table. I'm not sure if that's right or wrong, but it looks worrying. Please note that I defined __STDC_ISO_10646__ for Cygwin 1.7.8 yesterday. This define is missing since 1.7.2. Can we get a newer snapshot that the current 20110117? -- 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: vim wraps lines
On Wed, Jan 26, 2011 at 10:12:01PM -0500, Larry Hall (Cygwin) wrote: On 1/26/2011 12:00 PM, Daniel Ajoy wrote: I'm using the latest cygwin, min-tty and vim But when I open vim, lines seem to wrap. Here is the image: http://i.imgur.com/oC8lo.png Is that a configuration issue? how do I fix it? IMHO it isn't broken. That is the expected behavior. That is how I use it and I want to see all of the line, even if it wraps. Why don't you want to see all of the line? MB -- e-mail: vid...@vidiot.com/~\ The ASCII [I've been to Earth. I know where it is. ] \ / Ribbon Campaign [And I'm gonna take us there.Starbuck 3/25/07] X Against Visit - URL: http://vidiot.com/ / \ HTML Email -- 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: vim wraps lines
On 01/26/2011 09:20 PM, Mike Brown wrote: On Wed, Jan 26, 2011 at 10:12:01PM -0500, Larry Hall (Cygwin) wrote: On 1/26/2011 12:00 PM, Daniel Ajoy wrote: I'm using the latest cygwin, min-tty and vim But when I open vim, lines seem to wrap. Here is the image: http://i.imgur.com/oC8lo.png Is that a configuration issue? how do I fix it? IMHO it isn't broken. That is the expected behavior. That is how I use it and I want to see all of the line, even if it wraps. Why don't you want to see all of the line? Mike, please take another, closer look at the linked image. It's clear that what is displayed is the initial text outputted by vim when started without a file to open and that the display of this text obviously broken. While the problem could have been worded differently to avoid the confusion, the image makes the problem unambiguous. It's most likely a problem with the TERM setting in use when vim was started, as Larry asked to clarify. I think it's also possible that a non-Cygwin version of vim was actually started under a Cygwin session. Larry's suggestion to follow the problem reporting guidelines would likely clarify this point as well. BTW, if you didn't intend to comment on Larry's reply at all, you should have replied to Daniel's message instead. -Jeremy -- 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: CUPS development for cygwin
Thanks 2011/1/26 David Sastre d.sastre.med...@gmail.com On Wed, Jan 26, 2011 at 08:07:16AM +0100, Gyurmo wrote: Hello; I can see the http://cygwin-ports.git.sourceforge.net/git/gitweb-index.cgi CUPS. Hello, Questions regarding cygwinports should go to the cygwin-ports-general maillist: cygwin-ports-general AT lists DOT sourceforge DOT net Thanks. -- 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: vim wraps lines
On Wed, Jan 26, 2011 at 12:00:55PM -0500, Daniel Ajoy wrote: I'm using the latest cygwin, min-tty and vim But when I open vim, lines seem to wrap. Here is the image: http://i.imgur.com/oC8lo.png Is that a configuration issue? how do I fix it? It looks like either you're not using the Cygwin version of vim or you have your TERM environment variable set incorrectly. You haven't provided enough details to know for sure. See: http://cygwin.com/problems.html cgf -- 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: max memory
On Sun, Jan 23, 2011 at 08:11:52PM -0800, Linda Walsh wrote: Christopher Faylor wrote: Cygwin only uses as much memory as the OS gives it. It can't use a full 2048MB for the heap. Using the /LARGEADDRESSAWARE flag would allow cygwin to access up to a full 4GB of memory under Win7-64. Wouldn't that give enough to Cygwin to allow it to give more to the heap? No. cgf -- 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: windows paths in shebang lines
On Sun, Jan 23, 2011 at 10:26:15PM -0500, Rafael Kitover wrote: msys seems to do something special for this to work correctly, it also seems to translate its paths to windows paths when running windows executables automatically, a very nice feature. Command line munging is a nice feature if you're bastardizing the Cygwin DLL to sorta work with Windows apps which may or may not take a Windows PATH. It's an absolutely terrible feature if you are striving for compatibility with Linux/POSIX. cgf -- 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: Tcl file separator
On Tue, Jan 25, 2011 at 03:48:32PM -0600, Nellis, Kenneth wrote: From: Nellis, Kenneth I'm thinking that Cygwin Tcl's pwd should match Cygwin's and that file separator should return a Linux one. knellis@COBQDPPJ1 ~ $ pwd /cygdrive/d/cyghome/knellis knellis@COBQDPPJ1 ~ $ /cygdrive/c/cygwin/bin/tclsh84.exe % pwd D:/cyghome/knellis % file separator \ % I was hoping my OP would get some traction. It seems the basic purpose of Tcl's set of file commands is to allow one to write platform-independent scripts that need to manipulate pathnames. The Cygwin implementation seems to be broken. Tcl is currently one part of the Cygwin installation that is pretty much pure windows. It is that way for the sole purpose of working with the insight debugger. So it takes windows paths and is not a real Cygwin application. I'm working on this very very slowly but I don't have an ETA for when this will be fixed. -- 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
