Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
Hi! Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF I've made a new version of binutils available for download. This is CF just a refresh from sources.redhat.com. A notable change is the CF addition of Egor Duda's --enable-runtime-pseudo-reloc option which CF allows almost transparent linking of dll's without the need of a def CF file. However, this option requires functionality in the cygwin DLL CF which is not yet present. Stay tuned. Ok, it's time to revive a discussion about implementation of pseudo-relocations in runtime. So far, there were 3 propositions: 1. Implement everything in application (in crt0.o) Benefits: Will work with any version of cygwin1.dll. All problems with lack of support from runtime are detected during application linking. (Possibly) common code with mingw. Drawbacks: Will require rebuilding application in case we'll want change something. 2. Implement everything in cygwin1.dll. In this case application is about to have an external reference to _pei386_runtime_relocator. Benefits: Easy to change relocation semantics without relinking application. Drawbacks: GUI window popping up when new application is loaded with old runtime. Lack of support is detected only at application startup. 3. Implement actual relocation in dll, and call it from crt0 via cygwin_internal(). Check dll api version and print error message if runtime is too old. Benefits: Easy to change relocation semantics without relinking application. Drawbacks: Lack of support is detected only at application startup. Question: How can one distinguish console application from GUI one? What is the best wording for the error message? My own preference list (from most preferable to least preferable) is: 1st, then 3rd, then 2nd. Comments? Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
sysvinit initscripts ready for upload ? was Re: Pending packagesstatus
4. sysvinit version: 2.84-2 6. initscripts version: 0.9-1 It seems like these two are ready to be released - is there any reason that they are still not on sourceware ? Is it OK to upload them ?
Re: [ANNOUNCEMENT] Updated: binutils-20021117-1
--- egor duda [EMAIL PROTECTED] wrote: Hi!
Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote:
CF I've made a new version of binutils available for download. This is
CF just a refresh from sources.redhat.com. A notable change is the
CF addition of Egor Duda's --enable-runtime-pseudo-reloc option which
CF allows almost transparent linking of dll's without the need of a def
CF file. However, this option requires functionality in the cygwin DLL
CF which is not yet present. Stay tuned.
Ok, it's time to revive a discussion about implementation of
pseudo-relocations in runtime. So far, there were 3 propositions:
1. Implement everything in application (in crt0.o)
Benefits: Will work with any version of cygwin1.dll. All problems with
lack of support from runtime are detected during application linking.
(Possibly) common code with mingw.
Drawbacks: Will require rebuilding application in case we'll want
change something.
If mingw wants it, mingw will probably have to implement as (1) in crt2.o.
{Will it need to be in mingw's dllcrt2.o, also, for dll's that auto-import from
another dll?) I'm guessing you want it as an option for -mno-cygwin.
Danny
http://www.yahoo.promo.com.au/hint/ - Yahoo! Hint Dropper
- Avoid getting hideous gifts this Christmas with Yahoo! Hint Dropper!
Re: sysvinit initscripts ready for upload ? was Re: Pending packages status
On Tue, Nov 19, 2002 at 10:56:48AM +0100, Pavel Tsekov wrote: 4. sysvinit version: 2.84-2 6. initscripts version: 0.9-1 It seems like these two are ready to be released - is there any reason that they are still not on sourceware ? Is it OK to upload them ? AFAICS, yes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: sysvinit initscripts ready for upload ? was Re: Pending packagesstatus
4. sysvinit version: 2.84-2 6. initscripts version: 0.9-1 Uploaded.
Re: Detecting NetworkSimplicity in setup.exe
On Mon, 2002-11-18 at 12:01, Max Bowsher wrote: I've just installed the latest version of NetworkSimplicity (renaming my Cygwin registry keys first). I propose a 3-level system for detecting problematical mount tables: When NetworkSimplicity is installed, setup can simply look for OpenSSH on Windows * in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\. In this case, warn the user that Cygwin and NetworkSimplicity are mutually incompatible (perhaps link to a webpage with a detailed explanation?), and terminate the install. Hmm, I'm not keen on this one. It would be nice to coexist. As a fallback method, check the mount table mount table with the following characteristic: /bin == /ssh == /usr/bin == /usr/lib == /usr/local/bin == /usr/local/etc This particular odd layout is unique enough to assume that NetworkSimplicity was installed, but has been uncleanly removed. Therefore display a message explaining that the mount table is left over from a NetworkSimplicity install, and offer to either wipe the mount table and recreate it, or exit setup. Yep, if N/S is not there, cleaning up is appropriate. Lastly, as a final contingency, check for /bin == /lib or /usr/bin == /usr/lib. In that case, warn, and offer to revert the mount table to Cygwin defaults, or continue. Agreed. Perhaps, when setup is doing an update rather than an initial install, behaviour should be more relaxed - for example, don't exit setup, just shout loudly. Nyah, just make a command option to ignore 'insane mount tables'. That gives the know-it-alls a knob to twist. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: Detecting NetworkSimplicity in setup.exe
Robert Collins [EMAIL PROTECTED] wrote: On Mon, 2002-11-18 at 12:01, Max Bowsher wrote: I've just installed the latest version of NetworkSimplicity (renaming my Cygwin registry keys first). I propose a 3-level system for detecting problematical mount tables: When NetworkSimplicity is installed, setup can simply look for OpenSSH on Windows * in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\. In this case, warn the user that Cygwin and NetworkSimplicity are mutually incompatible (perhaps link to a webpage with a detailed explanation?), and terminate the install. Hmm, I'm not keen on this one. It would be nice to coexist. We can't, because of the two cygwin1.dlls == bad things. problem. So, basically NetworkSimplicity would have to start using a custom build of cygwin, with all shared mem ids, registry paths, etc, changed. I don't see any problem with being mutually exclusive, though. If someone wants Cygwin, they don't need NetworkSimplicity. ( Better still would be for NetworkSimplicity to metamorphose from a binary distribution to a HOWTO ) Max.
Re: Detecting NetworkSimplicity in setup.exe
Max Bowsher [EMAIL PROTECTED] wrote: I don't see any problem with being mutually exclusive, though. If someone wants Cygwin, they don't need NetworkSimplicity. ( Better still would be for NetworkSimplicity to metamorphose from a binary distribution to a HOWTO ) Mark Bradshaw [EMAIL PROTECTED] wrote: http://netsim.ibforums.com/index.php?act=STf=1t=194 The third post shows the problem. People don't know where to go once they're done with the installer. OK... so wouldn't a (*very* small) HOWTO solve that? Max.
Re: Detecting NetworkSimplicity in setup.exe
If a small howto would fix the problem then I think Mike Erdeley's would've fixed it, but it hasn't. - Original Message - From: Max Bowsher [EMAIL PROTECTED] To: Mark Bradshaw [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 12:41 PM Subject: Re: Detecting NetworkSimplicity in setup.exe Max Bowsher [EMAIL PROTECTED] wrote: I don't see any problem with being mutually exclusive, though. If someone wants Cygwin, they don't need NetworkSimplicity. ( Better still would be for NetworkSimplicity to metamorphose from a binary distribution to a HOWTO ) Mark Bradshaw [EMAIL PROTECTED] wrote: http://netsim.ibforums.com/index.php?act=STf=1t=194 The third post shows the problem. People don't know where to go once they're done with the installer. OK... so wouldn't a (*very* small) HOWTO solve that? Max.
Re: Detecting NetworkSimplicity in setup.exe
Perhaps I'm misreading Max's intent but I believe he's suggesting that there is more to gain by understanding, categorizing, and finding the solution to users' problems with Cygwin's OpenSSH installation than in trying to generate a different, incompatible installation. Wouldn't at least some of what you've learned about creating your OpenSSH version based on Cygwin be helpful in making the Cygwin installation simpler? Is there a reason not to pursue this goal? Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 12:50 PM 11/19/2002, Mark Bradshaw wrote: If a small howto would fix the problem then I think Mike Erdeley's would've fixed it, but it hasn't. - Original Message - From: Max Bowsher [EMAIL PROTECTED] To: Mark Bradshaw [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 12:41 PM Subject: Re: Detecting NetworkSimplicity in setup.exe Max Bowsher [EMAIL PROTECTED] wrote: I don't see any problem with being mutually exclusive, though. If someone wants Cygwin, they don't need NetworkSimplicity. ( Better still would be for NetworkSimplicity to metamorphose from a binary distribution to a HOWTO ) Mark Bradshaw [EMAIL PROTECTED] wrote: http://netsim.ibforums.com/index.php?act=STf=1t=194 The third post shows the problem. People don't know where to go once they're done with the installer. OK... so wouldn't a (*very* small) HOWTO solve that? Max.
Re: Detecting NetworkSimplicity in setup.exe
Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] wrote: Perhaps I'm misreading Max's intent but I believe he's suggesting that there is more to gain by understanding, categorizing, and finding the solution to users' problems with Cygwin's OpenSSH installation than in trying to generate a different, incompatible installation. Exactly. Wouldn't at least some of what you've learned about creating your OpenSSH version based on Cygwin be helpful in making the Cygwin installation simpler? Is there a reason not to pursue this goal? - And to reply to Mark at the same time: At 12:50 PM 11/19/2002, Mark Bradshaw wrote: If a small howto would fix the problem then I think Mike Erdeley's would've fixed it, but it hasn't. It's out of date, as far as I can see (now even simpler), and not wonderfully easy to find. If it was up to date, and easy to find, then I think it *would* have fixed the problem. Max.
Please refresh/fix tetex-bin/setup.hint [WAS: bug with installingtetex-base 20020911-1]
Nicolai Josuttis [EMAIL PROTECTED] writes: Thanks, in fact cygutils was not even installed! It seems there is a package dependency missing. Ouch. Thanks for the report. It seems that my latest tetex/tetex-bin/setup.hint: http://sources.redhat.com/ml/cygwin-apps/2002-09/msg00150.html didn't get uploaded, it's missing the `cygutils' requires that was added. Could someone please fix this? Where should I send the bug report to (or can you deal with it)? Please send bug reports on Cygwin packages (like this one) to [EMAIL PROTECTED] I tend to ignore bug reports sent to me personally. After installing it all was fine. BTW, is there a list of package contents or an info for each command in which package it is? Unfortunately, I couldn't find such a list. Try: http://cygwin.com/packages Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Please upload new version of curl (7.10.2-1)
Would someone kindly upload a new version of curl to the sourceware mirrors for me? I really apologize for the inconvenience of having to rename the files, but this is the preferred naming scheme of the person who runs the curl website; I've asked to have it changed and he said no. If this is truly a major pain to rename the files, I can upload them to my own personal website too, but I'd rather avoid that if I don't have to do it, as it's a lot more work for me. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The files are available as follows: Binary: http://curl.haxx.se/download/curl-7.10.2-1-cygwin.tar.bz2 Source: http://curl.haxx.se/download/curl-7.10.2-1-cygwin-src.tar.bz2 Devel: http://curl.haxx.se/download/curl-devel-7.10.2-1-cygwin.tar.bz2 As always, I'll need you to remove the -cygwin from the filenames. Please let me know once this has been completed so I can announce it. Thanks, --Kevin
Re: Please refresh/fix tetex-bin/setup.hint [WAS: bug with installing tetex-base 20020911-1]
On Tue, Nov 19, 2002 at 08:09:39PM +0100, Jan Nieuwenhuizen wrote: Nicolai Josuttis [EMAIL PROTECTED] writes: Thanks, in fact cygutils was not even installed! It seems there is a package dependency missing. Ouch. Thanks for the report. It seems that my latest tetex/tetex-bin/setup.hint: http://sources.redhat.com/ml/cygwin-apps/2002-09/msg00150.html didn't get uploaded, it's missing the `cygutils' requires that was added. Could someone please fix this? I've uploaded the newest setup.hint. cgf
Fw: Detecting NetworkSimplicity in setup.exe
Maybe some of it would. I think the problem is that the cygwin installer assumes that you actually know about cygwin and want to install it. I think there's a lot of windows folks who hear about ssh/openssh and want it, but don't know about or want the cygwin environment. They just want to push next a few times and have an openssh server, never mind this bash stuff. I'm not sure you can really fix the cygwin installer, since it's not broken. It's just too general for the task. As I've told Rob I've about reached the end of my interest in doing a separate package. In fact that's been the case for a while, but I'm not sure I have any good input on how to handle this problem in another fashion other than a separate install process. I'd certainly be willing to help if someone has a suggestion. Mark - Original Message - From: Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] To: Mark Bradshaw [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 1:10 PM Subject: Re: Detecting NetworkSimplicity in setup.exe Perhaps I'm misreading Max's intent but I believe he's suggesting that there is more to gain by understanding, categorizing, and finding the solution to users' problems with Cygwin's OpenSSH installation than in trying to generate a different, incompatible installation. Wouldn't at least some of what you've learned about creating your OpenSSH version based on Cygwin be helpful in making the Cygwin installation simpler? Is there a reason not to pursue this goal? Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: Detecting NetworkSimplicity in setup.exe
- Original Message - From: Max Bowsher [EMAIL PROTECTED] To: Mark Bradshaw [EMAIL PROTECTED]; [EMAIL PROTECTED]; Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 2:05 PM Subject: Re: Detecting NetworkSimplicity in setup.exe And to reply to Mark at the same time: At 12:50 PM 11/19/2002, Mark Bradshaw wrote: If a small howto would fix the problem then I think Mike Erdeley's would've fixed it, but it hasn't. It's out of date, as far as I can see (now even simpler), and not wonderfully easy to find. If it was up to date, and easy to find, then I think it *would* have fixed the problem. He's probably in the same boat I am. Not enough time. Corinna would be the ideal person to handle this, being the closest person to it, but I don't think she's at all interested. I might be assuming too much there. Mark
Re: Fw: Detecting NetworkSimplicity in setup.exe
At 05:05 PM 11/19/2002, Mark Bradshaw wrote: Maybe some of it would. I think the problem is that the cygwin installer assumes that you actually know about cygwin and want to install it. I think there's a lot of windows folks who hear about ssh/openssh and want it, but don't know about or want the cygwin environment. They just want to push next a few times and have an openssh server, never mind this bash stuff. I'm not sure you can really fix the cygwin installer, since it's not broken. It's just too general for the task. It's not clear (to me at least) that this is the major hindrance, although I'm willing to be convinced otherwise. Seems to me that the existing Cygwin setup suffices in this respect if there is a step-by-step installation document for those that don't want anything other than what's necessary to run SSH. But I'm sure there's improvements to setup that would make pre-configured Cygwin installations of specific utilities possible too, though that's a future. As I've told Rob I've about reached the end of my interest in doing a separate package. In fact that's been the case for a while, but I'm not sure I have any good input on how to handle this problem in another fashion other than a separate install process. I'd certainly be willing to help if someone has a suggestion. I think the list would benefit from knowing what your installation does and how it configures things. It would also be beneficial to know what are common problems and solutions with your package. Knowing this helps pinpoint general user issues. Is this information you can provide? If so, perhaps someone here can help relieve you of the need to provide your separate installation. ;-) Mark - Original Message - From: Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] To: Mark Bradshaw [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 1:10 PM Subject: Re: Detecting NetworkSimplicity in setup.exe Perhaps I'm misreading Max's intent but I believe he's suggesting that there is more to gain by understanding, categorizing, and finding the solution to users' problems with Cygwin's OpenSSH installation than in trying to generate a different, incompatible installation. Wouldn't at least some of what you've learned about creating your OpenSSH version based on Cygwin be helpful in making the Cygwin installation simpler? Is there a reason not to pursue this goal? Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX # # # # # # # # #
RE: Detecting NetworkSimplicity in setup.exe
Perhaps, when setup is doing an update rather than an initial install, behaviour should be more relaxed - for example, don't exit setup, just shout loudly. Nyah, just make a command option to ignore 'insane mount tables'. That gives the know-it-alls a knob to twist. Rob, PROMISE me that this option gets the long name --ignore-insane-mount-tables. PROMISE ME! ;-) -- Gary R. Van Sickle Brewer. Patriot.
Re: [xfree] Fwd: Re: XDMCP
Try creating a file /etc/X0.hosts. Place the names or ip addresses of any clients which need to connect to the Xserver. Make sure you include localhost so that xwinclip will work. This will bypass xauth for those machines. PapaFox - Original Message - From: Steven Whatley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 3:34 PM Subject: Re: [xfree] Fwd: Re: XDMCP Have you modified Cygwin's /etc/hsots.allow and /etc/hosts.deny files? I'm trying this but no go yet. Later, Steven On Mon, 18 Nov 2002, David Calkins wrote: Well, tried it again to make sure, and if I run XWin *without* the -query option, I can set my DISPLAY to 127.0.0.1:0.0 and then run xhost and it (xhost) works. If I then connect via the VPN to my work's intranet, and then run XWin *with* the -query option, xhost now hangs... argh! I think I'm *very* close to having this work. I just need to convince X to allow my work machine to connect back to my home machine.. Dave I'm seeing the following in /tmp/XWin.log AUDIT: Mon Nov 18 22:22:19 2002: 5924 XWin: client 1 rejected from IP WORKMACHINEIP port 3468 I get a bunch of the above messages in my XWin.log. Sounds like we're both having problems with convincing the X server that we do, in fact, want to allow connections from the work machine. I tried using xhost, but it just hangs if I run it while my X server is running (with the -query option). Anyone know how else I can tell my X server to trust a remote host? Dave Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Archive: http://sources.redhat.com/ml/cygwin-xfree/ List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED], http://sources.redhat.com/ml/#faqs Sender: [EMAIL PROTECTED] Mail-Followup-To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Date: Mon, 18 Nov 2002 20:54:52 -0600 (CST) From: Steven Whatley [EMAIL PROTECTED] X-X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: XDMCP The error I am getting in the ~/.xsessoin-errors is: Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Gtk-WARNING **: cannot open display: :0 Thanks, Steven From: Papa Fox papafox888 at hotmail dot com Date: Mon, 18 Nov 2002 19:23:17 +1100 Subject: Re: XDMCP It looks like the unix login is happening. What's in ~/.xsession-errors? PapaFox - Original Message - From: David Calkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 17, 2002 5:11 AM Subject: XDMCP I'm trying to connect up to a machine at work using XDMCP. My home machine is Win2k + Cygwin + XFree86. I made sure to use the cygwin setup program to get the latest packages. I'm using the -query option to do this, i.e. XWin -depth 32 -engine 4 -fullscreen -refresh 85 -screen 0 1024 768 -query $remotehost I get the login screen, enter my username and password and attempt to login. For some reason, I just get bounced back to the login screen again. I've been unable to get this to work. Any ideas as to what could cause this? -- ___ ((__O\ (___ \ Don't get rattled by Steven Whatley \ \_(___)\O\_/O___- what I say. It's just [EMAIL PROTECTED] \O)\___/my opinion.
Yenilenen noseks filuc
FULL 2002 YAPIMI PORNO VIDEOLAR Sitemize yeni filmler eklendi. Tam metraj, full kalite Yenilenen Kategoriler: AMATEUR ANAL ASIAN LESBIAN Ýyi eðlenceler, http://www.noseks.com id: cygwin-xfree - bvymetpelrtsyaemugqxr-
Fwd: Re: [xfree] Fwd: Re: XDMCP
That did it! I created /etc/X0.hosts and added localhost and my work machine to it. I was able to log in and get the remote CDE session with no problems. :-) Thanks for the tip. Dave Try creating a file /etc/X0.hosts. Place the names or ip addresses of any clients which need to connect to the Xserver. Make sure you include localhost so that xwinclip will work. This will bypass xauth for those machines. PapaFox - Original Message - From: Steven Whatley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 3:34 PM Subject: Re: [xfree] Fwd: Re: XDMCP Have you modified Cygwin's /etc/hsots.allow and /etc/hosts.deny files? I'm trying this but no go yet. Later, Steven On Mon, 18 Nov 2002, David Calkins wrote: Well, tried it again to make sure, and if I run XWin *without* the -query option, I can set my DISPLAY to 127.0.0.1:0.0 and then run xhost and it (xhost) works. If I then connect via the VPN to my work's intranet, and then run XWin *with* the -query option, xhost now hangs... argh! I think I'm *very* close to having this work. I just need to convince X to allow my work machine to connect back to my home machine.. Dave I'm seeing the following in /tmp/XWin.log AUDIT: Mon Nov 18 22:22:19 2002: 5924 XWin: client 1 rejected from IP WORKMACHINEIP port 3468 I get a bunch of the above messages in my XWin.log. Sounds like we're both having problems with convincing the X server that we do, in fact, want to allow connections from the work machine. I tried using xhost, but it just hangs if I run it while my X server is running (with the -query option). Anyone know how else I can tell my X server to trust a remote host? Dave Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Archive: http://sources.redhat.com/ml/cygwin-xfree/ List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED], http://sources.redhat.com/ml/#faqs Sender: [EMAIL PROTECTED] Mail-Followup-To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Date: Mon, 18 Nov 2002 20:54:52 -0600 (CST) From: Steven Whatley [EMAIL PROTECTED] X-X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: XDMCP The error I am getting in the ~/.xsessoin-errors is: Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server Gtk-WARNING **: cannot open display: :0 Thanks, Steven From: Papa Fox papafox888 at hotmail dot com Date: Mon, 18 Nov 2002 19:23:17 +1100 Subject: Re: XDMCP It looks like the unix login is happening. What's in ~/.xsession-errors? PapaFox - Original Message - From: David Calkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 17, 2002 5:11 AM Subject: XDMCP I'm trying to connect up to a machine at work using XDMCP. My home machine is Win2k + Cygwin + XFree86. I made sure to use the cygwin setup program to get the latest packages. I'm using the -query option to do this, i.e. XWin -depth 32 -engine 4 -fullscreen -refresh 85 -screen 0 1024 768 -query $remotehost I get the login screen, enter my username and password and attempt to login. For some reason, I just get bounced back to the login screen again. I've been unable to get this to work. Any ideas as to what could cause this? -- ___ ((__O\ (___ \ Don't get rattled by Steven Whatley \ \_(___)\O\_/O___- what I say. It's just [EMAIL PROTECTED] \O)\___/my opinion.
have cygwin/XFree86 running ... but need help connecting remotely
Greetings ... Okay, I know I should be able to understand this from the documentation, but I don't ... I've installed CygwinXFree86 on my windows box ... I can double-click the shortcut on the desktop to run the program, and I can run startxwin.sh, startx, etc. ... but how do i connect to a remote box? I want to connect to a linux box on my network, and I'm puzzled about how to make that happen. Can anyone provide this elementary help to me? Thanks in advance, kenn
Re: have cygwin/XFree86 running ... but need help connecting remotely
On Wed, 20 Nov 2002 1:59 am, Kenn Murrah wrote: Greetings ... Okay, I know I should be able to understand this from the documentation, but I don't ... I've installed CygwinXFree86 on my windows box ... I can double-click the shortcut on the desktop to run the program, and I can run startxwin.sh, startx, etc. ... but how do i connect to a remote box? I want to connect to a linux box on my network, and I'm puzzled about how to make that happen. Can anyone provide this elementary help to me? Depends on what type of connection you want? Did you just want to ssh into the box, or did you want to set up XDMCP. If you just want to ssh, then type $ ssh [EMAIL PROTECTED] If you want to ssh and forward the X session over ssh, then $ ssh -X [EMAIL PROTECTED] If you want XDMCP, then I would suggest reading the Linux XDMCP howto. http://www.tldp.org/HOWTO/XDMCP-HOWTO/ Also see the Cygwin-XFree86 FAQ etc. http://xfree86.cygwin.com/docs/ Cheers, Rasjid.
RE: xwinclip test 6 hacked to leave selection untouched
Robert, I have been trying to figure out how your patch to xwinclip works. In particular, I was wondering how it got notification that the selection had changed when it was owned by another window. I can now sum up your changes in a sentence: XA_CUT_BUFFER0 is watched for changes and the selection is copied to the Windows clipboard whenever cut buffer 0 is changed. That may not be a completely clean way to solve the problem forever, but it does work, at the very least. Harold
Direction of xwinclip
Chris [Twiner], I have finally had a chance to look at your changes to xwinclip. I now remember what it was that I did not like: Ownership of the X selection is grabbed when XWin.exe loses focus. Is that correct? Robert's method of watching for changes in XA_CUT_BUFFER0 might be hack, but I think it is probably closer to what other X Servers for Windows are doing, as those other X Server do not grab ownership of the X selection when they lose the focus. Have you got any objections to watching for changes in XA_CUT_BUFFER0 as a signal that we should request another copy of the X selection? If we decide to go with the XA_CUT_BUFFER0 hack, then there will probably need to be only one more release of xwinclip. After that we can concentrate on integrating the clipboard support into XWin.exe. By the way... I like the setjmp/longjmp stuff... I thought it was two assembly language instructions that were used. Imagine my surprise when I saw setjmp.h and realized that setjmp and longjmp were (used like) functions. That is a heck of a lot easier than I had thought it would be. Thanks for your contributions Chris. Harold
winsup/cygwin ChangeLog net.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2002-11-19 00:01:50 Modified files: cygwin : ChangeLog net.cc Log message: * net.cc: Sprinkle sigframes throughout. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.1598r2=1.1599 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/net.cc.diff?cvsroot=uberbaumr1=1.130r2=1.131
Re: ls problem
Hi Igor, I tried disabling ntsec and ls -l is still slow. I'm using 1.3.15-cygwin-1-3-15-1. ls -l and ls -ln takes almost the same amount of time.On a directory with 3 short text files, the difference, when I timed ls -l and ls -b, is still considerable. fcarlo@ZEUS~ $ time ls -b a b test real0m0.024s user0m0.030s sys 0m0.015s fcarlo@ZEUS ~ $ time ls -l total 11 -rw-r--r--1 fcarlo None5 Nov 19 13:58 a -rw-r--r--1 fcarlo None5 Nov 19 13:58 b -rw-r--r--1 fcarlo None 8283 Nov 19 13:59 test real0m1.819s user0m0.030s sys 0m0.000s Best Regards, Carlo Florendo Carlo, It would have been more helpful if you had provided your cygwin version, but even without it I could venture a guess... The latest versions of cygwin have ntsec on by default, and doing 'ls -l' will result in the user lookup in the /etc/passwd (and /etc/group) file. An easy way to test that is to time 'ls -ln' and see if it's faster. Another test would be to *temporarily* turn off ntsec (by adding nontsec to your CYGWIN environment variable and reloading cygwin1.dll by exiting all running cygwin processes). I say temporarily because ntsec is actually a very useful feature to have on, and this is suggested only as a means to find out whether it's the culprit. You can restore the state by either changing nontsec to ntsec, or leaving it off altogether, as it's the default now, and reloading cygwin1.dll again. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Water molecules expand as they grow warmer (C) Popular Science, Oct'02, p.51 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 3rd time lucky? Apache startup woes
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Stainburn Sent: Monday, November 18, 2002 5:04 PM To: Ralf Habacker; cygwin Subject: Re: 3rd time lucky? Apache startup woes On Monday 18 November 2002 1:49 pm, Ralf Habacker wrote: Hi Jason, Yes, unfortunately I am running WinME, so I downloaded the attachment to the above message. Unfortunately, the make fails as shown below. Ups, sorry, there are symbolic link in the package, with files are not distributed. Can anyone help me here, or point me to a binary distribution I can download? You can find a binary release of the recent version (0.4) on the http://kde-cygwin/sourceforge.net download area. See http://sourceforge.net/project/showfiles.php?group_id=27249release_id=1229 60 Please report any problems with release. Regards Ralf Hi Ralf, As you can see from the extract below, your rebase has worked (rebase.sh is the script Jason gave earlier in this thread), but I still can't start apache. Anyone got any ideas? Just to remind everyone, I'm running all the latest version packages on WinME running on an Advent 7352 laptop. $ ./rebase.sh ReBaseImage(C:\cygwin\home\gary\usr\X11R6\bin\libdps.dll,67ff) failed with last error = 6 #define ERROR_INVALID_HANDLE 6L The rebase could not open the dll. Is this dll still used by any process ? Please make sure, this dll isn't used by any process. gary@LADVENT ~ $ /usr/sbin/apachectl start Syntax error on line 236 of /etc/apache/httpd.conf: Cannot load /usr/lib/apache/libphp4.dll into server: dlopen: Win32 error 31 #define ERROR_GEN_FAILURE 31L Do you have tried ssp. ssp shows you which dll is load onto which address (Unfortunally I don't know if ssp works under winMe) $ ssp -v -d -dll 0x401000 0x44 `cygpath -aw /usr/sbin/httpd.exe ` verbose messages enabled stepping disabled; enable via OutputDebugString (ssp on) profiling dll usage prun: [00401000,0044] Running `c:\programme\cygwin\usr\sbin\httpd.exe' 00:00.000 create process at 00401000 00:00.017 load dll 77f8: (unknown) 00:00.027 load dll 6100: c:\programme\cygwin\bin\cygwin1.dll 00:00.033 load dll 77e7: c:\WINNT\system32\KERNEL32.dll 00:00.042 load dll 6c5c: c:\programme\cygwin\bin\cyghttpd.dll 00:00.047 00:00.050 load dll 77da: c:\WINNT\system32\advapi32.dll 00:00.055 load dll 77d3: c:\WINNT\system32\RPCRT4.DLL 00:00.064 create thread 0764 at 77e73775 c:\WINNT\system32\KERNEL32.dll 00:00.070 exit thread 0764, code=0 00:00.076 ODS: d0/0 cYg 610C9A50 00:00.085 create thread 04cc at 77e73775 c:\WINNT\system32\KERNEL32.dll 00:00.090 ODS: d0/0 cYgstd 22fe58 d 3 00:00.097 load dll 77e0: c:\WINNT\system32\user32.dll 00:00.104 load dll 77f4: c:\WINNT\system32\GDI32.DLL 00:00.111 load dll 75df: c:\WINNT\System32\IMM32.DLL 00:00.126 load dll 4300: c:\programme\cygwin\lib\apache\mod_vhost_alias.dll 00:00.132 load dll 4168: c:\programme\cygwin\lib\apache\mod_env.dll 00:00.140 load dll 41f8: c:\programme\cygwin\lib\apache\mod_log_config.dll Another possibility is to load apache with gdb and start it. Then you can try (gdb) info dll /usr/bin/cygwin1.dll 61001000 /c/WINNT/system32/KERNEL32.DLL 77e71000 /usr/bin/cyghttpd.dll6c5c1000 /c/WINNT/system32/ADVAPI32.DLL 77da1000 /c/WINNT/system32/rpcrt4.dll 77d31000 /c/WINNT/system32/USER32.DLL 77e01000 /c/WINNT/system32/GDI32.DLL 77f41000 /c/WINNT/System32/IMM32.DLL 75df1000 /usr/lib/apache/mod_vhost_alias.dll 43001000 /usr/lib/apache/mod_env.dll 41681000 /usr/lib/apache/mod_log_config.dll 41f81000 /usr/lib/apache/mod_mime_magic.dll 42281000 /usr/lib/apache/mod_mime.dll 42101000 /usr/lib/apache/mod_negotiation.dll 42401000 /usr/lib/apache/mod_status.dll 42a01000 /usr/lib/apache/mod_info.dll 41e01000 /usr/lib/apache/mod_include.dll 41c81000 so see the loaded dll's. Perhaps this helps. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Getting a new version of patch into cygwin
On Fri, Nov 15, 2002 at 01:35:57PM -0500, [EMAIL PROTECTED] wrote: The official cygwin copy of Larry Wall's patch program is mired at version 2.5.0 (which was released way back in 1997). The currently released version is 2.5.4 (which is still from 1999). 2.5.8 is available from the ftp://alpha.gnu.org website The main reason I'm mentioning is that 2.5.4 is necessary for --posix switch which is what you sometimes need to get multi-directory CVS diff files to work right as well as correcting a CR/LF issue I was running into. I have been using 2.5.8 for a few months now and was using 2.5.4 for years before that and haven't run into any problems. I put that on my todo list. There are several Cygwin specific patches in our 2.5.0 so this needs some attention. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
make error during postgresql install on windows using cygwin
Hi all Get the following error after installing cygwin and during running installation steps for PostgreSQL 7.2.1 on windows. ./configure passed successfully. make gives the following error: [quote] $ make make -C doc all make[1]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/doc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/doc' make -C src all make[1]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src' make -C backend all make[2]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend ' make -C access all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access' make -C common SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/common' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/common' make -C gist SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/gist' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/gist' make -C hash SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/hash' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/hash' make -C heap SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/heap' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/heap' make -C index SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/index' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/index' make -C nbtree SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/nbtree' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/nbtree' make -C rtree SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/rtree' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/rtree' make -C transam SUBSYS.o make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /access/transam' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access/transam' make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ access' make -C bootstrap all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /bootstrap' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ bootstrap' make -C catalog all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /catalog' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ catalog' make -C parser all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /parser' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ parser' make -C commands all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /commands' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ commands' make -C executor all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /executor' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/back end/ executor' make -C lib all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /lib' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ lib' make -C libpq all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /libpq' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ libpq' make -C main all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /main' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ main' make -C nodes all make[3]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend /nodes' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/ nodes' make -C optimizer all make[3]: Entering directory
mno_cygwin gcc 3.2
hi all, Under the gcc 2.95 release the :-mno_cygwin option let you link without cygwin1.dll. The gcc 3.2 release in the latest cygwin build, whilst not complaining about the option, will link with the cygwin1.dll even when using the option. cygcheck for example will show the link. This is for a dll compiled with : g++ -shared -mno_cygwin -o X.dll x.cpp Is this behaviour incorrect or is it planned that all cygwin gcc compiled apps will be forced to link with cygwin1.dll? Thanks, Chris _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: mno_cygwin gcc 3.2
-Original Message- From: Chris Twiner [mailto:[EMAIL PROTECTED]] Sent: Tue, November 19, 2002 12:45 PM To: [EMAIL PROTECTED] Subject: mno_cygwin gcc 3.2 hi all, Under the gcc 2.95 release the :-mno_cygwin option let you link without cygwin1.dll. The gcc 3.2 release in the latest cygwin build, whilst not complaining about the option, will link with the cygwin1.dll even when using the option. cygcheck for example will show the link. This is for a dll compiled with : g++ -shared -mno_cygwin -o X.dll x.cpp Is this behaviour incorrect or is it planned that all cygwin gcc compiled apps will be forced to link with cygwin1.dll? Thanks, Chris _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ar - memory exhaused
Hi, I'm compiling debug version of clisp (Common Lisp compiler) and on some stage come to following: An 8Mb object file need to be archived by 'ar' with command 'ar rcv lisp.a lisp.o' and I get the following: $ ar rcv lisp.a lisp.o a - lisp.o ar: lisp.a: Memory exhausted When I compiling non-debug version, lisp.o is about 2Mb and I get no error. My system is NT4.0SP6. How is this can be avoided ? Similar question was asked here 2 years ago w/o success: To: cygwin at sourceware dot cygnus dot com Subject: memory exhausted ??? From: kyra kyrab at mail dot ru Date: Tue, 10 Oct 2000 05:17:00 +0400 When compiling a large c source file cygwin gcc-2.95.2 preprocessor aborts in 3 seconds with something like cpp: memory exhausted. Machive have 512MB physical memory and there are not any signs of memory swapping or something. This seems to be a cygwin issue (?) because native (mingw) gcc-2.95.2 does compile the same source file pretty quickly and easily. -- Best regards, Arseny mailto:[EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Non-blocking I/O
How do I set-up non-blocking I/O with SIGIO or SIGURG notifications under Cygwin? The various Unices I know of use either F_SETFL+F_SETOWN (BSD-ish), I_SETSIG (STREAMS-ish), FIOASYNC+SIOCSPGRP, or FIOASYNC (but does this send signals?). Does any of these work with Cygwin or do I need another one? Also, what kinds of file handlers will it work on? Does it work on sockets and tty's at least? Thanks in advance, Paolo Bonzini -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated Cygwin Package: python-2.2.2-1
Rolf, On Mon, Nov 18, 2002 at 03:49:32PM -0500, Rolf Campbell wrote: I have patched pyserial (locally) and it seems to work fine now. Please submit your patch to pyserial's patch collector on SF for consideration. Thanks for your quick response. You are welcome. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Emacs hangs again (1.3.15, 20021115 and 20021119(!) snapshots)
Hello,
I'm experiencing yet another kind of hangs of emacs (running in X
window). This happens during emacs startup, but only if I resize its
window with mouse while emacs is processing startup files. Then it never
finishes its startup and eats 100% of CPU (quite similar symptoms of
previous bug fixed in 20021115 snapshot).
I've verified the same behaviour with 1.3.15-2 cygwin1 release, 20021115
and 20021119 snapshots.
strace shows this fragment, looping forever:
repeat start here
55 17683118 [main] emacs 2884 cygwin_select: 6, 0x1FB3FC, 0x0, 0x0, 0x0
56 17683174 [main] emacs 2884 dtable::select_read: /dev/streamsocket
fd 5
29 17683203 [main] emacs 2884 cygwin_select: to NULL, ms
30 17683233 [main] emacs 2884 cygwin_select: sel.always_ready 0
56 17683289 [main] emacs 2884 start_thread_socket: Handle 0x6F4
28 17683317 [main] emacs 2884 start_thread_socket: Added to readfds
135 17683452 [main] emacs 2884 start_thread_socket: exitsock 0x624
51 17683503 [main] emacs 2884 start_thread_socket: stuff_start 0x1FB2E0
58 17683561 [main] emacs 2884 select_stuff::wait: m 2, ms 4294967295
33 17683594 [main] emacs 2884 select_stuff::wait: signal received
80 17683674 [main] emacs 2884 select_stuff::cleanup: calling cleanup
routines
35 17683709 [main] emacs 2884 socket_cleanup: si 0x2051FA60
si-thread 0x610CA824
31 17683740 [main] emacs 2884 socket_cleanup: connection to
si-exitsock 0x624
315 17684055 [select_socket] emacs 2884 thread_socket: stuff_start
0x20522A84
55 17684110 [select_socket] emacs 2884 thread_socket: Win32 select
returned 2
35 17684145 [select_socket] emacs 2884 thread_socket: s 0x203B9590,
testing fd 5 (/dev/streamsocket)
33 17684178 [select_socket] emacs 2884 thread_socket: read_ready
30 17684208 [select_socket] emacs 2884 thread_socket: saw exitsock read
165 17684373 [main] emacs 2884 socket_cleanup: returning
32 17684405 [main] emacs 2884 select_stuff::~select_stuff: deleting
select records
repeated forever
Unfortunately, I'm not able to say from this whether is it a bug in
cygwin's select() internals or emacs calling it forever for some other
strange reason. I'll try to understand cygwin's select.cc code and
analyze further, but in the meanwhile, if anyone has any idea..
I've the full strace output, but it is quite big (800kB bz2). If anyone
wants it, I can post it privately.
thanks
Pavel
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Nov 19 13:05:51 2002
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: f:\cygwin\usr\local\bin
f:\cygwin\bin
f:\cygwin\usr\X11R6\bin
c:\cygwin-mounts\opt\gnome2\bin
f:\bin
f:\Program Files\Microsoft Platform SDK\Bin
f:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
f:\Program Files\Microsoft Visual Studio\Common\Tools
f:\Program Files\Wise for Windows Installer
f:\Program Files\Microsoft Visual Studio\VC98\bin
f:\jdk1.3.1\bin
f:\MetaDeveloper\hcarc\bin
f:\src\psuite\main\src\buildengine
f:\bin
SysDir: F:\WINDOWS\System32
WinDir: F:\WINDOWS
CYGWIN = `nowinsymlinks tty error_start=f:\cygwin\bin\dumper.exe'
HOME = `c:\cygwin-mounts\home\pholejs'
LD_LIBRARY_PATH = `\opt\kde2\lib:\opt\kde2\bin'
MAKE_MODE = `unix'
PWD = `/home/pholejs/cyg-em-bug'
USER = `pholejs'
ALLUSERSPROFILE = `F:\Documents and Settings\All Users'
APPDATA = `F:\Documents and Settings\PHolejs\Application Data'
BASEMAKE = `F:\Program Files\Microsoft Platform SDK\Include\BKOffice.Mak'
BASHRC_INITED = `BASHRC_INITED'
BKOFFICE = `F:\Program Files\Microsoft Platform SDK\.'
CLASSPATH =
`f:\Gemplus\GemXpresso.rad3\lib\gse\gse_gxp211_pk.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-gemxpresso.jar;f:\Gemplus\GemXpresso.rad3\lib\cryptix-jce-api.jar'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `F:\Program Files\Common Files'
COMPUTERNAME = `PRGPC009'
COMSPEC = `F:\WINDOWS\system32\cmd.exe'
DISPLAY = `:0.0'
DXSDKROOT = `F:\Program Files\Microsoft Platform SDK\.'
EDITOR = `gnuclient'
HOMEDRIVE = `F:'
HOMEPATH = `\Documents and Settings\PHolejs'
IMNINST = `help'
IMNINSTSRV = `F:\IMNnq_NT'
INCLUDE = `F:\Program Files\Microsoft Platform SDK\Include;F:\Program Files\Microsoft
Platform SDK\Src\WTL\Include;F:\Program Files\Microsoft Visual
Studio\VC98\atl\include;F:\Program Files\Microsoft Visual
Studio\VC98\mfc\include;F:\Program Files\Microsoft Visual Studio\VC98\include'
INETSDK = `F:\Program Files\Microsoft Platform SDK\.'
JAVA_HOME = `F:\jdk1.3.1'
JC21_HOME = `C:\Store\Chipcards\javacard\jc211'
JDKHOME = `F:\jdk1.3.1'
KDEDIR = `/opt/kde2'
KDEHOME = `/home/pholejs/.kde2'
LIB = `F:\Program Files\Intel\Compiler50\ia32\lib;F:\Program Files\Microsoft Platform
SDK\Lib;F:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;F:\Program
Files\Microsoft Visual Studio\VC98\lib'
LOGNAME = `pholejs'
LOGONSERVER = `\\PRGOP02'
LS_COLORS =
`no=00:fi=00:di=01;34
default tcsh configuration scripts
I use tcsh as default shell. (i.e. tcsh -l in cygwin.bat and
...:/bin/tcsh in /etc/passwd). Upon first-startup i used to receive a few
disturbing messages, that sed and grep are not found.
The grep error seems to reside in /etc/profile.d/00xfree.csh, which is very
short, so i won't bother writing more on this. My solution: replaced with
/usr/bin/grep.
The sed error is in /etc/profile.d/complete.tcsh, where set_emacs_dir
relies on the fact that sed is found in path. My solution: replaced with
/usr/bin/sed.
One more thing: I think 00xfree86.sh and .csh should set ${X11PATH}:${PATH}
instead of ${PATH}:${X11PATH} because one may have a windows executable
called X.exe (and I do have such a thingie), which is called by startx
instead of /usr/X11R6/bin/X.
That's it!
Cipi
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Postgresql installation problems.
Kurt, On Tue, Nov 19, 2002 at 01:40:41AM +0100, Kurt Roeckx wrote: On Mon, Nov 18, 2002 at 03:49:47PM -0500, Jason Tishler wrote: Any XP users successfully running PostgreSQL? If so, please post your experiences to the list. I'm especially interested in XP Home, since I assume that XP Pro will be the same as NT/2000. I'm using XP Pro. Hmm...I assumed XP Pro would be the same as NT/2000. I guess it is time to debug why ipc-daemon is not working for you under XP Pro. It seems it should just give a error instead of using all CPU. Yes. Anything else changed? Nothing on the PostgreSQL side. However, it is built against cygipc 1.13-2 instead of 1.11-1. See the cygipc ChangeLog for the details. I tried about everything I could think of. You may want to try the [EMAIL PROTECTED] mailing list. IIRC, there are users there using XP. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Non-blocking I/O
On Tue, Nov 19, 2002 at 12:52:44PM +0100, Paolo Bonzini wrote: How do I set-up non-blocking I/O with SIGIO or SIGURG notifications under Cygwin? FIOASYNC Also, what kinds of file handlers will it work on? Does it work on sockets and tty's at least? With sockets only and only in a restricted way. It's not well supported by WinSock. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: make error during postgresql install on windows using cygwin
Godson, On Tue, Nov 19, 2002 at 03:55:08PM +0530, Godson Retna wrote: $ make [snip] make[4]: Entering directory `/cygdrive/c/postgresql/postgresql-7.2.1/src/backend/storage/ipc' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I/usr/local/include -DBUILDING_DLL=1 -c -o ipc.o ipc.c cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory ipc.c: In function `InternalIpcSemaphoreCreate': ipc.c:271: warning: implicit declaration of function `semget' ipc.c:271: `IPC_CREAT' undeclared (first use in this function) ipc.c:271: (Each undeclared identifier is reported only once ipc.c:271: for each function it appears in.) Sigh. You still haven't answered the following: http://archives.postgresql.org/pgsql-cygwin/2002-11/msg00109.php Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: libxml2/libxslt binaries: libxml2 version mismatch in xsltproc
On Mon, 2002-11-18 at 21:19, Yves Forkl wrote: Sorry for not being clear about the specific problem I encountered which is almost certainly caused by the version mismatch, but I didn't know if that classified as a bug proper - please see the description of the problem in the message included. Well, for future reference, unclear messages get a 'clarify or go away' response 100% of the time. $ xsltproc --version Using libxml 20417, libxslt 10010 and libexslt 703 xsltproc was compiled against libxml 20413, libxslt 10010 and libexslt 703 libxslt 10010 was compiled against libxml 20413 libexslt 703 was compiled against libxml 20413 Looks 1/ old 2/ bad (the library used an the one the application was compiled again do not match) ... Simply upgrade then ! I need time to do a new build , a new libxml and libxslt have just been released anyway. For now, you can build your own, using the patches in the cygwin source packages as a starting point. I suspect this is an age thing, not a version mismatch BTW. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
RE: mno_cygwin gcc 3.2
The correct option is -mno-cygwin and it works fine for me (at least for hello world app). Thanks Pavel, Do you not get a : ld: cannot open dllcrt2.o message? Previous postings would seem to indicate this is a specs file issue, which has been resolved in previous releases. Has it been unfixed in this release or do I have some env badly configured, TIA Chris _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: quick config question
Looks like NT's find.exe is executed. -Original Message- From: Steffens-Jr, Alfred P [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 9:58 AM To: '[EMAIL PROTECTED]' Subject: quick config question Running the find command, find -iname 'gcc.exe' -print results in find not being able to read its parameters. I've seen this before but forgot how to fix it. I just upgraded to Windows 2000. Thanks. Al Steffens [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
looking for compiled lib
I'm looking for the gd and freetype lib as dll. I didn't find them via setup nor following link about ported software. Has anybody more information about these (compiled ) lib ? I can't compile myselh because I have a pb with gcc (see message on this list gcc about problem with function) Thank you JRC -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls problem
Carlo, I think your next step must be to run ls under strace and see where the excess time (presumably idle time) is going. Randall Schulz Mountain View, CA USA At 17:00 2002-11-19, Carlo Florendo wrote: Hi Igor, I tried disabling ntsec and ls -l is still slow. I'm using 1.3.15-cygwin-1-3-15-1. ls -l and ls -ln takes almost the same amount of time.On a directory with 3 short text files, the difference, when I timed ls -l and ls -b, is still considerable. fcarlo@ZEUS~ $ time ls -b a b test real0m0.024s user0m0.030s sys 0m0.015s fcarlo@ZEUS ~ $ time ls -l total 11 -rw-r--r--1 fcarlo None5 Nov 19 13:58 a -rw-r--r--1 fcarlo None5 Nov 19 13:58 b -rw-r--r--1 fcarlo None 8283 Nov 19 13:59 test real0m1.819s user0m0.030s sys 0m0.000s Best Regards, Carlo Florendo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
sshd: server refused our key
Hello, I have setup sshd using privilege separation. ssh login works fine but sshd doesn't accept my public key, which works fine using ssh on other UNIX machines. This is part of debug information of login: debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is publickey debug1: try pubkey: /home/mk/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: try privkey: /home/mk/.ssh/id_dsa debug2: we did not send a packet, disable method debug1: next auth method to try is keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: next auth method to try is password Do you have any idea to fix this problem? Thank you in advance, Manfred __ Wie war die Telefonnummer von Hans? In Zukunft haben Sie alle Daten - bei WEB.DE FreeMail! http://freemail.web.de/features/?mc=021134 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mno_cygwin gcc 3.2
Chris Twiner [EMAIL PROTECTED] wrote: The correct option is -mno-cygwin and it works fine for me (at least for hello world app). Thanks Pavel, Do you not get a : ld: cannot open dllcrt2.o Do you have the gcc-mingw package installed? -mno-cygwin is not functional without it. If you still have a problem, attach (don't paste inline) the output of cygcheck -svr. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: sshd: server refused our key
As requested at http://cygwin.com/bugs.html: o Please describe how to reproduce the problem, including a test case, if possible. In your case, please list the commands that you ran to set up sshd on your Cygwin machine. o Please include at least the version number of the Cygwin release you are using along with the operating system name and its version number, for example, cygwin v1.3.13 under NT 4.0. o Most of the information about your Cygwin environment is listed by running 'cygcheck -s -v -r cygcheck.txt'. Please include cygcheck.txt *AS AN ATTACHMENT* to your report. It is important that you include it as an attachment so that searches of the mailing-list archives give fewer false matches. Some things to check (that is, email back to this mailing list): The permissions and ownership of: - your home directory - your home/.ssh directory - your home/.ssh files -Original Message- From: Manfred Köhler [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 10:47 AM To: [EMAIL PROTECTED] Subject: sshd: server refused our key Hello, I have setup sshd using privilege separation. ssh login works fine but sshd doesn't accept my public key, which works fine using ssh on other UNIX machines. This is part of debug information of login: debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is publickey debug1: try pubkey: /home/mk/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: try privkey: /home/mk/.ssh/id_dsa debug2: we did not send a packet, disable method debug1: next auth method to try is keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: next auth method to try is password Do you have any idea to fix this problem? Thank you in advance, Manfred __ Wie war die Telefonnummer von Hans? In Zukunft haben Sie alle Daten - bei WEB.DE FreeMail! http://freemail.web.de/features/?mc=021134 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Conflict between libcygwin.a and GCC core libraries
Hi folks, I'm currently trying to compile GPA (s. http://www.gnupg.org/gpa.html) on Cygwin. To get it up and running, first of all I had to insert -mno-cygwin -mms-bitfields into the compiler options. After changing some more stuff in the makefiles, compiling runs fine now, but linking still causes trouble. First, I got a lot of `undefined references' to functions as basic as `__assert'. To get rid of them, I included -lcygwin by hand into the linker options. Now, the undefined references have disappeared, but instead I get the following error message: libcygwin.a: multiple definition of `atexit' crt2.o:crt1.c: first defined here Since libcygwin and crt2 are both essential parts of the development environment itself, I don't see a possibility how to solve this conflict. Can anyone help me? Thanks alot in advance Markus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Conflict between libcygwin.a and GCC core libraries
Markus Gerwinski [EMAIL PROTECTED] wrote: I'm currently trying to compile GPA (s. http://www.gnupg.org/gpa.html) on Cygwin. To get it up and running, first of all I had to insert -mno-cygwin -mms-bitfields into the compiler options. If you add -mno-cygwin, then you are trying to compile GPA for MinGW, not Cygwin. After changing some more stuff in the makefiles, compiling runs fine now, but linking still causes trouble. First, I got a lot of `undefined references' to functions as basic as `__assert'. To get rid of them, I included -lcygwin by hand into the linker options. Aaargh! First you tell gcc to not use cygwin, then you tell it to sort-of use cygwin. No wonder its confused! Solution: Don't do that. Do you actually intend to compile GPA for MinGW or Cygwin? If Cygwin, drop the -mno-cygwin. If MinGW, make sure the gcc-mingw package is installed. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: server refused our key
Manfred Köhler [EMAIL PROTECTED] wrote: I have setup sshd using privilege separation. ssh login works fine but sshd doesn't accept my public key, which works fine using ssh on other UNIX machines. To diagnose properly, we need to see the *server* debug log. To get this, install SSH as a service with debug arguments: cygrunsrv -I sshd_debugmode -d CYGWIN sshd DEBUG MODE -p /usr/sbin/sshd -a -Dddde -e CYGWIN=binmode tty ntsec -t manual Then stop sshd, start sshd_debugmode and try to log in. NB: sshd in debug mode will die after handling one connection. Server debug output will be written to /var/log/sshd_debugmode.log. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Conflict between libcygwin.a and GCC core libraries
Max Bowsher wrote: After changing some more stuff in the makefiles, compiling runs fine now, but linking still causes trouble. First, I got a lot of `undefined references' to functions as basic as `__assert'. To get rid of them, I included -lcygwin by hand into the linker options. Aaargh! First you tell gcc to not use cygwin, then you tell it to sort-of use cygwin. No wonder its confused! It seemed to be the only way to avoid the undefined references I had before. I had tried some other ways, but they either didn't work at all or yielded the same result. (Explicitly linking with -lc, for example, got me the same error message; just libcygwin.a was replaced by libc.a.) Solution: Don't do that. Okay, but what else? Do you actually intend to compile GPA for MinGW or Cygwin? To be honest, as long as I end up with a runnable gpa.exe for Windows, I dont' care... I gave it a try using Cygwin. If Cygwin, drop the -mno-cygwin. Then GTK+-2.0 refuses to link. If MinGW, make sure the gcc-mingw package is installed. It is, at least the binaries. Yours, Markus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mno_cygwin gcc 3.2
Chris Twiner [EMAIL PROTECTED] wrote: Chris Twiner [EMAIL PROTECTED] wrote: The correct option is -mno-cygwin and it works fine for me (at least for hello world app). Thanks Pavel, Do you not get a : ld: cannot open dllcrt2.o Do you have the gcc-mingw package installed? -mno-cygwin is not functional without it. If you still have a problem, attach (don't paste inline) the output of cygcheck -svr. I've attached the output, but the files are definitely there /lib/mingw No, can't see anything odd. Maybe adding '-v' to your link-stage invocation of gcc with show something helpful. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Conflict between libcygwin.a and GCC core libraries
Markus Gerwinski [EMAIL PROTECTED] wrote: To be honest, as long as I end up with a runnable gpa.exe for Windows, I dont' care... I gave it a try using Cygwin. If Cygwin, drop the -mno-cygwin. Then GTK+-2.0 refuses to link. Ahh. You will need to use the same setting as your gtk+ was compiled with. Based on what you say above, I think that you will need -mno-cygwin. But, you will *not* solve anything by adding -lcygwin. Post details of the errors with -mno-cygwin but without -lcygwin. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mno_cygwin gcc 3.2
No, can't see anything odd. Maybe adding '-v' to your link-stage invocation of gcc with show something helpful. It did no -L/lib/mingw for ld, so the spec file is wrong/incorrect on my machine does this work properly on others? (Using Wl didn't do much better either, passing -L/lib/mingw to it directly still places it after the dllcrt2.o so the linker never finds it). What does your's show? TIA Chris _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Emacs hangs again (1.3.15, 20021115 and 20021119(!) snapshots)
On Tue, Nov 19, 2002 at 01:11:57PM +0100, Pavel Holejsovsky wrote:
Hello,
I'm experiencing yet another kind of hangs of emacs (running in X
window). This happens during emacs startup, but only if I resize its
window with mouse while emacs is processing startup files. Then it never
finishes its startup and eats 100% of CPU (quite similar symptoms of
previous bug fixed in 20021115 snapshot).
I've verified the same behaviour with 1.3.15-2 cygwin1 release, 20021115
and 20021119 snapshots.
strace shows this fragment, looping forever:
repeat start here
55 17683118 [main] emacs 2884 cygwin_select: 6, 0x1FB3FC, 0x0, 0x0, 0x0
56 17683174 [main] emacs 2884 dtable::select_read: /dev/streamsocket
fd 5
29 17683203 [main] emacs 2884 cygwin_select: to NULL, ms
30 17683233 [main] emacs 2884 cygwin_select: sel.always_ready 0
56 17683289 [main] emacs 2884 start_thread_socket: Handle 0x6F4
28 17683317 [main] emacs 2884 start_thread_socket: Added to readfds
135 17683452 [main] emacs 2884 start_thread_socket: exitsock 0x624
51 17683503 [main] emacs 2884 start_thread_socket: stuff_start 0x1FB2E0
58 17683561 [main] emacs 2884 select_stuff::wait: m 2, ms 4294967295
33 17683594 [main] emacs 2884 select_stuff::wait: signal received
80 17683674 [main] emacs 2884 select_stuff::cleanup: calling cleanup
routines
35 17683709 [main] emacs 2884 socket_cleanup: si 0x2051FA60
si-thread 0x610CA824
31 17683740 [main] emacs 2884 socket_cleanup: connection to
si-exitsock 0x624
315 17684055 [select_socket] emacs 2884 thread_socket: stuff_start
0x20522A84
55 17684110 [select_socket] emacs 2884 thread_socket: Win32 select
returned 2
35 17684145 [select_socket] emacs 2884 thread_socket: s 0x203B9590,
testing fd 5 (/dev/streamsocket)
33 17684178 [select_socket] emacs 2884 thread_socket: read_ready
30 17684208 [select_socket] emacs 2884 thread_socket: saw exitsock read
165 17684373 [main] emacs 2884 socket_cleanup: returning
32 17684405 [main] emacs 2884 select_stuff::~select_stuff: deleting
select records
repeated forever
Unfortunately, I'm not able to say from this whether is it a bug in
cygwin's select() internals or emacs calling it forever for some other
strange reason. I'll try to understand cygwin's select.cc code and
analyze further, but in the meanwhile, if anyone has any idea..
I've the full strace output, but it is quite big (800kB bz2). If anyone
wants it, I can post it privately.
Unless you are actually familiar with cygwin internals, posting strace
logs or even strace snippets is probably worthless in the majority of
the cases. There is nothing in the above code which indicates that
anything is wrong.
It would really be wonderful to have someone actually debugging this
problem rather than speculating on what they think might be wrong and
sending YA snippet of normal strace logs to the list.
Ah. I can dream, can't I?
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: ls problem
Carlo, The difference between 'ls' and 'ls -l' is that 'ls -l' actually performs a stat() call on every file in the directory, whereas 'ls' simply reads the directory contents and doesn't touch the files. Therefore, the files themselves (or, rather, the stat records for them) need to be in disk cache along with the directory, otherwise it'll take some time to load them from disk. Try running 'ls -l' first to pull the directory contents and the stat records for the files into memory, and then repeating both 'time ls' and 'time ls -l' commands, and see if that makes a difference in the timings. FYI, 'ls -l' is *supposed* to be slower, because it accesses more information. On my machine (P3 700MHz running Win2k Pro SP3), the timings are as follows: $ cd /bin ls -l /dev/null $ ls | wc -l 658 $ time ls /dev/null real0m1.140s user0m0.180s sys 0m0.851s $ time ls -l /dev/null real0m1.917s user0m0.370s sys 0m1.421s $ Igor On Tue, 19 Nov 2002, Carlo Florendo wrote: Hi Igor, I tried disabling ntsec and ls -l is still slow. I'm using 1.3.15-cygwin-1-3-15-1. ls -l and ls -ln takes almost the same amount of time.On a directory with 3 short text files, the difference, when I timed ls -l and ls -b, is still considerable. fcarlo@ZEUS~ $ time ls -b a b test real0m0.024s user0m0.030s sys 0m0.015s fcarlo@ZEUS ~ $ time ls -l total 11 -rw-r--r--1 fcarlo None5 Nov 19 13:58 a -rw-r--r--1 fcarlo None5 Nov 19 13:58 b -rw-r--r--1 fcarlo None 8283 Nov 19 13:59 test real0m1.819s user0m0.030s sys 0m0.000s Best Regards, Carlo Florendo Carlo, It would have been more helpful if you had provided your cygwin version, but even without it I could venture a guess... The latest versions of cygwin have ntsec on by default, and doing 'ls -l' will result in the user lookup in the /etc/passwd (and /etc/group) file. An easy way to test that is to time 'ls -ln' and see if it's faster. Another test would be to *temporarily* turn off ntsec (by adding nontsec to your CYGWIN environment variable and reloading cygwin1.dll by exiting all running cygwin processes). I say temporarily because ntsec is actually a very useful feature to have on, and this is suggested only as a means to find out whether it's the culprit. You can restore the state by either changing nontsec to ntsec, or leaving it off altogether, as it's the default now, and reloading cygwin1.dll again. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Water molecules expand as they grow warmer (C) Popular Science, Oct'02, p.51 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Conflict between libcygwin.a and GCC core libraries
Max Bowsher wrote: Post details of the errors with -mno-cygwin but without -lcygwin. Okay. The full compiler call is attached in file log1, the error message in log2. It's everything left from the whole output of 'make'; all other jobs have already run fine. In short the error messages say, I get 'undefined reference's to QUITE a lot of functions, among them some essential gcc functions like __assert, __errno, pipe, kill, fork etc. Yours, Markus gcc -g -O2 -mno-cygwin -mms-bitfields -I/mysoftware/atk-dev-1.0.3-20020821/include/atk-1.0 -I/mysoftware/glib-dev-2.0.6-20020802/include/glib-2.0 -I/mysoftware/glib-dev-2.0.6-20020802/lib/glib-2.0/include -I/mysoftware/gtk+-dev-2.0.6-20020921/include/gtk-2.0 -I/mysoftware/gtk+-dev-2.0.6-20020921/lib/gtk-2.0/include -I/mysoftare/pango-dev-1.0.4-20020928/include/pango-1.0 -I/mysoftware/pango-dev-1.0.4-20020928/include/pango-1.0 -I/mysoftware/zlib-1.1.4-lib/include -I/home/markus/gpgme-0.3.12/gpgme -DGTK_ENABLE_BROKEN -I/usr/local/include -Wall -o gpa.exe gpa.o gpawindowkeeper.o gtktools.o helpmenu.o optionsmenu.o icons.o gpawidgets.o gpafilesel.o fileman.o filesigndlg.o encryptdlg.o verifydlg.o keyring.o ownertrustdlg.o keysigndlg.o keyimportdlg.o keyimpseldlg.o keyexportdlg.o keygendlg.o keygenwizard.o qdchkpwd.o keyeditdlg.o expirydlg.o keydeletedlg.o keylist.o siglist.o gpawizard.o gpapastrings.o gpa_license.o keyserver.o w32reg.o simple-gettext.o hidewnd.o keytable.o gpgmetools.o gpgmeedit.o gpgmeparsers.o server_access.o -L ../jnlib -ljnlib ../intl/libintl.a -lz -lm -L/mysoftware/atk-dev-1.0.3-20020821/lib -L/mysoftware/glib-dev-2.0.6-20020802/lib -L/mysoftware/gtk+-dev-2.0.6-20020921/lib -L/mysoftare/pango-dev-1.0.4-20020928/lib -L/mysoftware/pango-dev-1.0.4-20020928/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -L/usr/local/lib -lgpgme -lpthread -lws2_32 gpafilesel.o(.text+0x84b9): In function `find_completion_dir': /home/markus/gpa/src/gpafilesel.c:3605: undefined reference to `fnmatch' gpafilesel.o(.text+0x86ec): In function `attempt_file_completion': /home/markus/gpa/src/gpafilesel.c:3719: undefined reference to `fnmatch' gpafilesel.o(.text+0x8785):/home/markus/gpa/src/gpafilesel.c:3767: undefined reference to `fnmatch' server_access.o(.text+0x70): In function `parse_keyserver_uri': /home/markus/gpa/src/server_access.c:73: undefined reference to `strsep' server_access.o(.text+0xdf):/home/markus/gpa/src/server_access.c:91: undefined reference to `strsep' server_access.o(.text+0x11e):/home/markus/gpa/src/server_access.c:102: undefined reference to `strsep' /usr/local/lib/libgpgme.a(gpgme.o)(.text+0x239): In function `gpgme_cancel': /home/markus/gpgme-0.3.12/gpgme/gpgme.c:119: undefined reference to `_impure_ptr' /usr/local/lib/libgpgme.a(gpgme.o)(.text+0x33f): In function `gpgme_set_op_info': /home/markus/gpgme-0.3.12/gpgme/gpgme.c:193: undefined reference to `__assert' /usr/local/lib/libgpgme.a(version.o)(.text+0x59): In function `parse_version_number': /home/markus/gpgme-0.3.12/gpgme/version.c:55: undefined reference to `_imp___ctype_' /usr/local/lib/libgpgme.a(version.o)(.text+0xa4):/home/markus/gpgme-0.3.12/gpgme/version.c:63: undefined reference to `_imp___ctype_' /usr/local/lib/libgpgme.a(keylist.o)(.text+0x3d9): In function `set_userid_flags': /home/markus/gpgme-0.3.12/gpgme/keylist.c:168: undefined reference to `__assert' /usr/local/lib/libgpgme.a(keylist.o)(.text+0xd6a): In function `keylist_colon_handler': /home/markus/gpgme-0.3.12/gpgme/keylist.c:361: undefined reference to `__assert' /usr/local/lib/libgpgme.a(keylist.o)(.text+0xf3c): In function `gpgme_op_keylist_event_cb': /home/markus/gpgme-0.3.12/gpgme/keylist.c:538: undefined reference to `__assert' /usr/local/lib/libgpgme.a(keylist.o)(.text+0x1254): In function `gpgme_op_keylist_next': /home/markus/gpgme-0.3.12/gpgme/keylist.c:723: undefined reference to `__assert' /usr/local/lib/libgpgme.a(key.o)(.text+0x521): In function `gpgme_key_ref': /home/markus/gpgme-0.3.12/gpgme/key.c:313: undefined reference to `_impure_ptr' /usr/local/lib/libgpgme.a(key.o)(.text+0x755): In function `gpgme_key_release': /home/markus/gpgme-0.3.12/gpgme/key.c:377: undefined reference to `__assert' /usr/local/lib/libgpgme.a(key.o)(.text+0xb97): In function `gpgme_key_append_name': /home/markus/gpgme-0.3.12/gpgme/key.c:629: undefined reference to `_imp___ctype_' /usr/local/lib/libgpgme.a(key.o)(.text+0xc49):/home/markus/gpgme-0.3.12/gpgme/key.c:573: undefined reference to `__assert' /usr/local/lib/libgpgme.a(data.o)(.text+0x271): In function `gpgme_data_new_from_file': /home/markus/gpgme-0.3.12/gpgme/data.c:241: undefined reference to `__errno' /usr/local/lib/libgpgme.a(data.o)(.text+0x28e):/home/markus/gpgme-0.3.12/gpgme/data.c:248: undefined reference to `__errno' /usr/local/lib/libgpgme.a(data.o)(.text+0x2a8):/home/markus/gpgme-0.3.12/gpgme/data.c:251:
Re: mno_cygwin gcc 3.2
Chris Twiner [EMAIL PROTECTED] wrote: No, can't see anything odd. Maybe adding '-v' to your link-stage invocation of gcc with show something helpful. It did no -L/lib/mingw for ld, so the spec file is wrong/incorrect on my machine does this work properly on others? (Using Wl didn't do much better either, passing -L/lib/mingw to it directly still places it after the dllcrt2.o so the linker never finds it). What does your's show? gcc -mno-cygwin -v -shared -export-all dll.c -o hello.dll -Wl,--out-implib,libhello.dll.a ... /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/bin/ld.exe --shared -Bdynamic -e _DllMainCRTStartup@12 -o hello.dll -export-all /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib/dllcrt2 .o /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-m ingw32/3.2 -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw3 2/lib -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../.. /var/tmp/ccqxxSSp.o --out-implib libhello.dll.a -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -luse r32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lm svcrt /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtend.o Using gcc-3.2-3. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Conflict between libcygwin.a and GCC core libraries
Markus Gerwinski [EMAIL PROTECTED] wrote: Max Bowsher wrote: Post details of the errors with -mno-cygwin but without -lcygwin. Okay. The full compiler call is attached in file log1, the error message in log2. It's everything left from the whole output of 'make'; all other jobs have already run fine. In short the error messages say, I get 'undefined reference's to QUITE a lot of functions, among them some essential gcc functions like __assert, __errno, pipe, kill, fork etc. 'fork' isn't available under MinGW. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Conflict between libcygwin.a and GCC core libraries
Max Bowsher wrote: In short the error messages say, I get 'undefined reference's to QUITE a lot of functions, among them some essential gcc functions like __assert, __errno, pipe, kill, fork etc. 'fork' isn't available under MinGW. Good to know... Anyway, the other ones should be there, don't they? Markus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
patch(1) (Win32) and path separators
patch(1) on Win32 seems to insist on '\' rather than '/' in the paths in diffs. This is somewhat at odds with diff(1) which uses '/', even on Windows. According to the manpage there is no option to change this behaviour. I have d/l the sources but have yet to build it (am I correct that it needs gcc to build, i.e. won't build with MSVC++?) with the intention of making my own version that works with '/'. Can anyone confirm that there isn't an undocumented option (cmd line or build) to make it use '/'? If there isn't, why is it that the Windows version works this way, especially when diff(1) DTRT? Thanks. Regards, Parish -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: patch(1) (Win32) and path separators
At 01:10 PM 11/19/2002, Parish wrote: patch(1) on Win32 seems to insist on '\' rather than '/' in the paths in diffs. This is somewhat at odds with diff(1) which uses '/', even on Windows. According to the manpage there is no option to change this behaviour. I have d/l the sources but have yet to build it (am I correct that it needs gcc to build, i.e. won't build with MSVC++?) with the intention of making my own version that works with '/'. Can anyone confirm that there isn't an undocumented option (cmd line or build) to make it use '/'? If there isn't, why is it that the Windows version works this way, especially when diff(1) DTRT? What patch are you using? The Cygwin version works fine with '/'. I have to assume that since you mention the Windows version that your talking about a native port and not the patch that's available through Cygwin. If that's a proper assumption, you don't have the right forum to discuss the Windows native version of patch. This list discusses Cygwin-related issues only. Sorry, Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: mno_cygwin gcc 3.2
Maybe adding '-v' to your link-stage invocation of gcc with show something helpful. Here's what I get when I try to build gnucap: Reading specs from /usr/lib/gcc-lib/i686-pc-mingw32/3.2/specs Configured with: /netrel/src/gcc-3.2-1/configure --enable-languages=c,c++, f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-s hared --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin Thread model: posix gcc version 3.2 20020818 (prerelease) /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/bin/ld.exe -Bdynamic -o gnucap.exe /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib/crt2.o /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2 -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../.. here lots of gnucap libraries, then: -lstdc++ -lm -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwe x -lmsvcrt /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtend.o [edit] Just before hitting the 'send' button I tried to build gnugo with -mno-cygwin. It worked (i.e. it doesn't require cygwin1.dll to run). So I understand my setup is correct and the problem comes from gnucap alone. Does anybody have an idea about what could be the problem ? Is it possible that I'm linking by mistake with a library that requires cygwin1.dll ? Is there an issue with the order in which the libraries are linked ? From this you probably understand that I'm not an expert at debugging this kind of error... TIA, Denis. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: patch(1) (Win32) and path separators
On 19/11/2002 18:14 Larry Hall (RFK Partners, Inc) stood on a soap-box
and preached to the unwashed masses:
At 01:10 PM 11/19/2002, Parish wrote:
patch(1) on Win32 seems to insist on '\' rather than '/' in the paths in diffs. This is somewhat at odds with diff(1) which uses '/', even on Windows.
According to the manpage there is no option to change this behaviour.
I have d/l the sources but have yet to build it (am I correct that it needs gcc to build, i.e. won't build with MSVC++?) with the intention of making my own version that works with '/'.
Can anyone confirm that there isn't an undocumented option (cmd line or build) to make it use '/'? If there isn't, why is it that the Windows version works this way, especially when diff(1) DTRT?
What patch are you using? The Cygwin version works fine with '/'. I have
to assume that since you mention the Windows version that your talking
No, the one installed by the cygwin setup program:
marder-1:/cygdrive/e/mozilla_src/mozilla{13}$ patch --version
patch 2.5
Copyright 1988 Larry Wall
Copyright 1997 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
written by Larry Wall with lots o' patches by Paul Eggert
marder-1:/cygdrive/e/mozilla_src/mozilla{14}$
This is what happens when I run it:
marder-1:/cygdrive/e/mozilla_src/mozilla{12}$ patch --dry-run
../nsNativeAppSupportGtk.diff
can't find file to patch at input line 8
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--
|Index: xpfe/bootstrap/nsNativeAppSupportGtk.cpp
|===
|RCS file: /cvsroot/mozilla/xpfe/bootstrap/nsNativeAppSupportGtk.cpp,v
|retrieving revision 1.9
|diff -u -r1.9 nsNativeAppSupportGtk.cpp
|--- xpfe/bootstrap/nsNativeAppSupportGtk.cpp 29 Aug 2002 03:04:36
-1.9
|+++ xpfe/bootstrap/nsNativeAppSupportGtk.cpp 17 Nov 2002 22:06:07 -
--
File to patch:
The file, nsNativeAppSupportGtk.cpp exists:
marder-1:/cygdrive/e/mozilla_src/mozilla{14}$ ls -l
xpfe/bootstrap/nsNativeAppSupportGtk.cpp
-rwx--1 markoNone 3624 Nov 17 22:11
xpfe/bootstrap/nsNativeAppSupportGtk.cpp
marder-1:/cygdrive/e/mozilla_src/mozilla{15}$
about a native port and not the patch that's available through Cygwin.
If that's a proper assumption, you don't have the right forum to discuss the
Windows native version of patch. This list discusses Cygwin-related issues
only.
Sorry,
Larry Hall [EMAIL PROTECTED]
RFK Partners, Inc. http://www.rfk.com
838 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: patch(1) (Win32) and path separators
On Tue, 19 Nov 2002, Parish wrote:
On 19/11/2002 18:14 Larry Hall (RFK Partners, Inc) stood on a soap-box
and preached to the unwashed masses:
At 01:10 PM 11/19/2002, Parish wrote:
patch(1) on Win32 seems to insist on '\' rather than '/' in the paths in diffs.
This is somewhat at odds with diff(1) which uses '/', even on Windows.
According to the manpage there is no option to change this behaviour.
I have d/l the sources but have yet to build it (am I correct that it needs gcc to
build, i.e. won't build with MSVC++?) with the intention of making my own version
that works with '/'.
Can anyone confirm that there isn't an undocumented option (cmd line or build) to
make it use '/'? If there isn't, why is it that the Windows version works this way,
especially when diff(1) DTRT?
What patch are you using? The Cygwin version works fine with '/'. I have
to assume that since you mention the Windows version that your talking
No, the one installed by the cygwin setup program:
marder-1:/cygdrive/e/mozilla_src/mozilla{13}$ patch --version
patch 2.5
Copyright 1988 Larry Wall
Copyright 1997 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
written by Larry Wall with lots o' patches by Paul Eggert
marder-1:/cygdrive/e/mozilla_src/mozilla{14}$
This is what happens when I run it:
marder-1:/cygdrive/e/mozilla_src/mozilla{12}$ patch --dry-run
../nsNativeAppSupportGtk.diff
can't find file to patch at input line 8
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--
|Index: xpfe/bootstrap/nsNativeAppSupportGtk.cpp
|===
|RCS file: /cvsroot/mozilla/xpfe/bootstrap/nsNativeAppSupportGtk.cpp,v
|retrieving revision 1.9
|diff -u -r1.9 nsNativeAppSupportGtk.cpp
|--- xpfe/bootstrap/nsNativeAppSupportGtk.cpp 29 Aug 2002 03:04:36
-1.9
|+++ xpfe/bootstrap/nsNativeAppSupportGtk.cpp 17 Nov 2002 22:06:07 -
--
File to patch:
The file, nsNativeAppSupportGtk.cpp exists:
marder-1:/cygdrive/e/mozilla_src/mozilla{14}$ ls -l
xpfe/bootstrap/nsNativeAppSupportGtk.cpp
-rwx--1 markoNone 3624 Nov 17 22:11
xpfe/bootstrap/nsNativeAppSupportGtk.cpp
marder-1:/cygdrive/e/mozilla_src/mozilla{15}$
about a native port and not the patch that's available through Cygwin.
If that's a proper assumption, you don't have the right forum to discuss the
Windows native version of patch. This list discusses Cygwin-related issues
only.
Sorry,
Larry Hall [EMAIL PROTECTED]
Try 'patch -p0 --dry-run filename'.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Water molecules expand as they grow warmer (C) Popular Science, Oct'02, p.51
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Error compiling: cc1plus.exe - Entry Point Not Found entry point putc_unlocked could not be located
I just upgraded to the latest cygwin releases on my XP Pro system. I installed the defaults, which should have upgraded everything that needed upgrading. Previously, with the earlier version I had installed, I had no problem compiling. Now, every time I compile, I get a pop-up window with the title cc1plus.exe - Entry Point Not Found and the text The procedure entry point putc_unlocked could not be located in the dynamic link library cygwin1.dll The cygwin1.dll version is 1.3.15-1. gcc is version 3.2 20020927. Looking through the cygwin mailing-list archives I found something about putc_unlocked being unimplemented (see http://sources.redhat.com/ml/cygwin/2002-07/msg00240.html) , but nothing about my particular problem, or how to solve it. This, of course, is a major bug for me, as I can't compile anything. The command g++ -g xxx.cpp -c will always cause the error pop-up. Any suggestions? Many thanks. D.D. __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Error compiling: cc1plus.exe - Entry Point Not Found entry point putc_unlocked could not be located
Daryl Drome [EMAIL PROTECTED] wrote: I get a pop-up window with the title cc1plus.exe - Entry Point Not Found and the text The procedure entry point putc_unlocked could not be located in the dynamic link library cygwin1.dll The cygwin1.dll version is 1.3.15-1. putc_unlocked is present in 1.3.15-2. Get the latest version of Cygwin and the problem will probably go away. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 3rd time lucky? Apache startup woes
Anyone got any ideas? Just to remind everyone, I'm running all the latest version packages on WinME running on an Advent 7352 laptop. $ ./rebase.sh ReBaseImage(C:\cygwin\home\gary\usr\X11R6\bin\libdps.dll,67ff) failed with last error = 6 gary@LADVENT ~ $ /usr/sbin/apachectl start Syntax error on line 236 of /etc/apache/httpd.conf: Cannot load /usr/lib/apache/libphp4.dll into server: dlopen: Win32 error 31 /usr/sbin/apachectl start: httpd could not be started sorry to be roude, but I claimed that it *should* work (and has been tested) on NT based systen, i.e. Win200 etc. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: patch(1) (Win32) and path separators
On 19/11/2002 18:50 Igor Pechtchanski stood on a soap-box and preached to the unwashed masses: Try 'patch -p0 --dry-run filename'. That did it. Thanks Igor :-) I'd always assumed that without -p patch obeyed the path in the diff and that -p was only needed if, for example, the path in the diff was absolute and you needed a relative one. I didn't read all of the -p section in the manpage because it didn't seem to be what I needed, but /now/ I've read the last paragraph. Previously I'd been editing the diffs to replace '/' with '\' so it worked; I guess what was happening was that patch was interpreting the whole string a filename but the shell, or the system calls patch uses, were interpreting the '\' as path separators and therefore it worked? Thanks again for the help. Regards, Parish (who's going to make 'patch' an alias for 'patch -p0' ;-) ) Igor -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mno_cygwin gcc 3.2
Denis Dupeyron [EMAIL PROTECTED] wrote: Maybe adding '-v' to your link-stage invocation of gcc with show something helpful. Here's what I get when I try to build gnucap: Reading specs from /usr/lib/gcc-lib/i686-pc-mingw32/3.2/specs Configured with: /netrel/src/gcc-3.2-1/configure --enable-languages=c,c++, f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-s hared --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin Thread model: posix gcc version 3.2 20020818 (prerelease) /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/bin/ld.exe -Bdynamic -o gnucap.exe /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib/crt2.o /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2 -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/lib -L/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../.. here lots of gnucap libraries, then: -lstdc++ -lm -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwe x -lmsvcrt /usr/lib/gcc-lib/i686-pc-mingw32/3.2/crtend.o [edit] Just before hitting the 'send' button I tried to build gnugo with -mno-cygwin. It worked (i.e. it doesn't require cygwin1.dll to run). So I understand my setup is correct and the problem comes from gnucap alone. Does anybody have an idea about what could be the problem ? Is it possible that I'm linking by mistake with a library that requires cygwin1.dll ? Is there an issue with the order in which the libraries are linked ? From this you probably understand that I'm not an expert at debugging this kind of error... You've left out the actual error. I think that -lm is an alias of -lcygwin. Get rid of it. Neither Cygwin or MinGW has a seperate math library. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Conflict between libcygwin.a and GCC core libraries
Markus Gerwinski [EMAIL PROTECTED] wrote: Max Bowsher wrote: In short the error messages say, I get 'undefined reference's to QUITE a lot of functions, among them some essential gcc functions like __assert, __errno, pipe, kill, fork etc. 'fork' isn't available under MinGW. Good to know... Anyway, the other ones should be there, don't they? Actually, pipe and kill might not be. Don't know. You'd have to look and find out. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Error compiling: cc1plus.exe - Entry Point Not Found entry point putc_unlocked could not be located
--- Max Bowsher [EMAIL PROTECTED] wrote: Daryl Drome [EMAIL PROTECTED] wrote: The cygwin1.dll version is 1.3.15-1. putc_unlocked is present in 1.3.15-2. Get the latest version of Cygwin and the problem will probably go away. Sorry, I had the version number wrong. I just checked, and according to cygwin setup, I do have 1.3.15-2. D.D. __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SPEWS blocked me
Wu Yongwei [EMAIL PROTECTED] writes: OK, you might be right. Thanks that you at least provide a way to bypass the foolish anti-spam mechanism. The fact is that I hate the way SPEWS works. It thinks it is the crusade and refuses to remove individual IPs. I can't stand those folks. Their attitude sucks. But Christopher's right, it's really no big deal to register and get past the spam blocking for the cygwin list. -- scott evans :: www.antisleep.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Error compiling: cc1plus.exe - Entry Point Not Found entry point putc_unlocked could not be located
Daryl Drome [EMAIL PROTECTED] wrote: --- Max Bowsher [EMAIL PROTECTED] wrote: Daryl Drome [EMAIL PROTECTED] wrote: The cygwin1.dll version is 1.3.15-1. putc_unlocked is present in 1.3.15-2. Get the latest version of Cygwin and the problem will probably go away. Sorry, I had the version number wrong. I just checked, and according to cygwin setup, I do have 1.3.15-2. Then you must have an old version of cygwin1.dll somewhere in the PATH before the correct one. Get rid of it! Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: patch(1) (Win32) and path separators
On 19/11/2002 18:14 Larry Hall (RFK Partners, Inc) stood on a soap-box and preached to the unwashed masses: I have to assume that since you mention the Windows version that your talking about a native port and not the patch that's available through Cygwin. Duh! I'm more used to posting in Mozilla NGs and got into the habit of mentioning the platform, since Moz is multi-platform. A bit irrelevant for cygwin lists, eh? Regards, Parish -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Error compiling: cc1plus.exe - Entry Point Not Found entry point putc_unlocked could not be located
--- Max Bowsher [EMAIL PROTECTED] wrote: Daryl Drome [EMAIL PROTECTED] wrote: Sorry, I had the version number wrong. I just checked, and according to cygwin setup, I do have 1.3.15-2. Then you must have an old version of cygwin1.dll somewhere in the PATH before the correct one. Get rid of it! That's it. DLL hell again ... Thanks. D.D. __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Remote mounts not seen in remote bash shell
I have a Win2kAS box with the most recent Cygwin package installed. I am logged into the box with my own userid which has Administrator privileges. When I am running a local bash shell, that is on the console of the box, I can see remote drives with mount: $ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /cygdrive/c type user (binmode,noumount) h: on /cygdrive/h type user (binmode,noumount) j: on /cygdrive/j type user (binmode,noumount) The drives are also accessible via their mount locations -- //FILESERVER1/Home/jtwilley and //chez/jtwilley, respectively. When I am running a remote bash shell, that is via ssh'ing into the box from another computer, I cannot see remote drives with mount. The H: and J: drives are not visible, and they cannot be accessed via /cygdrive/j or //chez/jtwilley from the remote bash shell. How do I fix this? The whole reason I installed Cygwin was so I could ssh into the box, run a script stored on a remote machine and move files from one machine to another. This is not working as well as I'd hoped. I searched all over via Google and the FAQ and the User Guide and found nothing helpful. Jack. -- Jack Twilley // Tier 2 Support Engineer // Brightmail Inc. jtwilley at brightmail dot com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Setup 2.249.2.5 Hangs during Install from Local Directory
This is a handmade reply to a message posted on Sept 18, 2002 On Wed, 18 Sep 2002, John Carlyle- Clarke wrote: This problem seems to occur when the setup program tries to access a file for writing for which it does not have permission. Well, is there a chance you know also the name of the file. And is it really a single file or a directory ? Please, describe your problem along with any observations you have made, do not miss anything. We do not have the ability to read peoples mind, though some people think that we do :)) Btw have you tried a snapshot of setup.exe ? http://cygwin.com/setup-snapshots/ I'm having the same problem. Yes, I tried the only snapshot available (2.249.2.4), and it showed the same behavior. Here are the details: Setup 2.249.2.5 eats memory and hangs during Installation of some files. I'm simply trying to install the fvwm2 package that downloaded successfully. It appears some kind of infinite loop occurs during file extraction because setup appears to hang at 5% done and in Task Manager the setup.exe process just keeps growing in memory. Specifically, this is what setup is unable to extract: XFree86-bin-4.2.0-2 /usr/X11R6/bin/appres.exe Additionally, clicking cancel to stop the installation leads to: 'The instruction at 0x00422334 referenced memory at 0x73755c6e. The memory could not be read.' Clicking cancel on this box to debug and looking at the call stack in VS.NET reveals the following call stacks: thread 1: // thread that crashes setup.exe!00422334() setup.exe!0046b8be() setup.exe!0041ea1b() setup.exe!0040165a() setup.exe!0041ae6b() setup.exe!0041ca97() setup.exe!0041d796() setup.exe!0041dc7c() KERNEL32.DLL!_BaseThreadStart@8() + 0x52 thread 2: NTDLL.DLL!_ZwRaiseHardError@24() + 0xb KERNEL32.DLL!_UnhandledExceptionFilter@4() + 0x19c77 KERNEL32.DLL!_BaseProcessStart@4() + 0x4f53 thread 3 NTDLL.DLL!_NtQueryVirtualMemory@24() + 0xb KERNEL32.DLL!_ExitThread@4() + 0x75 KERNEL32.DLL!_BaseAttachComplete@4() + 0x38 KERNEL32.DLL!_BaseThreadStart@8() + 0x52 Any help? cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ramped CPU problem with fetchmail
On Tue, Nov 19, 2002 at 12:30:56AM -0700, Christian Weeks wrote: On Mon, Nov 18, 2002 at 09:32:47PM -0700, Christian Weeks wrote: [..stuff..] So why aren't you trying the solution that was proposed for the problem? This is, what?, the third time today that someone has posted saying that they've noticed the discussion while missing the fact that the problem is supposed to be fixed in the latest snapshots. Thank you for your reply. I have tried the proposed solution at your request (I downloaded and attempted each of the 13th, 14th, 15th and 16th snapshot fixes). The attached trace file is the result (it appears to be the same under the 15th and 16th snapshots- I did not bother generating for 13th 14th). It is still unfortunately not correctly functional. Instead of ramping my CPU (now I only see very small spikes of 100%) it aborts the fetchmail daemon. This is the log output from fetchmail: fetchmail: starting fetchmail 6.1.2 daemon fetchmail: couldn't find canonical DNS name of my.mail.server.com fetchmail: Query status=11 (DNS) fetchmail: sleeping at Tue Nov 19 00:10:16 2002 fetchmail: terminated with signal 14 I expected it to enter it's sleep/wake cycle, but it doesn't appear to do so. I'd say this was actually a potential problem with fetchmail but this may be fixed in the latest snapshot. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc-3.2-3: bootstrap build fails (HAVE_DECL_GETOPT not in config.h?)
Trying to build gcc-3.2-3 from scratch. Have the near latest versions of everything in cygwin (see cygcheck.out). Used the following configure command line: /usr/src/gcc-3.2-3/configure --with-program-suffix=-3.2-3-test --prefix=$HOM E/projects/install 21 My config.status file shows: #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: /usr/src/gcc-3.2-3/configure --with-gcc-version-trigger=/usr/src/gcc-3.2-3/g cc/version.c --host=i686-pc-cygwin --with-program-suffix=-3.2-3-test --prefi x=/home/mhcox/projects/install --norecursion # using mh-frag The build fails on compiling pure.cc in ./i686-pc-cygwin/libstdc++-v3/libsupc++ with the following output: /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /home/mhcox/projects/build/gcc-3.2-3/gcc/xgcc -shared-libgcc -B/home/mhcox/p rojects/build/gcc-3.2-3/gcc/ -nostdinc++ -L/home/mhcox/projects/build/gcc-3 .2-3/i686-pc-cygwin/libstdc++-v3/src -L/home/mhcox/projects/build/gcc-3.2-3/ i686-pc-cygwin/libstdc++-v3/src/.libs -B/home/mhcox/projects/install/i686-pc -cygwin/bin/ -B/home/mhcox/projects/install/i686-pc-cygwin/lib/ -isystem /home/mhcox/projects/install/i686-pc-cygwin/include -I/usr/src/gcc-3.2-3/lib stdc++-v3/../gcc -I/usr/src/gcc-3.2-3/libstdc++-v3/../include -I/home/mhcox/ projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/home/mhcox/projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3/include - I/usr/src/gcc-3.2-3/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location= once -ffunction-sections -fdata-sections -g-c /usr/src/gcc-3.2-3/libstdc++-v3/libsupc++/pure.cc /home/mhcox/projects/build/gcc-3.2-3/gcc/xgcc -shared-libgcc -B/home/mhcox/p rojects/build/gcc-3.2-3/gcc/ -nostdinc++ -L/home/mhcox/projects/build/gcc-3. 2-3/i686-pc-cygwin/libstdc++-v3/src -L/home/mhcox/projects/build/gcc-3.2-3/i 686-pc-cygwin/libstdc++-v3/src/.libs -B/home/mhcox/projects/install/i686-pc- cygwin/bin/ -B/home/mhcox/projects/install/i686-pc-cygwin/lib/ -isystem /home/mhcox/projects/install/i686-pc-cygwin/include -I/usr/src/gcc-3.2-3/lib stdc++-v3/../gcc -I/usr/src/gcc-3.2-3/libstdc++-v3/../include -I/home/mhcox/ projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/home/mhcox/projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3/include - I/usr/src/gcc-3.2-3/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -W all -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c /usr/src/gcc-3.2-3/libstdc++-v3/libsupc++/pure.cc -o pure.o cc1plus: warning: -ffunction-sections may affect debugging on some targets In file included from /usr/include/unistd.h:8, from /usr/src/gcc-3.2-3/libstdc++-v3/libsupc++/pure.cc:34: /usr/src/gcc-3.2-3/include/getopt.h:115: declaration of C function `int getopt()' conflicts with /usr/include/sys/unistd.h:125: previous declaration `int getopt(int, char* const*, const char*)' here make[4]: *** [pure.lo] Error 1 make[4]: Leaving directory `/home/mhcox/projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3/libsupc++' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/mhcox/projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3' make[2]: *** [all-recursive-am] Error 2 make[2]: Leaving directory `/home/mhcox/projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/mhcox/projects/build/gcc-3.2-3' make: *** [bootstrap] Error 2 Looking at /usr/src/gcc-3.2-3/include/getopt.h it looks like __GNU_LIBRARY__ and HAVE_DECL_GETOPT are not being defined/set: #if defined (__STDC__) __STDC__ /* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is undefined, we haven't run the autoconf check so provide the declaration without arguments. If it is 0, we checked and failed to find the declaration so provide a fully prototyped one. If it is 1, we found it so don't provide any declaration at all. */ #if defined (__GNU_LIBRARY__) || (defined (HAVE_DECL_GETOPT) !HAVE_DECL_GETOPT) /* Many other libraries have conflicting prototypes for getopt, with differences in the consts, in stdlib.h. To avoid compilation errors, only prototype getopt for the GNU C library. */ extern int getopt (int argc, char *const *argv, const char *shortopts); #else /* not __GNU_LIBRARY__ */ # if !defined (HAVE_DECL_GETOPT) extern int getopt ();line 115 (that conflicting getopt() seen by the compiler) # endif #endif /* __GNU_LIBRARY__ */ extern int getopt_long (int argc, char *const *argv, const char *shortopts, const struct option *longopts, int *longind); extern int getopt_long_only (int argc, char *const *argv, const char *shortopts, const struct
Re: .rhosts on W2K w/o ntsec
Thanks again for your help! What do you mean setting new userids? It is safe to turn ntsec off in the /etc/profile or ~/.bash_profile sourced by the login shell. Of course the login shell itself will still have ntsec on, so it needs to reexec itself after turning ntsec off. I was thinking of daemons such as inetd, sshd, etc. setting new user IDs (contexts, whatever) after the login as such has succeeded. I didn't have the time so far to look up how Cygwin handles this case, thus my concerns about inheriting the CYGWIN envionment variable. Given your question, I take it that Cygwin will pass the CYGWIN variable to all sub-processes regardless whether or not the user ID has changed. This would rule-out my biggest concern regarding different CYGWIN variable settings for inetd clients and local logins. Another problem would be that other services which don't start shells such as the IPC daemon, apache, etc. would end up using ntsec. Not sure if that's really a problem. At any rate that can be controlled with the -e argument of cygrunsrv, but I don't know what will happen in each case. The problem with this (regardless of the -e option in cygrunsrv) is that the environment being active for the service (e.g. CYGWIN=ntsec) cannot be changed at a later time unless the service starts some shell-like process which will execute something like /etc/profile. In other words, the service will execute with ntsec being active and there's no way to turn it off. Wouldn't it be a good idea to store uid and gid in the extended attributes as well and use them if ntsec is turned off? At least for me this would be the perfect solution They are, of course, but Cygwin does not report them when ntsec is off. Changing that behavior would probably hurt other users. Asking for a special cmueller field to CYGWIN is unlikely to yield a positive reply. Hmpff! I'm not asking for any special treatment for myself. If that was the case, I would take the source and implement whatever I think would be useful instead of going to the public cygwin mailing list Having said that, I agree that it's probably dangerous to simply change the current behaviour (i.e. UIDs and GIDs are stored in EAs but not used unless ntsec is turned on as well). However, it would be possible to safely change this behaviour based on a new token (e.g. ntea_uid or whatever). I have reread your original e-mail and I don't fully understand why nontsec helps you. The reasons you give are not compelling. Even with nontsec, the files you create are not owned by Administrators. Actually, they *are* owned by Administrators *if* they are created by Windows apps. As soon as a Windows user is part of the Administrators group, all files created by this user will automatically be owned by the Administrators group (again, I'm talking about Windows apps here, not Cygwin apps). I had problems in the past (around 1 year ago) with files created by JBuilder5 from Borland -- I had ntsec turned-on at this time and ran into problems when I committed the resulting files with cvs (Cygwin) because the source files were owned by Administrators and had stupid permissions (something like 0777). I thought quite a while about a solution for my dilemma and ended up using ntea nontsec because this is the only way how I can share Cygwin directories with Windows applications without ending up changing file permissions each time Windows programs have updated/created some files. Also, the directories created by Cygwin with ntsec do have inheritance turned on. In fact that inheritance determines the ACL of files created by Cygwin when ntsec is off, and also the ACL created by most Windows applications. Incidentally you can display these stupid permissions with getfacl and change them with setfacl, so you could add Administrators if needed. Hmmm it seems as if you mis-interpreted (is this a word?) my problem: The permissions set by Cygwin with ntsec are absolutely OK. I'm having problems with permissions set by *native* Windows programs when they create files in my Cygwin home directory Is your group Administrators? If not, wouldn't it help to change it to that? Yes, it is. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] New initscripts package available for download
New cygwin initscripts package available for download. The package is a System-V-like collection of system initialization scripts including a full-featured /etc/inittab. Initscripts package includes a sample script to start/stop sshd daemon. To install the package, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. You'll find initscripts listed in the System category. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . I would appreciate it if you would use this mailing list rather than emailing me directly. Sergey Okhapkin Somerset, NJ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated sysvinit packake available for download
Updated sysvinit package available for download. What's new: postinstall script modified to create /var/log and /var/run dirs and empty utmp/wtmp files (if not exist). Removed some manual pages Sergey Okhapkin Somerset, NJ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc-3.2-3: bootstrap build fails (HAVE_DECL_GETOPT not in config.h?)
Michael, I have encountered the same problem on my setup. Regards, Nigel Stewart Trying to build gcc-3.2-3 from scratch. Have the near latest versions of everything in cygwin (see cygcheck.out). /home/mhcox/projects/build/gcc-3.2-3/gcc/xgcc -shared-libgcc -B/home/mhcox/p rojects/build/gcc-3.2-3/gcc/ -nostdinc++ -L/home/mhcox/projects/build/gcc-3. 2-3/i686-pc-cygwin/libstdc++-v3/src -L/home/mhcox/projects/build/gcc-3.2-3/i 686-pc-cygwin/libstdc++-v3/src/.libs -B/home/mhcox/projects/install/i686-pc- cygwin/bin/ -B/home/mhcox/projects/install/i686-pc-cygwin/lib/ -isystem /home/mhcox/projects/install/i686-pc-cygwin/include -I/usr/src/gcc-3.2-3/lib stdc++-v3/../gcc -I/usr/src/gcc-3.2-3/libstdc++-v3/../include -I/home/mhcox/ projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/home/mhcox/projects/build/gcc-3.2-3/i686-pc-cygwin/libstdc++-v3/include - I/usr/src/gcc-3.2-3/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -W all -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c /usr/src/gcc-3.2-3/libstdc++-v3/libsupc++/pure.cc -o pure.o cc1plus: warning: -ffunction-sections may affect debugging on some targets In file included from /usr/include/unistd.h:8, from /usr/src/gcc-3.2-3/libstdc++-v3/libsupc++/pure.cc:34: /usr/src/gcc-3.2-3/include/getopt.h:115: declaration of C function `int getopt()' conflicts with /usr/include/sys/unistd.h:125: previous declaration `int getopt(int, char* const*, const char*)' here -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc-3.2-3: bootstrap build fails (HAVE_DECL_GETOPT not in config.h?)
On Wed, Nov 20, 2002 at 10:14:59AM +1100, Nigel Stewart Fiona Smith wrote: Michael, I have encountered the same problem on my setup. Regards, I have not encountered the same problem in my setup. HTH, cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ramped CPU problem with fetchmail
[ .. noise .. ] I'd say this was actually a potential problem with fetchmail but this may be fixed in the latest snapshot. Many thanks, the latest snapshot appears as if it may resolve this problem. It certainly isn't spinning wildly anymore. Thanks again, Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
'less' can't determine terminal size?
Hi, All, :)
I updated my installation recently, and I'm now suffering from an odd
problem with less. I hope that somebody can point me in a direction for my
own investigations. I had been running 1.3.12, I believe - after the
refresh on Friday my cygwin1.dll is at 1.3.15. bash is 2.05b.0(7). I run
bash via rxvt-2.7.2-14. Here's my rxvt run command:
C:\WINNT\system32\cmd.exe /c start C:\cygwin\bin\rxvt.exe -tn rxvt -fg
grey -bg black -fn Fixedsys -sr -sl 5000 -e /bin/bash --login -i
I believe these environment variables are relevant:
TERM=rxvt
LESS=iFMSX# 8
CYGWIN=tty nontsec
My problem is this: 'less' no longer properly updates the screen when I
scroll through a file. Paging forward is fine, but when trying to scroll by
line ('j' or 'e'), 'less' tells me that it is moving through the file, but
the display doesn't update. The status line (which '-M' enables) shows the
currently displayed lines changing ('75-97', '76-98', 77-99', etc.), but the
displayed data doesn't change. Paging forward again causes the screen to
update properly.
Also, when I scroll backward ('k'), the normally-blank command line (bottom
line) becomes filled with the previous status line. So, if I'm at the
bottom of the file and the bottom two lines are:
=
.bash_profile lines 105-127/127 (END)
=
Then, after pressing 'k', the bottom two lines will read:
=
.bash_profile lines 104-126/127 99%
.bash_profile lines 105-127/127 (END)
=
This *seems* to mean to me that 'less' can't determine the right size my
rxvt window. My theory is reinforced because 'less' suddenly finds its
brains again when I resize the window manually.
How should I go about fixing this? Thanks in advance for any pointers,
---Jason Tiller
*
This communication may contain information that is proprietary, privileged,
confidential or legally exempt from disclosure. If you are not a named
addressee, you are notified that you are not authorized to read, print,
retain, copy or disseminate this communication without the consent of the
sender and that doing so may be unlawful. If you have received this
communication in error, please notify the sender via return e-mail and
delete it from your computer. Thank you. St. Jude Medical, Inc.
*
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: 'less' can't determine terminal size?
Hi, Sergei, :)
Thank you for the speedy response!
On Tue, 19 Nov 2002, Sergei Okhapkin wrote:
What is the output of stty -a inside rxvt window?
$ stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = undef;
eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -tostop echoctl echoke
This is interesting, since the size of the window (as shown when I
turn on line numbers ('-N') in 'less') is actually *25* lines high
(columns are correct at 80).
After resizing the rxvt window to increase the number of lines by 1,
'stty -a' correctly shows that there are 26 rows. Weird!
Thanks for any ideas,
---Jason
-Original Message-
From: Tiller, Jason [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 9:04 PM
To: '[EMAIL PROTECTED]'
Subject: 'less' can't determine terminal size?
Hi, All, :)
I updated my installation recently, and I'm now suffering from an odd
problem with less. I hope that somebody can point me in a direction for
my own investigations. I had been running 1.3.12, I believe - after the
refresh on Friday my cygwin1.dll is at 1.3.15. bash is 2.05b.0(7). I
run bash via rxvt-2.7.2-14. Here's my rxvt run command:
C:\WINNT\system32\cmd.exe /c start C:\cygwin\bin\rxvt.exe -tn rxvt -fg
grey -bg black -fn Fixedsys -sr -sl 5000 -e /bin/bash --login -i
I believe these environment variables are relevant:
TERM=rxvt
LESS=iFMSX# 8
CYGWIN=tty nontsec
My problem is this: 'less' no longer properly updates the screen when I
scroll through a file. Paging forward is fine, but when trying to
scroll by line ('j' or 'e'), 'less' tells me that it is moving through
the file, but the display doesn't update. The status line (which '-M'
enables) shows the currently displayed lines changing ('75-97', '76-98',
77-99', etc.), but the displayed data doesn't change. Paging forward
again causes the screen to update properly.
Also, when I scroll backward ('k'), the normally-blank command line
(bottom
line) becomes filled with the previous status line. So, if I'm at the
bottom of the file and the bottom two lines are:
=
.bash_profile lines 105-127/127 (END)
=
Then, after pressing 'k', the bottom two lines will read:
=
.bash_profile lines 104-126/127 99%
.bash_profile lines 105-127/127 (END)
=
This *seems* to mean to me that 'less' can't determine the right size my
rxvt window. My theory is reinforced because 'less' suddenly finds its
brains again when I resize the window manually.
How should I go about fixing this? Thanks in advance for any pointers,
---Jason Tiller
*
This communication may contain information that is proprietary,
privileged, confidential or legally exempt from disclosure. If you are
not a named addressee, you are notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so may be unlawful. If you have
received this communication in error, please notify the sender via
return e-mail and delete it from your computer. Thank you. St. Jude
Medical, Inc.
*
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: 'less' can't determine terminal size?
Hi, Again, Sergei, :)
On Tue, 19 Nov 2002, Sergei Okhapkin wrote:
What is the output of stty -a inside rxvt window?
In my fiddling, I tried adding '-geometry 80x25' to my rxvt
invocation just to see what would happen. Strangest thing - my window
size was *26* lines. When I set -geometry to 80x24, rxvt opened up
a *25* line window.
Any idea why this might be happening? In all cases, if I manually
resize the window, this seems to sync things up and everything's
kosher after that.
Thanks for your help,
---Jason
-Original Message-
From: Tiller, Jason [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 9:04 PM
To: '[EMAIL PROTECTED]'
Subject: 'less' can't determine terminal size?
Hi, All, :)
I updated my installation recently, and I'm now suffering from an odd
problem with less. I hope that somebody can point me in a direction for
my own investigations. I had been running 1.3.12, I believe - after the
refresh on Friday my cygwin1.dll is at 1.3.15. bash is 2.05b.0(7). I
run bash via rxvt-2.7.2-14. Here's my rxvt run command:
C:\WINNT\system32\cmd.exe /c start C:\cygwin\bin\rxvt.exe -tn rxvt -fg
grey -bg black -fn Fixedsys -sr -sl 5000 -e /bin/bash --login -i
I believe these environment variables are relevant:
TERM=rxvt
LESS=iFMSX# 8
CYGWIN=tty nontsec
My problem is this: 'less' no longer properly updates the screen when I
scroll through a file. Paging forward is fine, but when trying to
scroll by line ('j' or 'e'), 'less' tells me that it is moving through
the file, but the display doesn't update. The status line (which '-M'
enables) shows the currently displayed lines changing ('75-97', '76-98',
77-99', etc.), but the displayed data doesn't change. Paging forward
again causes the screen to update properly.
Also, when I scroll backward ('k'), the normally-blank command line
(bottom
line) becomes filled with the previous status line. So, if I'm at the
bottom of the file and the bottom two lines are:
=
.bash_profile lines 105-127/127 (END)
=
Then, after pressing 'k', the bottom two lines will read:
=
.bash_profile lines 104-126/127 99%
.bash_profile lines 105-127/127 (END)
=
This *seems* to mean to me that 'less' can't determine the right size my
rxvt window. My theory is reinforced because 'less' suddenly finds its
brains again when I resize the window manually.
How should I go about fixing this? Thanks in advance for any pointers,
---Jason Tiller
*
This communication may contain information that is proprietary,
privileged, confidential or legally exempt from disclosure. If you are
not a named addressee, you are notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so may be unlawful. If you have
received this communication in error, please notify the sender via
return e-mail and delete it from your computer. Thank you. St. Jude
Medical, Inc.
*
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: 'less' can't determine terminal size?
Looks like rxvt bug. Did you try xterm instead?
-Original Message-
From: Jason Tiller [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 9:29 PM
To: [EMAIL PROTECTED]
Subject: RE: 'less' can't determine terminal size?
Hi, Again, Sergei, :)
On Tue, 19 Nov 2002, Sergei Okhapkin wrote:
What is the output of stty -a inside rxvt window?
In my fiddling, I tried adding '-geometry 80x25' to my rxvt invocation
just to see what would happen. Strangest thing - my window size was
*26* lines. When I set -geometry to 80x24, rxvt opened up a *25* line
window.
Any idea why this might be happening? In all cases, if I manually
resize the window, this seems to sync things up and everything's
kosher after that.
Thanks for your help,
---Jason
-Original Message-
From: Tiller, Jason [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 9:04 PM
To: '[EMAIL PROTECTED]'
Subject: 'less' can't determine terminal size?
Hi, All, :)
I updated my installation recently, and I'm now suffering from an odd
problem with less. I hope that somebody can point me in a direction
for my own investigations. I had been running 1.3.12, I believe -
after the refresh on Friday my cygwin1.dll is at 1.3.15. bash is
2.05b.0(7). I run bash via rxvt-2.7.2-14. Here's my rxvt run
command:
C:\WINNT\system32\cmd.exe /c start C:\cygwin\bin\rxvt.exe -tn rxvt
-fg grey -bg black -fn Fixedsys -sr -sl 5000 -e /bin/bash --login -i
I believe these environment variables are relevant:
TERM=rxvt
LESS=iFMSX# 8
CYGWIN=tty nontsec
My problem is this: 'less' no longer properly updates the screen when
I scroll through a file. Paging forward is fine, but when trying to
scroll by line ('j' or 'e'), 'less' tells me that it is moving through
the file, but the display doesn't update. The status line (which '-M'
enables) shows the currently displayed lines changing ('75-97',
'76-98', 77-99', etc.), but the displayed data doesn't change. Paging
forward again causes the screen to update properly.
Also, when I scroll backward ('k'), the normally-blank command line
(bottom
line) becomes filled with the previous status line. So, if I'm at the
bottom of the file and the bottom two lines are:
=
.bash_profile lines 105-127/127 (END)
=
Then, after pressing 'k', the bottom two lines will read:
=
.bash_profile lines 104-126/127 99%
.bash_profile lines 105-127/127 (END)
=
This *seems* to mean to me that 'less' can't determine the right size
my rxvt window. My theory is reinforced because 'less' suddenly finds
its brains again when I resize the window manually.
How should I go about fixing this? Thanks in advance for any
pointers,
---Jason Tiller
*
This communication may contain information that is proprietary,
privileged, confidential or legally exempt from disclosure. If you
are not a named addressee, you are notified that you are not
authorized to read, print, retain, copy or disseminate this
communication without the consent of the sender and that doing so may
be unlawful. If you have received this communication in error, please
notify the sender via return e-mail and delete it from your computer.
Thank you. St. Jude Medical, Inc.
*
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: 'less' can't determine terminal size?
Hi, Sergei, :)
On Tue, 19 Nov 2002, Sergei Okhapkin wrote:
Looks like rxvt bug. Did you try xterm instead?
I don't know if I'd be so quick to implicate rxvt - it could just as
easily be my setup. I would hardly describe myself as sophisticated
in these terminal issues - heck, most of the Unix tty model is beyond
me.
Setting '-tn' in the rxvt invocation to xterm (as opposed to rxvt)
made no difference that I could detect.
Perhaps it is a bug, but I'd like to more digging, if you or someone
else could point me at things to target.
Thanks,
---Jason
-Original Message-
From: Jason Tiller [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 9:29 PM
To: [EMAIL PROTECTED]
Subject: RE: 'less' can't determine terminal size?
Hi, Again, Sergei, :)
On Tue, 19 Nov 2002, Sergei Okhapkin wrote:
What is the output of stty -a inside rxvt window?
In my fiddling, I tried adding '-geometry 80x25' to my rxvt invocation
just to see what would happen. Strangest thing - my window size was
*26* lines. When I set -geometry to 80x24, rxvt opened up a *25* line
window.
Any idea why this might be happening? In all cases, if I manually
resize the window, this seems to sync things up and everything's
kosher after that.
Thanks for your help,
---Jason
-Original Message-
From: Tiller, Jason [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 9:04 PM
To: '[EMAIL PROTECTED]'
Subject: 'less' can't determine terminal size?
Hi, All, :)
I updated my installation recently, and I'm now suffering from an odd
problem with less. I hope that somebody can point me in a direction
for my own investigations. I had been running 1.3.12, I believe -
after the refresh on Friday my cygwin1.dll is at 1.3.15. bash is
2.05b.0(7). I run bash via rxvt-2.7.2-14. Here's my rxvt run
command:
C:\WINNT\system32\cmd.exe /c start C:\cygwin\bin\rxvt.exe -tn rxvt
-fg grey -bg black -fn Fixedsys -sr -sl 5000 -e /bin/bash --login -i
I believe these environment variables are relevant:
TERM=rxvt
LESS=iFMSX# 8
CYGWIN=tty nontsec
My problem is this: 'less' no longer properly updates the screen when
I scroll through a file. Paging forward is fine, but when trying to
scroll by line ('j' or 'e'), 'less' tells me that it is moving through
the file, but the display doesn't update. The status line (which '-M'
enables) shows the currently displayed lines changing ('75-97',
'76-98', 77-99', etc.), but the displayed data doesn't change. Paging
forward again causes the screen to update properly.
Also, when I scroll backward ('k'), the normally-blank command line
(bottom
line) becomes filled with the previous status line. So, if I'm at the
bottom of the file and the bottom two lines are:
=
.bash_profile lines 105-127/127 (END)
=
Then, after pressing 'k', the bottom two lines will read:
=
.bash_profile lines 104-126/127 99%
.bash_profile lines 105-127/127 (END)
=
This *seems* to mean to me that 'less' can't determine the right size
my rxvt window. My theory is reinforced because 'less' suddenly finds
its brains again when I resize the window manually.
How should I go about fixing this? Thanks in advance for any
pointers,
---Jason Tiller
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: ls problem
- Original Message - From: Igor Pechtchanski [EMAIL PROTECTED] To: Carlo Florendo [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 8:56 AM Subject: Re: ls problem Try running 'ls -l' first to pull the directory contents and the stat records for the files into memory, and then repeating both 'time ls' and 'time ls -l' commands, and see if that makes a difference in the timings. Ok, done! I actually repeated the operation many times. However, there is still considerable difference. I'm wondering why ls -l is slower now than my previous version of cygwin. They're both using fileutils-4.1.1. I try the same thing in my linux box and doing ls -l doesn't take that slow. It's only with this new version of cygwin that I experienced a slow response to ls -l. FYI, 'ls -l' is *supposed* to be slower, because it accesses more information. On my machine (P3 700MHz running Win2k Pro SP3), the timings are as follows: On Tue, 19 Nov 2002, Carlo Florendo wrote: That's right. It's supposed to be slower because it accesses more information but the speed should not be very signiicantly slower. BTW, I'm using a P4 1.7GHz, Win2k. My home PC is a P3 600MHz and it runs on the older version of cygwin. Doing an ls -l on the slower P3 PC with the older version of cygwin is still faster than doing a ls -l on my P4 with the newer version of cygwin. What actually happens is that after ls prints the total number, it processes for a while--this is where the slower part begins, then outputs the directory entries. It takes more than 1 second to print the directory entries. Still any hints? Thanks a lot! Carlo Carlo Florendo Astra (Philippines), Inc. Email: [EMAIL PROTECTED] Web: http://www.astra.ph -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls problem
I don't know how to interpret the output of strace so I just included it here as ls-output.bz2. I hope this helps us see the problem. Thanks! - Original Message - From: Randall R Schulz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 19, 2002 7:45 AM Subject: Re: ls problem Carlo, I think your next step must be to run ls under strace and see where the excess time (presumably idle time) is going. Randall Schulz Mountain View, CA USA At 17:00 2002-11-19, Carlo Florendo wrote: Hi Igor, I tried disabling ntsec and ls -l is still slow. I'm using 1.3.15-cygwin-1-3-15-1. ls -l and ls -ln takes almost the same amount of time.On a directory with 3 short text files, the difference, when I timed ls -l and ls -b, is still considerable. fcarlo@ZEUS~ $ time ls -b a b test real0m0.024s user0m0.030s sys 0m0.015s fcarlo@ZEUS ~ $ time ls -l total 11 -rw-r--r--1 fcarlo None5 Nov 19 13:58 a -rw-r--r--1 fcarlo None5 Nov 19 13:58 b -rw-r--r--1 fcarlo None 8283 Nov 19 13:59 test real0m1.819s user0m0.030s sys 0m0.000s Best Regards, Carlo Florendo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ls-output.bz2 Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
CYGWIN=codepage:oem in User's Guide
After researching a bit on the Internet, I think I understand what the codepage is and how it works in the CYGWIN environment variable. Please read this snippit of text meant eventually for http://cygwin.com/cygwin-ug-net/using-cygwinenv.html and give me any feedback about any errors: icodepage:[ansi|oem]/i - Windows console applications use one of two character sets for drawing characters, ansi or oem. The first is the default, called ansi since the Windows 1.0 set was the ANSI Latin1 (ISO 8859-1) standard, though the character sets have since diverged from any standard. The second character sets are the older, DOS-based character set, called oem since originally they were encoded on the firmware of IBM PCs by OEMs. If you find that some characters (especially non-US or 'graphical' ones) do not display correctly in Cygwin, you can manually set which codepage you want to use. __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls problem
On Wed, Nov 20, 2002 at 11:48:10AM -0800, Carlo Florendo wrote: I don't know how to interpret the output of strace so I just included it here as ls-output.bz2. I hope this helps us see the problem. There is a huge delay accessing F:\cygwin\usr\local\etc\zoneinfo\posixrules, on your F: drive. What's that? Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls problem
On Tue, Nov 19, 2002 at 10:56:49PM -0500, Pierre A. Humblet wrote: On Wed, Nov 20, 2002 at 11:48:10AM -0800, Carlo Florendo wrote: I don't know how to interpret the output of strace so I just included it here as ls-output.bz2. I hope this helps us see the problem. There is a huge delay accessing F:\cygwin\usr\local\etc\zoneinfo\posixrules, on your F: drive. What's that? To partially answer my own question, /usr/local/etc/zoneinfo comes from localtime.cc #define TZDIR /usr/local/etc/zoneinfo /* Time zone object file directory */ There is a lot about that on google, this is the first hit http://mail-index.netbsd.org/netbsd-bugs/1995/08/21/0006.html That doesn't explain the F: drive. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls problem
On Tue, Nov 19, 2002 at 11:09:33PM -0500, Pierre A. Humblet wrote: On Tue, Nov 19, 2002 at 10:56:49PM -0500, Pierre A. Humblet wrote: On Wed, Nov 20, 2002 at 11:48:10AM -0800, Carlo Florendo wrote: I don't know how to interpret the output of strace so I just included it here as ls-output.bz2. I hope this helps us see the problem. There is a huge delay accessing F:\cygwin\usr\local\etc\zoneinfo\posixrules, on your F: drive. What's that? To partially answer my own question, /usr/local/etc/zoneinfo comes from localtime.cc #define TZDIR /usr/local/etc/zoneinfo /* Time zone object file directory */ There is a lot about that on google, this is the first hit http://mail-index.netbsd.org/netbsd-bugs/1995/08/21/0006.html That doesn't explain the F: drive. The delay is apparently ls doing things that haven't been straced. I don't know what could be causing the delay. It would be interesting to see what the task manager says is happening during this time. Does ls spike the CPU? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls problem
Pierre, I think this probably explains the F: drive: ** Program name: F:\cygwin\bin\ls.exe (1728) App version: 1001.8, api: 0.34 DLL version: 1003.13, api: 0.62 DLL build:2002-10-13 23:15 OS version: Windows NT-5.0 Date/Time:2002-11-20 10:53:49 ** In other words, Carlo's Cygwin installation in on the F: drive. Randall Schulz Mountain View, CA USA At 20:09 2002-11-19, Pierre A. Humblet wrote: ... That doesn't explain the F: drive. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: ls problem
He put it of F Drive. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Pierre A. Humblet Sent: Tuesday, November 19, 2002 10:10 PM To: [EMAIL PROTECTED] Subject: Re: ls problem On Tue, Nov 19, 2002 at 10:56:49PM -0500, Pierre A. Humblet wrote: On Wed, Nov 20, 2002 at 11:48:10AM -0800, Carlo Florendo wrote: I don't know how to interpret the output of strace so I just included it here as ls-output.bz2. I hope this helps us see the problem. There is a huge delay accessing F:\cygwin\usr\local\etc\zoneinfo\posixrules, on your F: drive. What's that? To partially answer my own question, /usr/local/etc/zoneinfo comes from localtime.cc #define TZDIR /usr/local/etc/zoneinfo /* Time zone object file directory */ There is a lot about that on google, this is the first hit http://mail-index.netbsd.org/netbsd-bugs/1995/08/21/0006.html That doesn't explain the F: drive. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
