Re: Updated: xterm-238-1
Hello, please add the following configure options to the xterm package: --enable-wide-chars to provide a UTF-8 environment for applications that need to use it (see also http://sourceware.org/ml/cygwin-xfree/2007-08/msg00069.html) --enable-256-color Thanks for consideration, kind regards, Thomas -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The following package has been updated in the Cygwin net distribution: *** xterm-238-1 This is a version update; no Cygwin-specific changes. Yaakov Cygwin/X DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the cygwin-xfree mailing list is the appropriate place. CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO: === To unsubscribe to the cygwin-xfree-announce mailing list, 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-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkl04KwACgkQpiWmPGlmQSMbQACfQ0DtbRqK2KoSVKOuIdEx5r+N bB4AoLUiW9UzAO6zmDm0xdQ0wc1LaIaE =inKq -END PGP SIGNATURE- -- 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/
RE: -query not working on cygwin/windows
km4hr wrote: This is a update including further information regarding my quest to get cygwin/x to connect to my CentOS linux server via xdmcp. I believe I have isolated the problem to either cygwin/x or Windows, probably Windows because no X-server that I've tried works. I've tried cygwin/x, Xming, and X-Win32. I've isolated the problem by booting my Windows PC from a Linux LiveCD (pclos). Using the pclos X-server I successfully connected to my CentOS host using X :1 -query centos box . It works perfectly. A beautiful gdm login screen pops up immediately. I think this proves that xdmcp is configured correctly on the CentOS host and that my network is not contributing to the problem. OK. So the problem seems to be that X cannot communicate with the remote host. Do you have another host you could connect to, and if so do you have the same problem? You could try telnet remotehost 6000. If you can connect, then the X port (6000) is open, and the problem is protocol related. If you get connection refused, then the port is closed. The above successful connection seems to isolate the problem to either cygwin/x, Windows, or the combination of both. Although no one on this site has confirmed that they are actually using cygwin/x successfully in an xdmcp environment I'm assuming that it does work for somebody. I have used it successfully, but that was a few years ago. If that assumption is correct then it appears something in my Windows configuration is blocking cygwin/x, and the other X-servers, from working properly. Could it be that necessary ports on my Windows box are blocked? I have my Windows firewall turned off. But I'm not sure that disabling the firewall opens the ports. Do I even need to open certain ports on the Windows box? This is an area that I know virtually nothing about. Do you have any other security software installed? Perhaps you have http://cygwin.com/acronyms/#BLODA These are applications/drivers (often apparently nothing to do with the problem, e.g. Logitech Webcam), that inject their code into each process and cause all sorts of weird problems. Phil, you had several questions. One was, why do you want to use xdmcp?. I want to use xdmcp for the same reason anyone wants to use it and for the same reason that it exists. That is, I want to log in to a complete gnome environment. I don't want to run individual applications. That's fine. I only asked because there have been several queries over the years from people who did just want to display individual apps and thought XDMCP was the way to go because it showed up first in a web search. You suggested I contact someone who is familiar with my Linux distribution to make sure I have xdmcp set up correctly. I have already done that. I am asking many of the same questions on the CentOS forum that I'm asking here. You gave me several links to study. I've read those and more. I've been at this for days. That's good (the researching, not the outcome ;-). As with any fault finding, a lot of time can be saved if we know what has already been read/tried. You asked why I'm blaming cygwin. I don't know what I said that made you think that. It was partly your other thread about the -ac option which suggested that you though XWin was denying the access. I'm not blaming anybody or anything. I'm just trying to get a gdm login screen on my PC. I understand. Perhaps blaming was too loaded a word to use. My problem may be related to Windows security. Can you suggest a good forum where I can find an expert on that? I don't know any Windows experts personally. I'm not sure they exist. They do exist, but they come at a price. Most of the self-professed experts I see on the web are pretty poor. I think investigating the BLODA avenue is perhaps your best course of action for now. It's amazing how many of the seemingly intractable problems turn out to be caused by some dodgy app. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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/
Re: Updated: xterm-238-1
On 2009/02/20 20:24, Thomas Wolff wrote: please add the following configure options to the xterm package: --enable-wide-chars to provide a UTF-8 environment for applications that need to use it --enable-256-color Both options are already enabled in xterm-238-1. (Try installing the xterm-238-1 source package and see /usr/src/xterm-238-1.cygport .) For more information on how to enable utf8 resource, see http://sourceware.org/ml/cygwin-xfree/2008-12/msg00079.html -- neomjp -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- 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/
Re: Can't move or resize xterms within twm
Jonathan Nichols wrote: Hello All, I just upgraded X11 to the latest version. The default behavior is to launch twm when I run startx. After first running into and working around this problem: http://cygwin.com/ml/cygwin-xfree/2009-02/msg0.html by doing this: http://cygwin.com/ml/cygwin-xfree/2009-02/msg00115.html I have run into another. After launching twm, it successfully inserts several xterms and an xclock into the twm window. However, I can not move or resize the xterms within twm. I am able to use the xterm's dropdown menus, but that's about it. Any help or feedback will be appreciated. I have enclosed my cygcheck output as an attachment. Hmm... transfig 3.2.5-1 tzcode 2008h-1 Something missing here? $ cygcheck -c -d | grep twm twm1.0.4-1 See also http://cygwin.com/ml/cygwin-xfree/2008-11/msg00345.html -- 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/
Re: -query not working on cygwin/windows
Well, I have now turned on all relevant ports in the Windows firewall. I still can't connnect. I turned on port 177(UDP) and 6000-6006(TCP). I even turned on extra ports as recommend by http://www.starnet.com/xwin32kb/What_ports_need_to_be_opened_for_XDMCP/ this source. I'm about out of ideas. I love to hear some more. I don't know how firewalls work but on the linux host side (CentOS) simplyturning off the firewall did not open the ports. I had to turn the firewall on and specify which ports to open. Otherwise no computers could connect via xdmcp over the network. Thanks for you consideration. Larry Hall (Cygwin X) wrote: km4hr wrote: I've found an article on the internet that explains http://support.microsoft.com/kb/842242 how to open ports in Windows. I'll try it tomorrow even though I don't know if it's necessary. If you are confident that you turned the Windows firewall off and you have no other firewalls or other security software installed on this machine, then you don't need to follow this prescription to test X. In order to run X properly with the firewall on, following the article wouldn't be a bad idea if you need help when doing the firewall configuration. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- 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/ -- View this message in context: http://www.nabble.com/%22-query%22-not-working-on-cygwin-windows-tp22007087p22120448.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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/
Re: xdvi unexplained locale problem
On Wed, Feb 18, 2009 at 3:02 PM, Mike Ayers mike_ay...@tvworks.com wrote: Dan Tsafrir wrote: open xdvi, I get the following error message: Warning: locale not supported by C library, locale unchanged Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default Warning: Unable to load any usable fontset Try unsetting LOCPATH: This didn't work either. In fact, I tried unset-ing this and very many other env variables before posting the question here. It seems to me that the behavior is unrelated to any env variables. It appears as though, for some unexplained reason, somewhere along the way, xdvi or X think they need to change to a locale other than C. Googling the error messages shows that ubuntu users faced a similar problem in early 2007 (related to xdvi and xfig): https://bugs.launchpad.net/ubuntu/+source/control-center/+bug/2066 Some thought it was an xorg problem. The suggested workarounds (e.g., setting a LANG=C env var) don't work for me. Am I the only one that gets this error message for xdvi on cygwin? --Dan -- 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/
RE: Reproducing the cygwin X problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Phil Betts Sent: Friday, February 20, 2009 4:25 AM I do not usually set it. I only did so in the sample to satisfy FAQ 6.1. ...but set it out of order. I didn't notice that because the results didn't change. Here's the more typical session: [SNIP] mike-ayers-lap echo $DISPLAY 127.0.0.1:0.0 mike-ayers-lap ssh -Y may...@mikeayers-linux-2 Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Fri Feb 20 09:23:39 2009 from 192.168.2.87 mikeayers-linux-2 echo $DISPLAY localhost:15.0 mikeayers-linux-2 xterm Xlib: connection to localhost:15.0 refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key xterm Xt error: Can't open display: localhost:15.0 mikeayers-linux-2 [/SNIP] HTH, Mike
RE: Reproducing the cygwin X problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Dan Tsafrir Sent: Friday, February 20, 2009 9:36 AM Initially, the only way I was aware of to get the copy-paste functionality back was to reboot the machine. But recently I've noticed another way. I run XP's 'clipbrd', which (in the state of no copy-paste functionality) produces one of these two strange outcomes: 1) clipboard displays the following message ClipBook Viewer cannot display the information in its current format or there is not enough memory to display it. Quit one or more applications to increase the available memory, and try again. 2) clipboard is going insane, seemingly trying to endlessly scroll down (while simultaneously displaying a message saying Method Open Fai) and taking up 25-30% of the CPU. In both case, if I click the 'delete' button within the clipboard application (= clear content of clipboard) then the insane behavior stops and copy-paste starts working again as long as no cygwin X application is involved. I can neither confirm nor deny this, as I don't have ClipBook available. But the minute I highlight some text in a cygwin X application, the insane behavior within clipbrd resumes. The only way to make things normal again (that I'm aware of) is to kill cygwin/X (which, in this situation, mandates killing all cygwin applications through the task-manager, otherwise they refuse to die and just hang). I just kill Xwin.exe forcibly in task manager - it takes all X apps with it. However, the better trick I discovered recently is to click on VNC's taskbar icon and close it. Once it closes, the X applications recover and can cut-n-pste with Windows apps. Also, because VNC is VNC, no setup is lost there either - I can reconnect and my console is unharmed. I suspect the problem here may be contention between the two applications that want to share the clipboard. Our other report implicated Office clipboard, which may be doing the same thing..? HTH, Mike -- 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/
Re: Reproducing the cygwin X problems
On Fri, Feb 20, 2009 at 1:05 PM, Mike Ayers mike_ay...@tvworks.com wrote: I can neither confirm nor deny this, as I don't have ClipBook available. Did you try to run 'clipbrd' through start-run ? I just kill Xwin.exe forcibly in task manager - it takes all X apps with it. Right. However, the better trick I discovered recently is to click on VNC's taskbar icon and close it. Once it closes, the X applications recover and can cut-n-pste with Windows apps. Also, because VNC is VNC, no setup is lost there either - I can reconnect and my console is unharmed. This too works for me (but as you say, only if I kill the vncviewer through the context menu that pops up when right clicking its taskbar icon; strangely, killing it through the top right x doesn't produce a similar effect). Thanks! I suspect the problem here may be contention between the two applications that want to share the clipboard. Our other report implicated Office clipboard, which may be doing the same thing..? I strongly suspect cygwin's xorg is solely to blame: this problem was created immediately after my last upgrade of cygwin during which I unwittingly moved from xfree to xorg. (This is only one of the things that want bad for me; I wish there was a way to return to xfree until most of the problems are resolved.) --Dan -- 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/
Re: Unable to load any usable ISO8859 font
Hello Jon, Thank you for your reply. To answer your questions: 1. I have installed all fonts... My typical Cygwin installation is install, i.e., everything gets selected, both for download and installation. I have found all fonts in the right places. Only the fonts.dir files were missing. 2. Checking /var/log/setup.log... A good idea! It says up-front: Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. but then keeps going. Everything gets installed with no complaints. Then we get to postinstalls and... every one ends with abnormal exit: exit code=128 One, catdoc.sh, flags exit code 129, and another one, hicolor-icon-theme.sh, does not flag an abnormal exit at all. All X11 related postinstall scrips, xinit.sh, X-start-menu-icons.sh, x3270.sh, xfig.sh, xinetd.sh, and xpdf.sh flag 128 on exit. Eventually the log says Installation Complete and that's it: Here is the excerpt: 2009/02/18 17:40:30 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/xinit.sh 2009/02/18 17:42:04 abnormal exit: exit code=128 2009/02/18 17:42:04 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/X-start-menu-icons.sh 2009/02/18 17:43:38 abnormal exit: exit code=128 2009/02/18 17:43:38 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/x3270.sh 2009/02/18 17:45:12 abnormal exit: exit code=128 2009/02/18 17:45:12 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/xfig.sh 2009/02/18 17:46:46 abnormal exit: exit code=128 2009/02/18 17:46:46 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/xinetd.sh 2009/02/18 17:48:20 abnormal exit: exit code=128 2009/02/18 17:48:20 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/xpdf.sh 2009/02/18 17:49:54 abnormal exit: exit code=128 2009/02/18 17:49:54 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/zsh-profile.sh 2009/02/18 17:51:28 abnormal exit: exit code=128 2009/02/18 18:12:17 note: Installation Complete 2009/02/18 18:12:17 Ending cygwin install cygcheck --sysinfo lists the following font packages: font-adobe-dpi100 1.0.0-1 font-adobe-dpi75 1.0.0-1 font-adobe-utopia-dpi100 1.0.1-1 font-adobe-utopia-dpi75 1.0.1-1 font-adobe-utopia-type1 1.0.1-1 font-alias 1.0.1-1 font-arabic-misc 1.0.0-1 font-bh-dpi100 1.0.0-1 font-bh-dpi75 1.0.0-1 font-bh-lucidatypewriter-dpi100 1.0.0-1 font-bh-lucidatypewriter-dpi75 1.0.0-1 font-bh-ttf 1.0.0-1 font-bh-type1 1.0.0-1 font-bitstream-dpi100 1.0.0-1 font-bitstream-dpi75 1.0.0-1 font-bitstream-speedo 1.0.0-1 font-bitstream-type1 1.0.0-1 font-bitstream-vera-ttf 1.10-1 font-cronyx-cyrillic 1.0.0-1 font-cursor-misc 1.0.0-1 font-daewoo-misc 1.0.0-1 font-dec-misc 1.0.0-1 font-encodings 1.0.2-1 font-ibm-type1 1.0.0-1 font-isas-misc 1.0.0-1 font-jis-misc 1.0.0-1 font-micro-misc 1.0.0-1 font-misc-cyrillic 1.0.0-1 font-misc-meltho 1.0.0-1 font-misc-misc 1.0.0-1 font-mutt-misc 1.0.0-1 font-schumacher-misc 1.0.0-1 font-screen-cyrillic 1.0.1-1 font-sony-misc 1.0.0-1 font-sun-misc 1.0.0-1 font-util 1.0.1-1 font-winitzki-cyrillic 1.0.0-1 font-xfree86-type1 1.0.1-1 In any case, as I said above, it's not really a missing font problem, but a missing fonts.dir problem, perhaps due to the aborted postinstall scripts flagged above. The installation was carried out on Vista under an Administrator account with Account Checking switched off and the fire wall switched off, too. Other missing bits... 1. no /etc/passwd and /etc/group: fixed this with mkpasswd and mkgroup. 2. no /usr/share/misc/man.conf: copied the file from another machine; man works fine now. 3. no dir file in /usr/share/info: made one with install-info; works fine now. Other than the above hiccups, things seem to work. I have configured sshd without problems, X11 works fine now, compilation works fine too, so far. No such problems on the XP, on which I have installed the same Cygwin version only a day earlier. The Vista cygcheck header is: Cygwin Configuration Diagnostics Current System Time: Fri Feb 20 14:29:24 2009 Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6001 Service Pack 1 Running under WOW64 on AMD64 Cheers, Gustav Zdzislaw Meglicki, OVPIT, Indiana University, Bloomington, Indiana http://perth.ovpit.indiana.edu/gustav From: Jon TURNEY jon.tur...@dronecode.org.uk To: cygwin-xfree@cygwin.com; zdzisi...@sbcglobal.net Sent: Thursday, February 19, 2009
RE: Reproducing the cygwin X problems
I use the vnc viewer from RealVNC and the X.org server from cygwin I and I don't have any copy and paste problems. My problems with the clipboard on Windows seem to be related to the Offfice clipboard application. Once I shut that down, everything seems fine. In fact, I copy/paste to/from the RealVNC viewer and X apps all the time. -Chris -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Mike Ayers Sent: Thursday, February 19, 2009 3:50 PM To: cygwin-xfree@cygwin.com Subject: Reproducing the cygwin X problems Lately, I have been having problems with the cygwin X server and cut-n-paste. I have reported a connection to vncclient (RealVNC) - in fact, I don't recall having problems with vncclient not running. These days I use one or the other - so far, so good. Unfortunately, though, I am in the habit of cutting and pasting between vncclient and cygwin X, so if I can be of any tracking the problem down, please let me know. If I have vncclient and an xterm running, simply selecting text on the xterm is sufficient to cause the problem, which I confirm by raising the xterm over the vncclient, then clicking the vncclient to raise it (it then exhibits responsiveness problems). Today I noticed a new problem, which may or may not be related: [SNIP] mike-ayers-lap ssh -Y -l mayers mikeayers-linux-2 Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Thu Feb 19 11:54:55 2009 from 192.168.2.87 mikeayers-linux-2 export DISPLAY=192.168.2.87:0 mikeayers-linux-2 xterm Xlib: connection to 192.168.2.87:0.0 refused by server Xlib: No protocol specified xterm Xt error: Can't open display: 192.168.2.87:0 mikeayers-linux-2 [/SNIP] This same technique used to work. The only changes I have made since it last worked was (1) update cygwin, including X, and (2) add -- -multiwindow -clipboard to my invocation of startx (I used to get those by default). Let me know if you have trouble reproducing this. HTH, Mike -- 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/
RE: Reproducing the cygwin X problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Williams, Chris (Marlboro) Sent: Friday, February 20, 2009 11:40 AM I use the vnc viewer from RealVNC and the X.org server from cygwin I and I don't have any copy and paste problems. My problems with the clipboard on Windows seem to be related to the Offfice clipboard application. Once I shut that down, everything seems fine. In fact, I copy/paste to/from the RealVNC viewer and X apps all the time. H... which invocation method and clipboard type are you using? I am running `/usr/bin/startx -- -multiwindow -clipboard`. Thanks, Mike -- 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/
RE: Reproducing the cygwin X problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Williams, Chris (Marlboro) Sent: Friday, February 20, 2009 12:19 PM There is also a warning about not usign xwinclip with the -clipboard switch I am not explicitly running xwinclip - is there an implicit way to be running it? Thanks, Mike -- 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/
BadAlloc
Hi folk, I have a problem with the Xserver. I have installed xorg-x11-base 7.4-1 xorg-x11-bin7.4-1 xorg-x11-bin-dlls 7.4-1 xorg-x11-bin-lndir 7.4-1 xorg-x11-etc7.4-1 xorg-x11-fenc 7.4-1 xorg-x11-fnts 7.4-1 xorg-x11-libs-data 7.4-1 xorg-x11-man-pages 7.4-1 xorg-x11-man-pages-html 7.4-1 xorg-x11-xwin 7.4-1 Under cygwin everything is fine, but when I start a x-Programm like xterm from another machine like Sunos $ uname -a SunOS beadev 5.10 Generic_118822-23 sun4u sparc SUNW,Sun-Fire-V240 The xterm starts, but when I press a key the x crashes with the following error message - xterm: warning, error event received: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 136 (XKEYBOARD) Minor opcode of failed request: 16 (XkbSetNamedIndicator) Serial number of failed request: 133 Current serial number in output stream: 137 - I would be happy about any Idea to fix the problem. With the older Version of X i didn't had that problem. I hope that someone can help me Thanks Franz -- 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/
RE: BadAlloc
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of cygwin-xfree.20.maillingl...@spamgourmet.com The xterm starts, but when I press a key the x crashes with the following error message - xterm: warning, error event received: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 136 (XKEYBOARD) Minor opcode of failed request: 16 (XkbSetNamedIndicator) Serial number of failed request: 133 Current serial number in output stream: 137 - From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Jon TURNEY Sent: Friday, January 23, 2009 11:06 AM I'm afraid this has the status of 'known issue' at the moment, until someone who can reproduce the problem works on it. Tracking in bugzilla: http://sourceware.org/bugzilla/show_bug.cgi?id=9780 HTH, Mike -- 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/
Re: Reproducing the cygwin X problems
On Fri, Feb 20, 2009 at 3:19 PM, Williams, Chris (Marlboro) christopherb.willi...@amd.com wrote: I use the file C:\cygwin\bin\startxwin.bat Me too, so I would guess that the difference in the copy-paste behavior we observe, is unrelated. --Dan -- 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/
RE: Reproducing the cygwin X problems
Are you running the office clipboard from Office 2003? -Chris -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Dan Tsafrir Sent: Friday, February 20, 2009 3:55 PM To: cygwin-xfree@cygwin.com Subject: Re: Reproducing the cygwin X problems On Fri, Feb 20, 2009 at 3:19 PM, Williams, Chris (Marlboro) christopherb.willi...@amd.com wrote: I use the file C:\cygwin\bin\startxwin.bat Me too, so I would guess that the difference in the copy-paste behavior we observe, is unrelated. --Dan -- 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/ -- 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/
RE: Reproducing the cygwin X problems
I am not explicitly running xwinclip - is there an implicit way to be running it? I would think not, that might even be an outdated warning. I don't even have xwinclip installed in my system. If you have it I would just remove it to be on the safe side. -Chris -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Mike Ayers Sent: Friday, February 20, 2009 3:24 PM To: cygwin-xfree@cygwin.com Subject: RE: Reproducing the cygwin X problems From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Williams, Chris (Marlboro) Sent: Friday, February 20, 2009 12:19 PM There is also a warning about not usign xwinclip with the -clipboard switch I am not explicitly running xwinclip - is there an implicit way to be running it? Thanks, Mike -- 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/ -- 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 autoload.cc sec_au ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-02-20 16:10:45 Modified files: winsup/cygwin : ChangeLog autoload.cc sec_auth.cc Log message: * autoload.cc (NetLocalGroupEnum): Remove. (NetLocalGroupGetMembers): Remove. (NetUserGetLocalGroups): Add. * sec_auth.cc (is_group_member): Remove function. (get_user_local_groups): Get user as string instead of as SID. Call NetUserGetLocalGroups instead of NetLocalGroupEnum. Drop call to is_group_member. (get_server_groups): Call get_user_local_groups with user name instead of user SID. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4385r2=1.4386 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/autoload.cc.diff?cvsroot=srcr1=1.157r2=1.158 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sec_auth.cc.diff?cvsroot=srcr1=1.18r2=1.19
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
On Feb 19 23:03, Charles Wilson wrote: Corinna Vinschen wrote: I've updated the Cygwin 1.7 version of file to 5.00-1. Odd behavior: after I did a rebaseall, I was consistently seeing coredumps using this version of file. Reverting to the older version of file fixed it, as did re-installing the new version. I haven't rebased again, but is there any reason to suspect that cygmagic-1.dll is not rebaseable? Apparently. I rebased the DLL alone and afterwards file simply stopped working. The DLL has a base address of 0x6a50. Even rebasing to the very same address results in a coredump! The DLL has been built with -static-libgcc. Assuming that this might have been the reason I rebuilt the file package without -static-libgcc, so the DLL now depends on cyggcc_s.dll. And, guess what, afterwards the DLL is rebaseable just fine. Dave? Any idea why this occurs? The crash happens when the Cygwin DLL is running the ctors list. Given that the file package is using plain C, it seems that a static libgcc is non-relocatable for whatever reason. For the time being, I create and uploaded a new file package which depends on gcc4-runtime. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Windows Mobile?
Are there any plans to port Cygwin to Windows Mobile? Dates? If not, I'd be interested to know why. Harold Fuchs London, England -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem Adding Membership Multicast Errno 22
Hi,
I have written a C++ program for a Multicast Client that compiles and runs
on Ubuntu. I tried to compile and run it on Cygwin version 1.5.25 (June
2008). However, when I run the code, the Multicast receiving socket doesn't
seem to work. The problem comes when I use setsockopt() to add Multicast
membership. The errno() declaration returns 22 (EINVAL), but I cannot find a
solution. My code is:
int Descriptor, Descriptor2, payloadoffset,sqnum, T_ns, status;
long nsegundos,Dnsegundos, segundos, Dsegundos;
struct sockaddr_in Direccion, Direccion2;
unsigned short Puerto;
struct timespec valorcontador,valorcontador2,Next;
struct ip_mreq Multic;
Descriptor=socket(AF_INET,SOCK_DGRAM,0);
Puerto=12100;
Direccion.sin_family=AF_INET;
Direccion.sin_port=htons(Puerto);
Direccion.sin_addr.s_addr=inet_addr(224.0.22.1);
memset((Direccion.sin_zero),'\0',8);
Multic.imr_multiaddr.s_addr=inet_addr(224.0.22.1);
Multic.imr_interface.s_addr=inet_addr(138.4.32.34);
status= setsockopt(Descriptor, IPPROTO_IP, IP_ADD_MEMBERSHIP, Multic,
sizeof(Multic));
if (status0){
printf(Fallo al añadir el grupo de Multicast, codigo %i\n,
errno);
}
I would really appreciate your help with this. Thanks in advance.
Victor
--
View this message in context:
http://www.nabble.com/Problem-Adding-Membership-Multicast-Errno-22-tp22119431p22119431.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Windows Mobile?
On Fri, 20 Feb 2009 11:20:41 -, Harold Fuchs har...@wolfeden.demon.co.uk wrote: Are there any plans to port Cygwin to Windows Mobile? Dates? If not, I'd be interested to know why. Harold Fuchs London, England -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ You can already use cegcc, don't see the point to port cygwin. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem Adding Membership Multicast Errno 22
On Feb 20 04:05, victhor_1983 wrote:
Hi,
I have written a C++ program for a Multicast Client that compiles and runs
on Ubuntu. I tried to compile and run it on Cygwin version 1.5.25 (June
2008). However, when I run the code, the Multicast receiving socket doesn't
seem to work. The problem comes when I use setsockopt() to add Multicast
membership. The errno() declaration returns 22 (EINVAL), but I cannot find a
solution. My code is:
int Descriptor, Descriptor2, payloadoffset,sqnum, T_ns, status;
long nsegundos,Dnsegundos, segundos, Dsegundos;
struct sockaddr_in Direccion, Direccion2;
unsigned short Puerto;
struct timespec valorcontador,valorcontador2,Next;
struct ip_mreq Multic;
Descriptor=socket(AF_INET,SOCK_DGRAM,0);
Puerto=12100;
Direccion.sin_family=AF_INET;
Direccion.sin_port=htons(Puerto);
Direccion.sin_addr.s_addr=inet_addr(224.0.22.1);
memset((Direccion.sin_zero),'\0',8);
Multic.imr_multiaddr.s_addr=inet_addr(224.0.22.1);
Multic.imr_interface.s_addr=inet_addr(138.4.32.34);
status= setsockopt(Descriptor, IPPROTO_IP, IP_ADD_MEMBERSHIP, Multic,
sizeof(Multic));
if (status0){
printf(Fallo al añadir el grupo de Multicast, codigo %i\n,
errno);
}
I'm sorry, I can't tell you why this doesn't work. Cygwin's setsockopt
function is basically just a shim between application and Winsock's
setsockopt call. It only performs special actions on a very limited
set of options, only two actually: (SOL_SOCKET, SO_REUSEADDR) and
(IPPROTO_IP, IP_TOS). I'm also quite multicast illiterate. Is it
possible that you have to use the IP_MULTICAST_IF option on Windows
before you can use IP_ADD_MEMBERSHIP?!?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Problem Adding Membership Multicast Errno 22
On Feb 20 13:48, Corinna Vinschen wrote:
On Feb 20 04:05, victhor_1983 wrote:
status= setsockopt(Descriptor, IPPROTO_IP, IP_ADD_MEMBERSHIP, Multic,
sizeof(Multic));
if (status0){
printf(Fallo al añadir el grupo de Multicast, codigo %i\n,
errno);
}
I'm sorry, I can't tell you why this doesn't work. Cygwin's setsockopt
function is basically just a shim between application and Winsock's
setsockopt call. It only performs special actions on a very limited
set of options, only two actually: (SOL_SOCKET, SO_REUSEADDR) and
(IPPROTO_IP, IP_TOS). I'm also quite multicast illiterate. Is it
possible that you have to use the IP_MULTICAST_IF option on Windows
before you can use IP_ADD_MEMBERSHIP?!?
Here's one idea: Is it possible that your application includes
winsock.h? If so, don't do that, use the POSIX headers for socket and
ip stuff. Winsock.h is the WInsock specific header file for
applications using the old Winsock 1.x API. In that API,
IP_ADD_MEMBERSHIP is defined as the value 5.
However, the newer Winsock 2.x API, which is used by Cygwin under the
hood as well, defines IP_ADD_MEMBERSHIP as the value 12. So, if there's
any chance that you're including the winsock.h header, remove it and
only use Cygwin's header files, not the Winsock specifc header files.
Hope that helps,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
Corinna Vinschen wrote: On Feb 19 23:03, Charles Wilson wrote: Corinna Vinschen wrote: I've updated the Cygwin 1.7 version of file to 5.00-1. Odd behavior: after I did a rebaseall, I was consistently seeing coredumps using this version of file. Reverting to the older version of file fixed it, as did re-installing the new version. I haven't rebased again, but is there any reason to suspect that cygmagic-1.dll is not rebaseable? Apparently. I rebased the DLL alone and afterwards file simply stopped working. The DLL has a base address of 0x6a50. Even rebasing to the very same address results in a coredump! The DLL has been built with -static-libgcc. Assuming that this might have been the reason I rebuilt the file package without -static-libgcc, so the DLL now depends on cyggcc_s.dll. And, guess what, afterwards the DLL is rebaseable just fine. Dave? Any idea why this occurs? The crash happens when the Cygwin DLL is running the ctors list. Given that the file package is using plain C, it seems that a static libgcc is non-relocatable for whatever reason. Investigating. While I do that, I noticed a bug: libtool: compile: gcc-4 -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\/usr/local/share/file/magic\ -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT magic.lo -MD -MP -MF .deps/magic.Tpo -c magic.c -o magic.o magic.c: In function 'file_or_fd': magic.c:304: warning: passing argument 1 of 'strlcat' makes pointer from integer without a cast 304 (void)strlcat(strlcpy(tmp, inname, len), .exe, len); That sort of construct works for strcat (strcpy ()) but not for the 'l' versions, they aren't drop-in replacements. suddenly does HUGE double-take on seeing surrounding code 251 public const char * 252 magic_file(struct magic_set *ms, const char *inname) ... 257 private const char * 258 file_or_fd(struct magic_set *ms, const char *inname, int fd) /sighs *facepalm* hurried grep 68 #define private static 69 #ifndef protected 70 #define protected 71 #endif 72 #define public *headdesk* *facepalm* *headdesk* *facepalm* *headdesk* cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem Adding Membership Multicast Errno 22
Thanks for the advice, I just tried it, but I keep getting the same mistake.
Maybe there is no IP_ADD_MEMBERSHIP option for Multicast in Cygwin?
Victor
Corinna Vinschen-2 wrote:
On Feb 20 04:05, victhor_1983 wrote:
Hi,
I have written a C++ program for a Multicast Client that compiles and
runs
on Ubuntu. I tried to compile and run it on Cygwin version 1.5.25 (June
2008). However, when I run the code, the Multicast receiving socket
doesn't
seem to work. The problem comes when I use setsockopt() to add Multicast
membership. The errno() declaration returns 22 (EINVAL), but I cannot
find a
solution. My code is:
int Descriptor, Descriptor2, payloadoffset,sqnum, T_ns, status;
long nsegundos,Dnsegundos, segundos, Dsegundos;
struct sockaddr_in Direccion, Direccion2;
unsigned short Puerto;
struct timespec valorcontador,valorcontador2,Next;
struct ip_mreq Multic;
Descriptor=socket(AF_INET,SOCK_DGRAM,0);
Puerto=12100;
Direccion.sin_family=AF_INET;
Direccion.sin_port=htons(Puerto);
Direccion.sin_addr.s_addr=inet_addr(224.0.22.1);
memset((Direccion.sin_zero),'\0',8);
Multic.imr_multiaddr.s_addr=inet_addr(224.0.22.1);
Multic.imr_interface.s_addr=inet_addr(138.4.32.34);
status= setsockopt(Descriptor, IPPROTO_IP, IP_ADD_MEMBERSHIP, Multic,
sizeof(Multic));
if (status0){
printf(Fallo al añadir el grupo de Multicast, codigo %i\n,
errno);
}
I'm sorry, I can't tell you why this doesn't work. Cygwin's setsockopt
function is basically just a shim between application and Winsock's
setsockopt call. It only performs special actions on a very limited
set of options, only two actually: (SOL_SOCKET, SO_REUSEADDR) and
(IPPROTO_IP, IP_TOS). I'm also quite multicast illiterate. Is it
possible that you have to use the IP_MULTICAST_IF option on Windows
before you can use IP_ADD_MEMBERSHIP?!?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
View this message in context:
http://www.nabble.com/Problem-Adding-Membership-Multicast-Errno-22-tp22119431p22120193.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
Corinna Vinschen wrote: I haven't rebased again, but is there any reason to suspect that cygmagic-1.dll is not rebaseable? Apparently. I rebased the DLL alone and afterwards file simply stopped working. The DLL has a base address of 0x6a50. Even rebasing to the very same address results in a coredump! The DLL has been built with -static-libgcc. Assuming that this might have been the reason I rebuilt the file package without -static-libgcc, so the DLL now depends on cyggcc_s.dll. And, guess what, afterwards the DLL is rebaseable just fine. Dave? Any idea why this occurs? Nope, I can't reproduce it yet. I installed the file-5.00-1 sources and then ran r...@host /usr/src/file-5.00-1 $ ./configure --prefix=/usr/local CC='gcc-4 -static-libgcc' $ make $ cd src/.libs/ $ cp cygmagic-1.dll cygmagic-1.dll.bak $ rebase -v -b 0x6a50 ./cygmagic-1.dll r...@host /usr/src/file-5.00-1/src/.libs $ ./file.exe ./file.exe file: could not find any magic files! No crash. Then I tried it on the live version in /bin: r...@host /bin $ cp cygmagic-1.dll cygmagic-1.dll.bak r...@host /bin $ ./file.exe ./file.exe ./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit r...@host /bin $ rebase -v -b 0x6a50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6a50, new size = 2 r...@host /bin $ ./file.exe ./file.exe ./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit I verified that I have the statically linked version installed, rather than the update you just uploaded: r...@host /bin $ cygcheck ./cygmagic-1.dll F:\cygwin-1.7\bin\cygmagic-1.dll F:\cygwin-1.7\bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL F:\cygwin-1.7\bin\cygz.dll r...@host /bin Did I do something wrong? Did you do something differently? I note that after my attempt to rebase at the same address, the DLL afterward is identical to the one before: dkad...@ubik /bin $ md5sum cygmagic-1.dll cygmagic-1.dll.bak 1628930e970b95891bd5ce79bab9f814 *cygmagic-1.dll 1628930e970b95891bd5ce79bab9f814 *cygmagic-1.dll.bak Do you see the same result? Because if so, that would be *really* strange! The crash happens when the Cygwin DLL is running the ctors list. Given that the file package is using plain C, it seems that a static libgcc is non-relocatable for whatever reason. I'm fairly certain it shouldn't be. You can't expect exceptions to work right in these circumstances, but I wouldn't see why they would be involved. Can one of you and Chuck run addr2line on the stackdump from the crash? I have no idea what's even going on yet. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
On Feb 20 13:35, Dave Korn wrote: Corinna Vinschen wrote: Apparently. I rebased the DLL alone and afterwards file simply stopped working. The DLL has a base address of 0x6a50. Even rebasing to the very same address results in a coredump! The DLL has been built with -static-libgcc. Assuming that this might have been the reason I rebuilt the file package without -static-libgcc, so the DLL now depends on cyggcc_s.dll. And, guess what, afterwards the DLL is rebaseable just fine. Dave? Any idea why this occurs? The crash happens when the Cygwin DLL is running the ctors list. Given that the file package is using plain C, it seems that a static libgcc is non-relocatable for whatever reason. Investigating. While I do that, I noticed a bug: libtool: compile: gcc-4 -DHAVE_CONFIG_H -I. -I.. -DMAGIC=\/usr/local/share/file/magic\ -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT magic.lo -MD -MP -MF .deps/magic.Tpo -c magic.c -o magic.o magic.c: In function 'file_or_fd': magic.c:304: warning: passing argument 1 of 'strlcat' makes pointer from integer without a cast 304(void)strlcat(strlcpy(tmp, inname, len), .exe, len); That sort of construct works for strcat (strcpy ()) but not for the 'l' versions, they aren't drop-in replacements. Urgh! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Windows Mobile?
Vincent R. wrote: On Fri, 20 Feb 2009 11:20:41 -, Harold Fuchs wrote: Are there any plans to port Cygwin to Windows Mobile? Dates? Not that I know of. If not, I'd be interested to know why. Well, the reason I wasn't planning to do it is because I don't ever use Windows Mobile. I can't speak for anyone else of course. You can already use cegcc, don't see the point to port cygwin. Huh? You can already use MinGW on ordinary windows, but there was a point in writing Cygwin in the first place. Neither cegcc nor MinGW give you a Posix API and environment; that's what Cygwin does on non-mobile Windows, and that's what would be the point of porting it to Mobile Windows. Am I missing something here? cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
On Feb 20 14:45, Corinna Vinschen wrote: On Feb 20 13:35, Dave Korn wrote: magic.c:304: warning: passing argument 1 of 'strlcat' makes pointer from integer without a cast 304 (void)strlcat(strlcpy(tmp, inname, len), .exe, len); That sort of construct works for strcat (strcpy ()) but not for the 'l' versions, they aren't drop-in replacements. Urgh! Upstream has changed my code! Sacrilege! Fortunately this code won't be used anymore in Cygwin 1.7 because 1.7 appends the .exe suffix in calls to open transparently. I'll send a fix upstream. The fix is to remove the CYGWIN specific code. I won't create a 1.5.x version of file = 5.00 anyway. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
Dave Korn wrote: Corinna Vinschen wrote: Apparently. I rebased the DLL alone and afterwards file simply stopped working. The DLL has a base address of 0x6a50. Even rebasing to the very same address results in a coredump! Nope, I can't reproduce it yet. I can now, but not by rebasing to the exact same address; did something just go amiss in your testing of that particular case maybe? dkad...@ubik /bin $ rebase -v -b 0x6b50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6b50, new size = 2 dkad...@ubik /bin $ ./file.exe ./file.exe 1 [main] file 1556 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) It's reversible, too! dkad...@ubik /bin $ rebase -v -b 0x6a50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6a50, new size = 2 dkad...@ubik /bin $ ./file.exe ./file.exe ./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit dkad...@ubik /bin $ rebase -v -b 0x6b50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6b50, new size = 2 dkad...@ubik /bin $ ./file.exe ./file.exe 1 [main] file 1404 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) dkad...@ubik /bin $ rebase -v -b 0x6a50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6a50, new size = 2 dkad...@ubik /bin $ ./file.exe ./file.exe ./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit dkad...@ubik /bin Ok, now I'll try debugging it. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Windows Mobile?
On Fri, 20 Feb 2009 13:57:49 +, Dave Korn dave.korn.cyg...@googlemail.com wrote: Vincent R. wrote: On Fri, 20 Feb 2009 11:20:41 -, Harold Fuchs wrote: Are there any plans to port Cygwin to Windows Mobile? Dates? Not that I know of. If not, I'd be interested to know why. Well, the reason I wasn't planning to do it is because I don't ever use Windows Mobile. I can't speak for anyone else of course. You can already use cegcc, don't see the point to port cygwin. Huh? You can already use MinGW on ordinary windows, but there was a point in writing Cygwin in the first place. Neither cegcc nor MinGW give you a Posix API and environment; that's what Cygwin does on non-mobile Windows, and that's what would be the point of porting it to Mobile Windows. Am I missing something here? Still don't understand because cegcc provides you with POSIX API! And what would mean to port cygwin on Windows Mobile, does it mean you want a terminal with a compiler running directly on the device ? You need to know that cegcc is actually a common name for two different toolchains cegcc = POSIX API + newlib libc mingw32ce = mingw for wince : native API + native libc To say it differently : cegcc = cygwin for wince mingw32ce = mingw for wince But maybe I am the one missing something ? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Windows Mobile?
Vincent R. wrote: Still don't understand because cegcc provides you with POSIX API! Oh, wow! I didn't know that, I thought it was more like MinGW; it's actually far more comprehensive than I thought. And what would mean to port cygwin on Windows Mobile, does it mean you want a terminal with a compiler running directly on the device ? You'll have to ask Harold, but I was acting under the assumption that that is what he wanted, or at any rate, a version of cygwin1.dll that runs on CE. You need to know that cegcc is actually a common name for two different toolchains cegcc = POSIX API + newlib libc mingw32ce = mingw for wince : native API + native libc To say it differently : cegcc = cygwin for wince mingw32ce = mingw for wince But maybe I am the one missing something ? No, I was; thank you for explaining. I haven't been paying attention to the windows mobile platforms (until just the other day as it happens, when I was trying to find out if anyone still uses sh-*-pe, which I gather you guys don't). cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
On Feb 20 14:14, Dave Korn wrote: Dave Korn wrote: Corinna Vinschen wrote: Apparently. I rebased the DLL alone and afterwards file simply stopped working. The DLL has a base address of 0x6a50. Even rebasing to the very same address results in a coredump! Nope, I can't reproduce it yet. I can now, but not by rebasing to the exact same address; did something just go amiss in your testing of that particular case maybe? I have no idea, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSH V.5.1 with Cygwin1.dll 1.7.0: Very large logon times...
Hello, No. Not really. The only reason could be that the code isn't called. Only further debugging will help. It ist very difficult to put in debug statements at the right places within the sourcecode because of the complexity of the programs. But we have just found out these new facts: - We copied our productive Active Directory database into a test environment + AD database contained 8700 users, 6000 groups, 9600 computers + part of this test network are only three computers: root domain controller, domain controller, member server + problem of large logon time could also be seen in this copied environment - In the next step we deleted most of the Active Directory objects + After this deletion process AD database contains only 278 users, 784 groups and 32 computers + SSH login takes only 1 sec. for login With theses informations it should be possible for you developers to adjust the situation. Increase the number of your Active Directory objects, and you will probably see that the logon time will also increase! Anything within your ssh logon process takes more time the bigger the Active Directory database is. Thanks a lot in advance and best regards Carsten Porzler -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
Dave Korn wrote:
Ok, now I'll try debugging it.
Ah. Right. Ouch. I see what's going on. Rebasing does not interact well
with the presence of unresolved weaks. Gah.
The problem arises here, in cygming-crtbegin.c:
---snip---
extern void __register_frame_info (const void *, struct object *)
TARGET_ATTRIBUTE_WEAK;
---snip---
/* We need to indirect through a variable, as gcc assumes
that a function label used as a constant is never zero. */
void (*register_frame_info_ptr) (const void *, struct object *) =
__register_frame_info;
---snip---
comments, #ifdefs folded
void
__gcc_register_frame (void)
{
void (*register_frame_fn) (const void *, struct object *) = 0;
HANDLE h = GetModuleHandle (LIBGCC_SONAME);
if (h)
register_frame_fn = (void (*) (const void *, struct object *))
GetProcAddress (h, __register_frame_info);
if (!register_frame_fn)
register_frame_fn = register_frame_info_ptr;
if (register_frame_fn)
register_frame_fn (__EH_FRAME_BEGIN__, obj);
---snip---
The purpose of playing these games is in order not to drag in the whole
exception handling machinery into a statically-linked application unless we
actually need it. We're relying on detecting an unlinked weak symbol by it
having a value of zero at runtime. That usually works, but the pointer
variable register_frame_info_ptr must have some kind of reloc pointing at it,
because rebase adjusts it, so instead of zero it becomes equal to the
difference between the new and old base addresses.
I'll need to do some thinking about this, as it might be possible to make it
work, but in any case, the rule should be that DLLs are *always* linked
against shared-libgcc, regardless; even plain old C with no exceptions. It's
OK if you're linking an entire app statically to link against static libgcc,
but it's definitely bad practice when building a DLL. I should probably warn
against this usage in the compiler, if not fail it altogether; not sure yet,
because it does basically work, even if the DLL it produces isn't rebaseable,
and because it might not be difficult to make rebase skip relocating
unresolved weaks, and because I have this long-term scheme to make weaks work
properly on win32 like they do on ELF which would avoid the problem altogether.
Take-home point: never use -static-libgcc when building a DLL.
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: SSH V.5.1 with Cygwin1.dll 1.7.0: Very large logon times...
On Feb 20 15:48, carsten.porz...@spb.de wrote: It ist very difficult to put in debug statements at the right places within the sourcecode because of the complexity of the programs. But we have just found out these new facts: - We copied our productive Active Directory database into a test environment + AD database contained 8700 users, 6000 groups, 9600 computers + part of this test network are only three computers: root domain controller, domain controller, member server + problem of large logon time could also be seen in this copied environment - In the next step we deleted most of the Active Directory objects + After this deletion process AD database contains only 278 users, 784 groups and 32 computers + SSH login takes only 1 sec. for login With theses informations it should be possible for you developers to adjust the situation. Increase the number of your Active Directory objects, and you will probably see that the logon time will also increase! Anything within your ssh logon process takes more time the bigger the Active Directory database is. I just discussed this problem and my code with somebody having more insight into this AD stuff. I now have a hunch what I could do to fix this bad timing problem. Stay tuned. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
On Feb 20 15:06, Dave Korn wrote: Dave Korn wrote: Ah. Right. Ouch. I see what's going on. Rebasing does not interact well with the presence of unresolved weaks. Gah. [...] I'll need to do some thinking about this, as it might be possible to make it work, but in any case, the rule should be that DLLs are *always* linked against shared-libgcc, regardless; even plain old C with no exceptions. It's OK if you're linking an entire app statically to link against static libgcc, but it's definitely bad practice when building a DLL. I should probably warn against this usage in the compiler, if not fail it altogether; not sure yet, because it does basically work, even if the DLL it produces isn't rebaseable, and because it might not be difficult to make rebase skip relocating unresolved weaks, and because I have this long-term scheme to make weaks work properly on win32 like they do on ELF which would avoid the problem altogether. Take-home point: never use -static-libgcc when building a DLL. Baeh. The two of us discussed this in PM a couple of days back and I still don't like the idea to depend on cyggcc_s.dll for more or less every other package providing a DLL. If that's becoming the default, we need at least to put the gcc-runtime package into Base, IMHO. Yes, I know you can simply add the dependency to setup.hint, but still. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem Adding Membership Multicast Errno 22
On Fri, 20 Feb 2009, victhor_1983 wrote: Thanks for the advice, I just tried it, but I keep getting the same mistake. Maybe there is no IP_ADD_MEMBERSHIP option for Multicast in Cygwin? There definately is as I use it daily. I'm not sure the cause of the EINVAL, but without a bind, it definately won't work on Windows: http://www.cygwin.com/ml/cygwin/2006-08/msg00703.html I assume you aren't trying to define IP_ADD_MEMBERSHIP yourself? http://cygwin.com/ml/cygwin/2005-09/msg01007.html Are you sure the interface IP exists and is up with a link on your test system? Multic.imr_interface.s_addr=inet_addr(138.4.32.34); Corinna Vinschen-2 wrote: Is it possible that you have to use the IP_MULTICAST_IF option on Windows before you can use IP_ADD_MEMBERSHIP?!? Nope. IP_MULTICAST_IF specifies which interface to use for outbound traffic. IP_ADD_MEMBERSHIP tells a particular interface to receive multicast traffic. That IP must be present and up with link, or EINVAL will be returned. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
Corinna Vinschen wrote: Take-home point: never use -static-libgcc when building a DLL. Baeh. The two of us discussed this in PM a couple of days back and I still don't like the idea to depend on cyggcc_s.dll for more or less every other package providing a DLL. Nah, I think I was expressing that too strongly. I guess if something's only pulling in a few math functions from the DLL, it shouldn't need to do so dynamically if it doesn't want to. I'll find a way to make this usage work under rebasing. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Strange freezes when using gdb (rxvt/mintty but not dos box)
Hi...
Today I observed a strange freeze when using gdb-6.8-2 (or cvs gdb)
within cygwin 1.5.25 on 2 different machines.
gdb freezes upon execution of the inferior process when used from within
mintty/rxvt, but does not freeze when gdb
is invoked from a (conventional) bash inside of a windows DOS box. I
assume some race conditions/syncronization
issue causing a thread block.
What did I want to do.. I compiled myself a little piece of code (see
below) to check how different gdb version
behave unwinding the stack on crashes in different threads. The
application I want to debug is compiled for mingw.
Here comes the code (if someone wants to reproduce):
--
#include stdio.h
#include windows.h
void func1(int num);
int var = 23;
void crashIfZero(int num)
{
var--;
if (var == 0)
{
int *data=0x0;
printf (I am thread %d and I will crash now!\n,num);
*data=911;
}
else
printf (Thread %d: var = %d\n,num,var);
}
void func4(int num)
{
Sleep(100);
crashIfZero(num);
func1(num);
}
void func3(int num)
{
Sleep(100);
crashIfZero(num);
func4(num);
}
void func2(int num)
{
Sleep(100);
crashIfZero(num);
func3(num);
}
void func1(int num)
{
Sleep(100);
crashIfZero(num);
func2(num);
}
DWORD WINAPI threadFunc(LPVOID param)
{
int num = *(DWORD *)param;
printf (I am thread %d and alive\n);
func1(num);
}
void makeThreads(int num)
{
int i;
for (i=1;i=num;i++)
{
HANDLE threadHandle;
DWORD threadId, threadParam = i;
threadHandle =
CreateThread(NULL,0,threadFunc,threadParam,0,threadId);
if (threadHandle == NULL)
printf (Couldn't create thread %d\n,i);
else
printf (Created thread %d with ID: %d\n,i,threadId);
Sleep(50);
}
printf (Created %d Threads\n,num);
Sleep(20);
}
int main(int argc,char **argv)
{
setbuf(stdout,NULL);
setbuf(stderr,NULL);
printf (test gdb stack tracing during a crash\n);
makeThreads(3);
}
--
Compiled using: gcc -g -mno-cygwin gdb_crash.c -o gdb_crash
Invoking gdb: gdb gdb_crash.exe
The (gdb) prompt appears just fine... When I now enter r to run the code
gdb prints the first lines but then freezes when gdb ist started using
mintty/rxvt.
$ gdb gdb_crash.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) r
Starting program: gdb_crash.exe
[New thread 2060.0xca4]
test gdb stack tracing during a crash
C[New thread 2060.0xfdc]
reated thread 1 with ID: 4060
I am thread 1 and alive
C
That's it... When I do this from cygwin bash inside of a dos box
everything is fine.
I assume it is happening during the phase when gdb wants to print the
next [New thread 2060.0x] line
Please not that that the [New thread 2060.0x] line is in between
of the output of the Created thread 1 with ... line.
When running it from dos box the lines are not mixed. Everything is fine.
While this is curious enough it is still not the whole story. I made my
tests on a Intel Quadcore (Q9550). The problems
DO NOT happen on a AMD Singlecore maschine (XP 2800+). The cygwin is
100% identical on both systems
(copied bit by bit from machine A to machine B). Both systems run
Windows XP SP 3 32bit.
When I limit gdb to just use on cpu core (using windows taskmanager)
before typing 'r' everything works
too on the quad core... In this case both gdb and my testcode only use
one cpu core. But this is not
really what I want to do...
So I assume some threading issues here in communication with the
console/terminal from multiple threads...
But why does it work with DOS box and not using mintty/rxvt??? When I
run my code without gdb it runs
well even on the quad core.
Thanks for any help,
Roland
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: 1.5.25: changed dev/ino error with shared drives
Corinna Vinschen wrote: The problem you're reporting should be fixed in Cygwin 1.7. [snip] Please report back in this maling list whether or not that problem is fixed for you. The problem is indeed fixed in Cygwin 1.7. Thank you so much. Cheers, Wagner -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: fstream - problem with reading/writing to file
Greg Chicares wrote: On 2009-02-19 20:33Z, Tim McDaniel wrote: I think you mean C99 7.19.5.3/6, which says output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function and vice versa. The C++ standard refers to the C standard for low-level stuff like this. Thanks for answer. I should look how it is exactly in C++ because fstream::flush() call between read/write does not help. Pavel Kudrna -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange freezes when using gdb (rxvt/mintty but not dos box)
Roland Schwingel wrote: gdb freezes upon execution of the inferior process when used from within mintty/rxvt, but does not freeze when gdb is invoked from a (conventional) bash inside of a windows DOS box. The application I want to debug is compiled for mingw. You're trying to use a Cygwin GDB to cross-debug a MinGW (== plain old win32) application. Dunno if that's completely guaranteed to work, but it probably should for simple programs. So I assume some threading issues here in communication with the console/terminal from multiple threads... Assumption probably wrong. But why does it work with DOS box and not using mintty/rxvt??? Clue here. You are launching a win32 app, from a cygwin app, in a (non-console-based) GUI window. Won't work. Use a console. See discussions around CYGWIN=tty for full details (which, if you had it set, ought to make the crash occur in a console as well as in rxvt/mintty, but isn't anything you can turn off for rxvt and get it working). cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-41
Hi folks, I just uploaded a new Cygwin 1.7 test release, 1.7.0-41. Cygwin 1.7 is a major jump from Cygwin 1.5.x. The list with all changes related to Cygwin 1.5.25 is attached below. Just download http://cygwin.com/setup-1.7.exe and use that setup tool to install Cygwin 1.7. As usual, please report bugs and problems to the mailing list cygwin AT cygwin DOT com. We also have a new User's Guide for 1.7, which is currently located at http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html We also now have new API documentation http://cygwin.com/1.7/cygwin-api/cygwin-api.html And we have a new FAQ, though very likely not quite complete since we still don't know what exactly *is* a FAQ realted to Cygwin 1.7. http://cygwin.com/1.7/faq/faq.html Bug fixes and extensions to the documentation in the form of patches to the source SGML files are much appreciated. The SGML sources are located in the CVS repository under the winsup/doc directory, for example here: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/doc/?cvsroot=src Same goes for Cygwin patches in general, of course. THIS IS STILL A TEST RELEASE. DON'T USE IN PRODUCTION ENVIRONMENTS. What's new in contrast to 1.7.0-40: === - Reworked documentation. - Simplify getting the user's local groups when creating user tokens in calls to setuid(2)/seteuid(2)/setreuid(2). This should (hopefully) speed up logons in large AD environments. - Add the open(2) flags O_DIRECTORY, O_EXEC and O_SEARCH per POSIX-1.2008. - Export new functions: mbsnrtowcs, open_wmemstream, reallocf, wcsnlen, wcsnrtombs, wcstod, wcstof, wcstoimax, wcstoumax Bugfixes: = - Handle the cygdrive default mount options more consistent. - Fix a bug where newlib and Cygwin would have a different idea what the processes' environment is. Known Bugs: === - A long standing problem in newlib's setlocale() function disallows to read the locale specific LC_* environment variables. I created a fix, but it's not in newlib yet. FAQ: - Q: How do I know that I'm running Cygwin 1.7.0-41? A: The `uname -v' command prints 2009-02-20 17:20 Have fun, Corinna Here's the list of user-visible changes in 1.7.0 related to 1.5.25: OS releated changes: - Windows 95, 98 and Me are not supported anymore. The new DLL will not run on any of these systems. File Access related changes: - Mount points are no longer stored in the registry. Use /etc/fstab and /etc/fstab.d/$USER instead. Mount points created with mount(1) are only local to the current session and disappear when the last Cygwin process in the session exits. - PATH_MAX is now 4096. Internally, path names can be as long as the underlying OS can handle (32K). - UTF-8 filenames are supported now. So far, this requires to set the environment variable CYGWIN to contain codepage:utf8. but this will likely disappear at one point. The setting of $LANG or $LC_CTYPE will be used instead. - struct dirent now supports d_type, filled out with DT_REG or DT_DIR. All other file types return as DT_UNKNOWN for performance reasons. - The CYGWIN environment variable options ntsec and smbntsec have been replaced by the per-mount option acl/noacl. - The CYGWIN environment variable option ntea has been removed without substitute. - The CYGWIN environment variable option check_case has been removed in favor of real case-sensitivity on file systems supporting it. - Creating filenames with special DOS characters '', '*', ':', '', '', '|' is supported. - Creating files with special DOS device filename components (aux, nul, prn) is supported. - File name are case sensitive if the OS and the underlying file system supports it. Works on NTFS and NFS. Does not work on FAT and Samba shares. Requires to change a registry key (see the user's guide). Can be switched off on a per-mount base. - Due to the above changes, managed mounts have been removed. - Incoming DOS paths are always handled case-insensitive and get no POSIX permission, as if they are mounted with noacl,posix=0 mount flags. - unlink(2) and rmdir(2) try very hard to remove files/directories even if they are currently accessed or locked. This is done by utilizing the hidden recycle bin directories and marking the files for deletion. - rename(2) rewritten to be more POSIX conformant. - Add st_birthtim member to struct stat. - File locking is now advisory, not mandatory anymore. The fcntl(2) and the new lockf(2) APIs create and maintain locks with POSIX semantics, the flock(2) API creates and maintains locks with BSD semantics. POSIX and BSD locks are independent of each other. - Implement atomic O_APPEND mode. -
Re: SSH V.5.1 with Cygwin1.dll 1.7.0: Very large logon times...
On Feb 20 16:20, Corinna Vinschen wrote: On Feb 20 15:48, carsten.porz...@spb.de wrote: It ist very difficult to put in debug statements at the right places within the sourcecode because of the complexity of the programs. But we have just found out these new facts: - We copied our productive Active Directory database into a test environment + AD database contained 8700 users, 6000 groups, 9600 computers + part of this test network are only three computers: root domain controller, domain controller, member server + problem of large logon time could also be seen in this copied environment - In the next step we deleted most of the Active Directory objects + After this deletion process AD database contains only 278 users, 784 groups and 32 computers + SSH login takes only 1 sec. for login With theses informations it should be possible for you developers to adjust the situation. Increase the number of your Active Directory objects, and you will probably see that the logon time will also increase! Anything within your ssh logon process takes more time the bigger the Active Directory database is. I just discussed this problem and my code with somebody having more insight into this AD stuff. I now have a hunch what I could do to fix this bad timing problem. Stay tuned. Please try the latest 1.7.0 incarnation: http://cygwin.com/ml/cygwin-announce/2009-02/msg00018.html This hopefully fixes the above problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange freezes when using gdb (rxvt/mintty but not dos box)
On Fri, Feb 20, 2009 at 04:45:00PM +, Dave Korn wrote: Roland Schwingel wrote: gdb freezes upon execution of the inferior process when used from within mintty/rxvt, but does not freeze when gdb is invoked from a (conventional) bash inside of a windows DOS box. The application I want to debug is compiled for mingw. You're trying to use a Cygwin GDB to cross-debug a MinGW (== plain old win32) application. Dunno if that's completely guaranteed to work, but it probably should for simple programs. Yes, it should work fine. So I assume some threading issues here in communication with the console/terminal from multiple threads... Assumption probably wrong. But why does it work with DOS box and not using mintty/rxvt??? Clue here. You are launching a win32 app, from a cygwin app, in a (non-console-based) GUI window. Won't work. Use a console. See discussions around CYGWIN=tty for full details (which, if you had it set, ought to make the crash occur in a console as well as in rxvt/mintty, but isn't anything you can turn off for rxvt and get it working). Right on, Dave. There are all sorts of potential problems with using a cygwin pty/tty and a mingw process. So: what he said. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem Adding Membership Multicast Errno 22
On Feb 20 13:48, Corinna Vinschen wrote:
On Feb 20 04:05, victhor_1983 wrote:
status= setsockopt(Descriptor, IPPROTO_IP, IP_ADD_MEMBERSHIP, Multic,
sizeof(Multic));
if (status0){
printf(Fallo al añadir el grupo de Multicast, codigo %i\n,
errno);
}
I'm sorry, I can't tell you why this doesn't work. Cygwin's setsockopt
function is basically just a shim between application and Winsock's
setsockopt call. It only performs special actions on a very limited
set of options, only two actually: (SOL_SOCKET, SO_REUSEADDR) and
(IPPROTO_IP, IP_TOS). I'm also quite multicast illiterate. Is it
possible that you have to use the IP_MULTICAST_IF option on Windows
before you can use IP_ADD_MEMBERSHIP?!?
Here's one idea: Is it possible that your application includes
winsock.h? If so, don't do that, use the POSIX headers for socket and
ip stuff. Winsock.h is the WInsock specific header file for
applications using the old Winsock 1.x API. In that API,
IP_ADD_MEMBERSHIP is defined as the value 5.
However, the newer Winsock 2.x API, which is used by Cygwin under the
hood as well, defines IP_ADD_MEMBERSHIP as the value 12. So, if there's
any chance that you're including the winsock.h header, remove it and
only use Cygwin's header files, not the Winsock specifc header files.
Thanks for the idea. Yes, I read something similar in a post related to
multicast in this same forum. However, I am not using windows headers, since
I migrated my code from Ubuntu. I also tried defining the value of
IP_ADD_MEMBERSHIP myself, and it checks with value 12, just as you say.
However, I still get the error.
I do the binding right after the setsockopt, but the result is the same if I
do it before. In both cases, the setsockopt() returns an errno=22, and the
binding returns an errno=125. It is a real mistery, because I know the IP
interface I associate to the multicast group exists and works, since I use
it without a problem in unicast sockets in other programs.
I have the feeling the problem is in the struct ip_mreg Multic or in
sizeof(Multic), but I cannot figure out why or how to solve it. I will keep
looking into it. Just in case, I post the whole code here:
#include string.h
#include stdio.h
#include netinet/in.h
#include sys/socket.h
#include errno.h
#include sys/time.h
#include pthread.h
#include sys/types.h
#include unistd.h
#define SIGALRM 14
void salir()
{
exit(NULL);
}
int main (void)
{
int Descriptor, Descriptor2, status;
struct sockaddr_in Direccion, Direccion2;
unsigned short Puerto;
struct ip_mreq Multic;
Descriptor=socket(AF_INET,SOCK_DGRAM,0);
Puerto=12100;
Direccion.sin_family=AF_INET;
Direccion.sin_port=htons(Puerto);//Puerto-s_port;
Direccion.sin_addr.s_addr=inet_addr(224.0.22.1);//(138.4.32.34);
memset((Direccion.sin_zero),'\0',8);
Direccion2.sin_family=AF_INET;
Direccion2.sin_port=htons(Puerto);//Puerto-s_port;
Direccion2.sin_addr.s_addr=htonl(INADDR_ANY);//inet_addr(138.4.32.34);//(138.4.32.34);
memset((Direccion2.sin_zero),'\0',8);
status=bind(Descriptor,(struct sockaddr *)Direccion, sizeof(struct
sockaddr));
if (status0){
printf(Fallo al realizar binding, codigo %i\n, errno);
}
Multic.imr_multiaddr.s_addr=inet_addr(224.0.22.1);
Multic.imr_interface.s_addr=htonl(INADDR_ANY);//inet_addr(138.4.32.34);
status= setsockopt(Descriptor, IPPROTO_IP, IP_ADD_MEMBERSHIP, Multic,
sizeof(Multic));
if (status0){
printf(Fallo al añadir el grupo de Multicast, codigo %i\n,
errno);
}
signal (SIGINT, salir);
signal (SIGALRM, SIG_IGN);
return 0;
}
Maybe the error is in some other part. Thanks again for your insight and
your help.
Victor
--
View this message in context:
http://www.nabble.com/Problem-Adding-Membership-Multicast-Errno-22-tp22119431p22123508.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Problem Adding Membership Multicast Errno 22
Hi, thanks for your answer There definately is as I use it daily. I'm not sure the cause of the EINVAL, but without a bind, it definately won't work on Windows: I have tried binding before and after setsockopt(), but the result is the same. I get errno=22 for setsockopt() and errno=125 for bind(). I assume you aren't trying to define IP_ADD_MEMBERSHIP yourself? No, but I have tried and I know IP_ADD_MEMBERSHIP equals to 12 in my system. However, I still get errno=22 when I use 12 instead of IP_ADD_MEMBERSHIP. Are you sure the interface IP exists and is up with a link on your test system? Yes, I have used in unicast sockets and it works like a charm. Perhaps the problem lies in the struct ip_mreg Multic or in sizeof(Multic) parameters, but I cannot figure out the reason or how to solve it. Victor -- View this message in context: http://www.nabble.com/Problem-Adding-Membership-Multicast-Errno-22-tp22119431p22123866.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange freezes when using gdb (rxvt/mintty but not dos box)
On Feb 20 12:13, Christopher Faylor wrote: On Fri, Feb 20, 2009 at 04:45:00PM +, Dave Korn wrote: Roland Schwingel wrote: gdb freezes upon execution of the inferior process when used from within mintty/rxvt, but does not freeze when gdb is invoked from a (conventional) bash inside of a windows DOS box. [...] But why does it work with DOS box and not using mintty/rxvt??? Clue here. You are launching a win32 app, from a cygwin app, in a (non-console-based) GUI window. Won't work. Use a console. See discussions around CYGWIN=tty for full details (which, if you had it set, ought to make the crash occur in a console as well as in rxvt/mintty, but isn't anything you can turn off for rxvt and get it working). Right on, Dave. There are all sorts of potential problems with using a cygwin pty/tty and a mingw process. So: what he said. What about the new-console option in Cygwin's GDB to create the inferior process in a new Console window? Shouldn't that help here, as long as the pty is actually running in the local GUI session. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Lftp hang while executing batch file
Hi folks, I found that the Version 3.7.6-3 have the problem executing batchfiles. After upgrading from 3.7.6-1 my script does not longer work. I started lftp -f batchfile where in the batchfile the connection to the server And some action is done. It looks like that lftp hang while it tries to connect. I downgraded to 3.7.6-1 an everything works fine. May be someone can reproduce and fix the problem. Thanks for the report, but in order for us to reproduce the problem, wouldn't you expect to have to post the script? Please do that. The difference between 3.7.6-1 and -3 was very small-- all I did was remove a single file, /usr/lib/charset.alias, that's already provided by gettext. Can you tell me, (1) do you have /usr/lib/charset.alias on your host, and (2) do you have gettext installed? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange freezes when using gdb (rxvt/mintty but not dos box)
On Fri, Feb 20, 2009 at 06:26:17PM +0100, Corinna Vinschen wrote: On Feb 20 12:13, Christopher Faylor wrote: On Fri, Feb 20, 2009 at 04:45:00PM +, Dave Korn wrote: Roland Schwingel wrote: gdb freezes upon execution of the inferior process when used from within mintty/rxvt, but does not freeze when gdb is invoked from a (conventional) bash inside of a windows DOS box. [...] But why does it work with DOS box and not using mintty/rxvt??? Clue here. You are launching a win32 app, from a cygwin app, in a (non-console-based) GUI window. Won't work. Use a console. See discussions around CYGWIN=tty for full details (which, if you had it set, ought to make the crash occur in a console as well as in rxvt/mintty, but isn't anything you can turn off for rxvt and get it working). Right on, Dave. There are all sorts of potential problems with using a cygwin pty/tty and a mingw process. So: what he said. What about the new-console option in Cygwin's GDB to create the inferior process in a new Console window? Shouldn't that help here, as long as the pty is actually running in the local GUI session. I don't think that resets stdin/stdout for the inferior process so I doubt that it would help. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange freezes when using gdb (rxvt/mintty but not dos box)
On Feb 20 12:45, Christopher Faylor wrote: On Fri, Feb 20, 2009 at 06:26:17PM +0100, Corinna Vinschen wrote: On Feb 20 12:13, Christopher Faylor wrote: On Fri, Feb 20, 2009 at 04:45:00PM +, Dave Korn wrote: Roland Schwingel wrote: gdb freezes upon execution of the inferior process when used from within mintty/rxvt, but does not freeze when gdb is invoked from a (conventional) bash inside of a windows DOS box. [...] But why does it work with DOS box and not using mintty/rxvt??? Clue here. You are launching a win32 app, from a cygwin app, in a (non-console-based) GUI window. Won't work. Use a console. See discussions around CYGWIN=tty for full details (which, if you had it set, ought to make the crash occur in a console as well as in rxvt/mintty, but isn't anything you can turn off for rxvt and get it working). Right on, Dave. There are all sorts of potential problems with using a cygwin pty/tty and a mingw process. So: what he said. What about the new-console option in Cygwin's GDB to create the inferior process in a new Console window? Shouldn't that help here, as long as the pty is actually running in the local GUI session. I don't think that resets stdin/stdout for the inferior process so I doubt that it would help. Indeed, that could be a problem. I was just wondering if this win32 app doesn't actually opens the console by itself and uses functions like WriteConsole. That could explain why it hangs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem Adding Membership Multicast Errno 22
On Fri, 20 Feb 2009, victhor_1983 wrote: Direccion.sin_addr.s_addr=inet_addr(224.0.22.1);//(138.4.32.34); Binding to a multicast address doesn't work on windows. You must bind to INADDR_ANY. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
openssh question
When I install openssh 5.1-10 from source and run the cygwin post install everything works fine. But if i install to a directory then run cygwin post install and tar the contents of the folder with the following tar cvjfT my-openssh-5.1.-10.tar.bz2 - (found in /usr/share/doc/Cygwin/openssh.README) then take that archive to another machine unpack the archive with tar --owner= accountname --overwrite -xvpf my-openssh-5.1-10.tar.bz2. When i try to start the service or manually run sshd -D it complains about the permissions on /var/empty (owned by SYSTEM).i verified on the working machine(from source) all permissions on folders and files. They are the same. I tried setting acl with setfacl and chown to SYSTEM and the the user(admin account), again they are the exact same permissions. But still the same result. I have tried the same process several times. Anyone have any ideas what is going wrong? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
path to graphics.h
Hello, I wonder where is this lib located? I have installed cygwin under d:\cygwin directory. Thank you for your helps. Huan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: path to graphics.h
H Le wrote: Hello, I wonder where is this lib located? I have installed cygwin under ^^^ You mean header or include file. d:\cygwin directory. Thank you for your helps. I can't answer your question directly but I think I can help you answer it. From the main Cygwin page, first line: Cygwin is a Linux-like environment for Windows. Where on a Linux machine or from what Linux package would you expect to find graphics.h? If you can't answer that, then perhaps an easier question is why would you expect to find graphics.h with Cygwin? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] rebaseall doesn't solve the problem
For the last several days I have been having a terrible time with the old 2 [main] perl 3620 C:\cygwin-1.7\bin\perl.exe: *** fatal error - unable to remap C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Cwd\Cwd.dll to same address as parent(0x86) != 0x14E 5 [main] perl 3636 child_info::sync: wait failed, pid 3620, Win32 error 183 418 [main] perl 3636 fork: child 3620 - died waiting for dll loading, errno 11 issue. It's being triggered when running the autotools (so the libtool testsuite is a nightmare, as is trying to package anything using cygport for 1.7) -- and the culprit is ALWAYS Cwd.dll. I've tried rebasing to various addresses (0x7000, 0x6800, 0x650) but to no avail. Using process explorer, I find that for SOME reason, even in the parent perl, the Cwd.dll (one of the DLLs shipped with perl, in /usr/lib/perl5/5.10/i686-pc-cygwin/auto/Cwd/Cwd.dll) is being loaded in a strange location: Image Base: 0x5d6a Location in Parent: 0x0086 Location in Child : 0x014E I can't see that there is any conflict at the image base location of 0x5d6a, so I'm not sure why, in the parent, Cwd.dll was loaded that low. However, the low memory region is rife with conflict, and in fact, in the child: C:\Windows\system32\locale.nls image base: 0x0 mapped location: 0x0096 mapped size: 0x0037F000 which means that locale.nls extends all the way down to 0x005E1000, so Cwd.dll can't go at 0x0086. Rebasing won't solve this problem, because Cwd.dll is NOT being loaded at the rebased (0x5d6a) location even tho, as far as I can tell, there is no conflict there. Instead, it's being loaded at a traffic heavy location for no good reason that I can see -- and I keep getting hit by passing cars. Help? -- Chuck PS. The full output of sysinternal's listdll for the parent (first) and child (second) is below. But first: in the parent, there are three items that have an image base of 0x0, so they are relocated, in addition to Cwd.dll: name mapped to mapped size image base locale.nls 0x1999 0x0037f0000x0 locale.nls 0x00a1 0x0037f0000x0 oleaccrc.dll 0x008d 0x10000x0 Cwd.dll 0x0086 0x80000x5d6a In the (partially loaded) child, there is as yet only one copy of locale.nls loaded, and the Cwd.dll that are relocated from their actual image base: name mapped to mapped size image base locale.nls 0x0096 0x0037f0000x0 Cwd.dll 0x014e 0x80000x5d6a In each case, all of the other dlls are loaded at their actual image base and are not relocated. ListDLLs v2.25 - DLL lister for Win9x/NT Copyright (C) 1997-2004 Mark Russinovich Sysinternals - www.sysinternals.com -- perl.exe pid: 4948 Command line: C:\cygwin-1.7\bin\perl.exe -w /usr/bin/autom4te-2.63 --language=m4sh -B libltdl/config libltdl/config/ltmain.m4sh BaseSize Version Path 0x5206 0x8000C:\cygwin-1.7\bin\perl.exe 0x77a8 0x127000 6.00.6001.18000 C:\Windows\system32\ntdll.dll 0x763a 0xdb000 6.00.6001.18000 C:\Windows\system32\kernel32.dll 0x6100 0x30 1007.00.. C:\cygwin-1.7\bin\cygwin1.dll 0x76c1 0xc6000 6.00.6001.18000 C:\Windows\system32\ADVAPI32.DLL 0x76ab 0xc2000 6.00.6001.18051 C:\Windows\system32\RPCRT4.dll 0x5d76 0x184000 C:\cygwin-1.7\bin\cygperl5_10.dll 0x64ed 0x7000C:\cygwin-1.7\bin\cygcrypt-0.dll 0x7563 0x3b000 6.00.6001.18000 C:\Windows\system32\rsaenh.dll 0x77c1 0xaa000 7.00.6001.18000 C:\Windows\system32\msvcrt.dll 0x5d68 0xd000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Data\Dumper\Dumper.dll 0x5d05 0x9000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\IO\IO.dll 0x5d13 0x7000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Fcntl\Fcntl.dll 0x5cee 0x1c000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\POSIX\POSIX.dll 0x0086 0x8000 C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Cwd\Cwd.dll 0x7613 0x2c000 6.00.6001.18000 C:\Windows\system32\apphelp.dll 0x73fd 0x32000 6.00.6001.18000 C:\Windows\system32\winmm.dll 0x7630 0x9d000 6.00.6001.18000 C:\Windows\system32\USER32.dll 0x7678 0x4b000 6.00.6001.18159 C:\Windows\system32\GDI32.dll 0x7648 0x144000 6.00.6001.18000 C:\Windows\system32\ole32.dll 0x767d 0x8d000 6.00.6001.18000 C:\Windows\system32\OLEAUT32.dll 0x7468 0x39000 4.02.5406. C:\Windows\system32\OLEACC.dll 0x7676 0x1e000 6.00.6001.18000 C:\Windows\system32\IMM32.DLL 0x76d1 0xc8000 6.00.6001.18000 C:\Windows\system32\MSCTF.dll 0x77cd 0x90006.00.6001.18000 C:\Windows\system32\LPK.DLL 0x768e 0x7d000 1.626.6001.18000 C:\Windows\system32\USP10.dll 0x6c1b 0x50008.00..0223
[1.7] makeinfo: too many open files
I ran into the following problem building libtool under cygwin-1.7 (makeinfo from texinfo-4.8a-1): makeinfo -I doc -I /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc -o /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.info /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.texi /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.texi:5485: @include `PLATFORMS': Too many open files. /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.texi:6191: @include `fdl.texi': Too many open files. makeinfo: Removing output file `/usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.info' due to errors; use --force to preserve. When using the same version of makeinfo under cygwin-1.5, there are no problems. I see that Eric asked about (the same?) problem over on bug-texinfo, but I don't see any resolution. It looks like a cygwin-1.7 problem, not a texinfo problem, to me... http://lists.gnu.org/archive/html/bug-texinfo/2009-01/msg00013.html Eric, did anything ever come of this? -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] Updated: cygwin-1.7.0-41
Hi folks, I just uploaded a new Cygwin 1.7 test release, 1.7.0-41. Cygwin 1.7 is a major jump from Cygwin 1.5.x. The list with all changes related to Cygwin 1.5.25 is attached below. Just download http://cygwin.com/setup-1.7.exe and use that setup tool to install Cygwin 1.7. As usual, please report bugs and problems to the mailing list cygwin AT cygwin DOT com. We also have a new User's Guide for 1.7, which is currently located at http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html We also now have new API documentation http://cygwin.com/1.7/cygwin-api/cygwin-api.html And we have a new FAQ, though very likely not quite complete since we still don't know what exactly *is* a FAQ realted to Cygwin 1.7. http://cygwin.com/1.7/faq/faq.html Bug fixes and extensions to the documentation in the form of patches to the source SGML files are much appreciated. The SGML sources are located in the CVS repository under the winsup/doc directory, for example here: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/doc/?cvsroot=src Same goes for Cygwin patches in general, of course. THIS IS STILL A TEST RELEASE. DON'T USE IN PRODUCTION ENVIRONMENTS. What's new in contrast to 1.7.0-40: === - Reworked documentation. - Simplify getting the user's local groups when creating user tokens in calls to setuid(2)/seteuid(2)/setreuid(2). This should (hopefully) speed up logons in large AD environments. - Add the open(2) flags O_DIRECTORY, O_EXEC and O_SEARCH per POSIX-1.2008. - Export new functions: mbsnrtowcs, open_wmemstream, reallocf, wcsnlen, wcsnrtombs, wcstod, wcstof, wcstoimax, wcstoumax Bugfixes: = - Handle the cygdrive default mount options more consistent. - Fix a bug where newlib and Cygwin would have a different idea what the processes' environment is. Known Bugs: === - A long standing problem in newlib's setlocale() function disallows to read the locale specific LC_* environment variables. I created a fix, but it's not in newlib yet. FAQ: - Q: How do I know that I'm running Cygwin 1.7.0-41? A: The `uname -v' command prints 2009-02-20 17:20 Have fun, Corinna Here's the list of user-visible changes in 1.7.0 related to 1.5.25: OS releated changes: - Windows 95, 98 and Me are not supported anymore. The new DLL will not run on any of these systems. File Access related changes: - Mount points are no longer stored in the registry. Use /etc/fstab and /etc/fstab.d/$USER instead. Mount points created with mount(1) are only local to the current session and disappear when the last Cygwin process in the session exits. - PATH_MAX is now 4096. Internally, path names can be as long as the underlying OS can handle (32K). - UTF-8 filenames are supported now. So far, this requires to set the environment variable CYGWIN to contain codepage:utf8. but this will likely disappear at one point. The setting of $LANG or $LC_CTYPE will be used instead. - struct dirent now supports d_type, filled out with DT_REG or DT_DIR. All other file types return as DT_UNKNOWN for performance reasons. - The CYGWIN environment variable options ntsec and smbntsec have been replaced by the per-mount option acl/noacl. - The CYGWIN environment variable option ntea has been removed without substitute. - The CYGWIN environment variable option check_case has been removed in favor of real case-sensitivity on file systems supporting it. - Creating filenames with special DOS characters '', '*', ':', '', '', '|' is supported. - Creating files with special DOS device filename components (aux, nul, prn) is supported. - File name are case sensitive if the OS and the underlying file system supports it. Works on NTFS and NFS. Does not work on FAT and Samba shares. Requires to change a registry key (see the user's guide). Can be switched off on a per-mount base. - Due to the above changes, managed mounts have been removed. - Incoming DOS paths are always handled case-insensitive and get no POSIX permission, as if they are mounted with noacl,posix=0 mount flags. - unlink(2) and rmdir(2) try very hard to remove files/directories even if they are currently accessed or locked. This is done by utilizing the hidden recycle bin directories and marking the files for deletion. - rename(2) rewritten to be more POSIX conformant. - Add st_birthtim member to struct stat. - File locking is now advisory, not mandatory anymore. The fcntl(2) and the new lockf(2) APIs create and maintain locks with POSIX semantics, the flock(2) API creates and maintains locks with BSD semantics. POSIX and BSD locks are independent of each other. - Implement atomic O_APPEND mode. -
