Re: how to remove CYGWINsshd win2k service
On Mar 31 02:45, Markus Sch?nhaber wrote: > Am Donnerstag, 31. M?rz 2005 02:34 schrieb Markus Sch?nhaber: > > Am Donnerstag, 31. M?rz 2005 01:39 schrieb Hunter Peress: > > > while c:\cygwin was still there, i reinstalled cygwin to c:\cgywin3. > > > > > > the ssh service in services namely CYGWINsshd still points to the now > > > deleted c:\cygwin\bin\cygrunsrv.exe so how can i remove the service? > > > > Use cygrunsrv: > > > > $ cygrunsrv --help > > > > Usage: cygrunsrv [OPTION]... > > > > Main options: Exactly one is required. > > -I, --install Installes a new service named . > > -R, --removeRemoves a service named . > > -S, --start Starts a service named . > > [...] > > > Oh, well... xyz is gone - what should I use instead? Use xyz! > I should practice reading. > But nevertheless, cygrunsrv.exe from your new installation should work. If it > does not, you can still use something like sc. The newly installed cygrunsrv will do quite well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot link ___assert, __impure_ptr with -mno-cygwin
Matt Olson wrote: > Thanks, folks. What was mysterious is now mundane. > > Now to find a version of SDL that builds with Cygwin. Anyone have > experience with that, just offhand? http://www.cygwin.com/ml/cygwin/2004-10/msg01145.html Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot link ___assert, __impure_ptr with -mno-cygwin
On Wed, Mar 30, 2005 at 06:33:53PM -0800, Matt Olson wrote: >Now to find a version of SDL that builds with Cygwin. Anyone have >experience with that, just offhand? As strange as it sounds, non-cygwin applications are not really a topic for this mailing list. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: recv and errno during a connection reset/closed by peert
On Wed, 30 Mar 2005, Brian Ford wrote: On Tue, 29 Mar 2005, Peter A. Castro wrote: On Tue, 29 Mar 2005, Brian Ford wrote: On Tue, 29 Mar 2005, Peter Stephens wrote: I have thought about your suggestion and it makes a lot of sense. It seems like your suggestion would be very portable. A good suggestion and the most likely route for me at this point. Not to me. Maybe I'm missing something, but it seems you are going to a lot of effort to poorly recreate poll/select? Why? A zero length return on a stream socket always means that the peer has closed its socket for writing. It may, however, still be open for reading (I don't remember the syscalls for doing such, but it can be done). And I'm saying experience shows to the contrary. A zero return on a datagram socket always means that a zero length message has been received. We're talking stream, not datagram here. Counting zero returns is a poor hack at best and makes no sense to me since it never gives you any more information. Considering its a very simply solution to a real problem, what makes it a poor hack? If you are doing sequential, non multi-plexed, reads why do poll or select? You don't need to. Sitting in read is more optimal and the read should return either data or an error. Ok. The flaw in recv is that it returns a non-error non-data status. It's not a flaw, it's the design (see above). Yes, and I've never been very happy with it. If the connection was closed and there's no more data left to return, I'd prefer recv returned -1 with ENODATA or ENOTCONN for the errno. But, it's not likely recv's semantics will ever be changed. Perhaps it would be better to switch to using read() instead of recv? They usually have exactly the same semantics. Note the word "usually". Not "always". -- Brian Ford -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: recv and errno during a connection reset/closed by peer
On Wed, 30 Mar 2005, Brian Ford wrote: On Tue, 29 Mar 2005, Peter A. Castro wrote: On Tue, 29 Mar 2005, Brian Ford wrote: If you are doing a normal blocking recv without MSG_PEEK, any return of 0 should mean a closed connection AFAIK. Unfortunately that's not true for all implementation. It's legal for a zero length data object to be sent. The network simply sends a header with no payload in it, but it's passed through the network anyways and is presented to the receiver. The receiver, which might be blocking at the time, will return from the call and get zero length data, but the connection is still valid at this point. I've seen AS/400's do just this sending zero length data to an AIX box. If the sender closes the connection normally, then subsequent calls to recv return zero with no indication that the connection is closed. Call it a bug if you want, but that's how it works. I agree that zero length data can be sent, but only for UDP or datagram based sockets, not for TCP or stream based ones (nothing denotes a message here). Even then, they are only sent by application choice, not just randomly by the OS. Whether a connection is open or closed in this case has little meaning. Nope, sorry, the example I cited above was using TCP, and wasn't really the applications choice (as I wrote both the server and client apps on both ends in this example, I can tell you the server app did not send zero byte data, but the client got a zero byte return after a previous non-zero byte return). The network stack on the AS/400 is rather awful and does send empty segments at odd times. It's a real life example. Unfortunately it's neither Cygwin nor Linux, and so likely not relevent for the OP. -- Brian Ford -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot link ___assert, __impure_ptr with -mno-cygwin
On Tue, 29 Mar 2005 13:48:49 -0500, Christopher Faylor <[EMAIL PROTECTED]> wrote: > On Tue, Mar 29, 2005 at 01:30:00PM -0500, Williams, Gerald S (Jerry) wrote: > >Matt Olson wrote: > >> Unfortunately, while "compile .o files with -mno-cygwin" fixes my toy > >> example, it doesn't help the real code I'm trying to build: > >[...] > >> If the problem is object files being compiled without -mno-cygwin and > >> linked with it, do I need to make sure that all of the (static?) > >> libraries I link with are also compiled with -mno-cygwin? > > > >Yes, that's no doubt what's going on. You are trying to link > >some object files that depend on the Cygwin runtime library > >and others that depend on the MinGW library. If you can, you > >should choose one or the other entirely, which should resolve > >your link issues. > > In general, you can't mix cygwin and non-cygwin libraries. Thanks, folks. What was mysterious is now mundane. Now to find a version of SDL that builds with Cygwin. Anyone have experience with that, just offhand? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
how to remove CYGWINsshd win2k service
while c:\cygwin was still there, i reinstalled cygwin to c:\cgywin3. the ssh service in services namely CYGWINsshd still points to the now deleted c:\cygwin\bin\cygrunsrv.exe so how can i remove the service? since when i run ssh-host-config in the new cygwin , it skips the installing-sshd-as-a-service step. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to remove CYGWINsshd win2k service
Am Donnerstag, 31. März 2005 01:39 schrieb Hunter Peress: > while c:\cygwin was still there, i reinstalled cygwin to c:\cgywin3. > > the ssh service in services namely CYGWINsshd still points to the now > deleted c:\cygwin\bin\cygrunsrv.exe so how can i remove the service? > Use cygrunsrv: $ cygrunsrv --help Usage: cygrunsrv [OPTION]... Main options: Exactly one is required. -I, --install Installes a new service named . -R, --removeRemoves a service named . -S, --start Starts a service named . [...] Regards mks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: /proc/self/exename -> exe ? (Re: Retrieving name of executable)
... but perhaps you can deprecate it. For example, have it take an ever increasing amount of time to open each time it's referenced :-) stephan(); -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: Tuesday, March 29, 2005 1:12 AM To: cygwin@cygwin.com Subject: Re: /proc/self/exename -> exe ? (Re: Retrieving name of executable) On Mar 29 09:47, Chris January wrote: > Corinna Vinschen wrote: > >The old exename was a file containing the path, the new exe is a symlink > >pointing to the binary. This is how it's done on Linux. > > Maybe exename should be kept for backwards compatibility? Sigh. Ok, I reverted the removal of exename. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to remove CYGWINsshd win2k service
Am Donnerstag, 31. März 2005 02:34 schrieb Markus Schönhaber: > Am Donnerstag, 31. März 2005 01:39 schrieb Hunter Peress: > > while c:\cygwin was still there, i reinstalled cygwin to c:\cgywin3. > > > > the ssh service in services namely CYGWINsshd still points to the now > > deleted c:\cygwin\bin\cygrunsrv.exe so how can i remove the service? > > Use cygrunsrv: > > $ cygrunsrv --help > > Usage: cygrunsrv [OPTION]... > > Main options: Exactly one is required. > -I, --install Installes a new service named . > -R, --removeRemoves a service named . > -S, --start Starts a service named . > [...] > Oh, well... xyz is gone - what should I use instead? Use xyz! I should practice reading. But nevertheless, cygrunsrv.exe from your new installation should work. If it does not, you can still use something like sc. Regards mks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygexec mounted binaries don't inherit PATH during dynamic loading
On Wed, Mar 30, 2005 at 11:01:10AM -0500, Christopher Faylor wrote: >On Tue, Mar 29, 2005 at 09:33:49PM -0800, Brian Dessent wrote: >>So my question is simply this: in the case of spawning a cygexec-mounted >>binary, shouldn't build_env at least fill in PATH from the calling >>process' value, so that Windows can do its runtime DLL loading? > >Yes, it should. I've been closing my eyes to this problem for a while but >this is the second time it's been reported in the span of a week (the other >time was over in the crossgcc mailing list). > >There were several problems with the handling of PATH and other special >environment variables. I hope I have fixed all of them in CVS. A new >snapshot is being generated now. I can't believe that I didn't notice this, but after not sleeping all night running over various ways to fix this problem, I ended up "fixing" it by exporting *only* the PATH environment variable to a cygexec binary. Then once I fixed that, I reintroduced the lack of SYSTEMROOT so none of my network apps worked. What fun. Anyway, I'm regenerating the snapshot now with, hopefully, a better fix. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC header libraries ... ?
On Wed, 30 Mar 2005 12:30:45 -0800, Jacob Lane, MCP <[EMAIL PROTECTED]> wrote: > Excellent ... now we're getting somewhere! ;-) > > So, my follow-up question is: did you just know that from prior expereince, > or were you able to look that up somwhere? > > Jake > > "Corinna Vinschen" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > On Mar 30 07:54, Jacob Lane, MCP wrote: > > > All, > > > > > > Sorry if this is a newb question, but I am somwhat new to Cygwin and > trying > > > to write / compile programs using GCC. One thing I noticed is that when > I > > > try to compile code from others, I seem to be missing some header > libraries. > > > > > > For example, in one recent program: > > > > > > #include > > > > > > I have had others tell me that on their native Linux installs, they have > the > > > nameser.h library -- so it seems to be just me (using Cygwin) that is > having > > > the issue. > > > > That's not a Cygwin problem. You just missed to install the appropriate > > development packages. In the above case you'll get the file by installing > > minires-devel. > > > > > > Corinna > > > > -- > > Corinna Vinschen Please, send mails regarding Cygwin to > > Cygwin Project Co-Leader mailto:cygwin@cygwin.com > > Red Hat, Inc. > > Some people might just know that, but we mortals who don't can find it on the Cygwin Package Search at: http://cygwin.com/packages/ (You can also get to it from the links on the left side of http://www.cygwin.com). >From there, search for "nameser.h", or even "arpa/nameser.h" to search a little more precisely. To avoid the likely confusion for this particular case, note that there are a number of -src packages listed, including cygwin--src that include that file as well. Generally, you don't want the -src packages unless you intend to build that particular package, so that the minires-devel module mentioned previously. Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC header libraries ... ?
Excellent ... now we're getting somewhere! ;-) So, my follow-up question is: did you just know that from prior expereince, or were you able to look that up somwhere? Jake "Corinna Vinschen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Mar 30 07:54, Jacob Lane, MCP wrote: > > All, > > > > Sorry if this is a newb question, but I am somwhat new to Cygwin and trying > > to write / compile programs using GCC. One thing I noticed is that when I > > try to compile code from others, I seem to be missing some header libraries. > > > > For example, in one recent program: > > > > #include > > > > I have had others tell me that on their native Linux installs, they have the > > nameser.h library -- so it seems to be just me (using Cygwin) that is having > > the issue. > > That's not a Cygwin problem. You just missed to install the appropriate > development packages. In the above case you'll get the file by installing > minires-devel. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader mailto:cygwin@cygwin.com > Red Hat, Inc. > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
On Wed, Mar 30, 2005 at 11:20:16AM -0800, Jim Kleckner wrote: >Christopher Faylor wrote: > >>On Wed, Mar 30, 2005 at 09:57:44AM -0800, Jim Kleckner wrote: > >>>Then strike the link text and limit it to the workaround of adding >>>the bin to the system path. My text was a suggested starting point. >> >>i.e., a workaround. >> The solution that the DLL has to be in the system path is not required for a sanctioned Cygwin release. But, then, we've seen before that clamwin insists on running in a non-cygwin environment. I don't want to be in the business of adding advice to the FAQ for fixing up other people's problems. >>> >>>Nobody said the workaround was required. >> >> >>See above. > >Above does not say the workaround is required nor did the original >text. Ah, semantic fun. Ok. I do not want to have an entry in the FAQ which "suggests" a workaround of setting the system PATH environment variable to work around other people's problems. >You complain about 3PPs but don't want to provide any easily found >directions to them about what not to do. You can say "search the list" >but as a practical matter, it isn't effective at guiding their >behavior. Corinna already said that she thought that instructions are a good idea. I am not against providing instructions to 3PPs. As I said today: >The problem with a "third party packager's guide" is that it would have >to be written by a third party who understands the whole deal. I'm not >aware of anyone actually trying to do this right. On rereading this thread, I see that you've volunteered to come up to speed on this subject so, maybe I was wrong. Patches tacitly awaited. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Netscape or Mozilla binaries for Cygwin?
> I was just wondering if there are any binaries for Netscape or Mozilla for > Cygwin? umm, why? Wouldn't be easier just to use the native windows versions? just curious. -- -matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
Christopher Faylor wrote: On Wed, Mar 30, 2005 at 09:57:44AM -0800, Jim Kleckner wrote: Then strike the link text and limit it to the workaround of adding the bin to the system path. My text was a suggested starting point. i.e., a workaround. The solution that the DLL has to be in the system path is not required for a sanctioned Cygwin release. But, then, we've seen before that clamwin insists on running in a non-cygwin environment. I don't want to be in the business of adding advice to the FAQ for fixing up other people's problems. Nobody said the workaround was required. See above. Above does not say the workaround is required nor did the original text. You complain about 3PPs but don't want to provide any easily found directions to them about what not to do. You can say "search the list" but as a practical matter, it isn't effective at guiding their behavior. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
On Wed, Mar 30, 2005 at 09:57:44AM -0800, Jim Kleckner wrote: >Christopher Faylor wrote: > >>On Wed, Mar 30, 2005 at 08:45:10AM -0800, Jim Kleckner wrote: > >>So, if you're a Unix guy since 1978, that puts you in a unique category. >>You don't qualify as a FAQ. > >I don't quite understand this. I don't qualify to write FAQ entries >or shouldn't be allowed to use them? "F"requently "A"sked "Q"uestions. >>I have very strong reservations about filling up documentation with >>every conceivable combination of advice that we could possibly think of. >>Adding rationales to stop Unix guys from shooting themselves in the foot >>should not be a focus of the FAQ. The FAQ is there to give advice to >>people on what to do, not to provide rationales for why they shouldn't >>do other things that pop into their heads. > >Then strike the link text and limit it to the workaround of adding >the bin to the system path. My text was a suggested starting point. i.e., a workaround. >>The solution that the DLL has to be in the system path is not required >>for a sanctioned Cygwin release. But, then, we've seen before that >>clamwin insists on running in a non-cygwin environment. I don't want to >>be in the business of adding advice to the FAQ for fixing up other >>people's problems. > >Nobody said the workaround was required. See above. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
Christopher Faylor wrote: On Wed, Mar 30, 2005 at 08:45:10AM -0800, Jim Kleckner wrote: So, if you're a Unix guy since 1978, that puts you in a unique category. You don't qualify as a FAQ. I don't quite understand this. I don't qualify to write FAQ entries or shouldn't be allowed to use them? I have very strong reservations about filling up documentation with every conceivable combination of advice that we could possibly think of. Adding rationales to stop Unix guys from shooting themselves in the foot should not be a focus of the FAQ. The FAQ is there to give advice to people on what to do, not to provide rationales for why they shouldn't do other things that pop into their heads. Then strike the link text and limit it to the workaround of adding the bin to the system path. My text was a suggested starting point. Look, all I'm trying to do here is save time for other people, not waste all of our time. The notion that the email list should be the primary reference for this kind of issue is wrong. And it shouldn't be this hard to try to help out either. The solution that the DLL has to be in the system path is not required for a sanctioned Cygwin release. But, then, we've seen before that clamwin insists on running in a non-cygwin environment. I don't want to be in the business of adding advice to the FAQ for fixing up other people's problems. Nobody said the workaround was required. I am very grateful for the great lengths you go to to fix other people's problems who use cygwin. If this is a problem with clamwin then people should be lobbying them for a fix, not suggesting that the Cygwin FAQ has to be modified as a workaround. Agree that clamwin should be fixed. I don't use it and don't care to use it. But then I share the compute resources. Jim - "It is better to light a candle than curse the darkness" -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apparent scheduler problem
Brian Ford wrote: On Tue, 29 Mar 2005, Andrew Dunstan wrote: Recently after upgrading my installation of Cygwin on XP-Pro, I noticed that PostgreSQL started failing one of its regression tests. [snip] The test is for the stats collector, and essentially it does some work, waits a couple of seconds in a fairly brain dead busy/wait loop, and then checks to see if the stats collector has done the work we expect it to have done. [snip] We are wondering if anything is known to have changed in Cygwin recently that could account for this. Sounds to me like yet another case of http://cygwin.com/ml/cygwin/2005-03/msg00730.html That's remarkably ugly :-) Two of us have confirmed that using the latest snapshot DLL fixes the problem for Postgres. When might the fix make it into a release? cheers andrew -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: What to do with "*** recreate_mmaps_after_fork_failed" ?
On Mar 30 18:14, Max Bowsher wrote: > Corinna Vinschen wrote: > >On Mar 30 17:21, Max Bowsher wrote: > >>I ran into a DLL base address problem, and rebased. > >> > >>However, instead of fixing this, rebasing just changed the error message > >>to > >>this: > >> > >> 4 [main] ruby 2652 fhandler_disk_file::fixup_mmap_after_fork: > >>requested 0x3F != 0x0 mem alloc base 0x2F, state 0x1000, size > >>12288, Win32 error 487 > >>M:\cygwin\bin\ruby.exe (2652): *** recreate_mmaps_after_fork_failed > >> 3 [main] ruby 2716 fork_parent: child 2652 died waiting for dll > >>loading > >>/home/max/devel/subversion/trunk/subversion/bindings/swig/ruby/test/util.rb:48: > >>[BUG] rb_sys_fail(fork(2)) - errno == 0 > >>ruby 1.8.2 (2004-12-25) [i386-cygwin] > >> > >> > >>How should I proceed? > > > >Debugging? Just an idea... > > Any hints? Sure. Just read src/winsup/cygwin/how-to-debug-cygwin.txt. If the mmaps couldn't be recreated then very likely because a DLL has been loaded to this memory area. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC header libraries ... ?
On Mar 30 07:54, Jacob Lane, MCP wrote: > All, > > Sorry if this is a newb question, but I am somwhat new to Cygwin and trying > to write / compile programs using GCC. One thing I noticed is that when I > try to compile code from others, I seem to be missing some header libraries. > > For example, in one recent program: > > #include > > I have had others tell me that on their native Linux installs, they have the > nameser.h library -- so it seems to be just me (using Cygwin) that is having > the issue. That's not a Cygwin problem. You just missed to install the appropriate development packages. In the above case you'll get the file by installing minires-devel. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: What to do with "*** recreate_mmaps_after_fork_failed" ?
Corinna Vinschen wrote: On Mar 30 17:21, Max Bowsher wrote: I ran into a DLL base address problem, and rebased. However, instead of fixing this, rebasing just changed the error message to this: 4 [main] ruby 2652 fhandler_disk_file::fixup_mmap_after_fork: requested 0x3F != 0x0 mem alloc base 0x2F, state 0x1000, size 12288, Win32 error 487 M:\cygwin\bin\ruby.exe (2652): *** recreate_mmaps_after_fork_failed 3 [main] ruby 2716 fork_parent: child 2652 died waiting for dll loading /home/max/devel/subversion/trunk/subversion/bindings/swig/ruby/test/util.rb:48: [BUG] rb_sys_fail(fork(2)) - errno == 0 ruby 1.8.2 (2004-12-25) [i386-cygwin] How should I proceed? Debugging? Just an idea... Any hints? Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: GCC header libraries ... ?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jacob Lane, MCP > Sent: Wednesday, March 30, 2005 9:54 AM > To: cygwin@cygwin.com > Subject: GCC header libraries ... ? > > All, > > Sorry if this is a newb question, but I am somwhat new to > Cygwin and trying to write / compile programs using GCC. One > thing I noticed is that when I try to compile code from > others, I seem to be missing some header libraries. > > For example, in one recent program: > > #include > > I have had others tell me that on their native Linux > installs, they have the nameser.h library -- so it seems to > be just me (using Cygwin) that is having the issue. > > My question is: if I run into this situation (1) what is the > best way to find and get the needed libraries, (2) is there > something within the Cygwin installer or docs that tells me > what libraries are installed with what package, etc? In this particular instance, I think the issue you're running into is that Cygwin uses newlib instead of glibc (the GNU C library used on Linux). Glibc tends to be more comprehensive in the networking department. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
On Wed, Mar 30, 2005 at 08:45:10AM -0800, Jim Kleckner wrote: >Christopher Faylor wrote: > >>On Wed, Mar 30, 2005 at 08:08:16AM -0800, Jim Kleckner wrote: >> >>>Christopher Faylor wrote: >>> OTOH, perhaps I'm oversimplifying things, but it seems like this thread went on for quite a while after the simple "delete the nonstandard DLL" advice was given. I don't see how any advice is going to be useful if it isn't followed. >>> >>>I agree completely. All the more reason to pull the concise answers >>>out of the email list and into the FAQ. This thread wouldn't have >>>existed at all. >> >> >>The concise answer is already in *cygwin itself*. The FAQ could >>arguably be updated to say "delete the dll that is not in >>c:\cygwin\bin". I guess it is assuming that someone has actually >>taken the time to read the error that cygwin presents. >> >>However, again, this concise answer was mentioned in the email list and >>not followed. I don't know why anyone would view the FAQ as more >>authoritative than the people they are soliciting for help here. > >Not true at all. The suggestion was followed. > >Note that the FAQ does not state to put the cygwin bin on the system >path. Of course I knew that it would work to do that. As a Unix guy >since 1978, I was curious to try using ln to see what it would do. >Larry Hall helpfully pointed out that while it would work, it was a >brittle solution. So, if you're a Unix guy since 1978, that puts you in a unique category. You don't qualify as a FAQ. I have very strong reservations about filling up documentation with every conceivable combination of advice that we could possibly think of. Adding rationales to stop Unix guys from shooting themselves in the foot should not be a focus of the FAQ. The FAQ is there to give advice to people on what to do, not to provide rationales for why they shouldn't do other things that pop into their heads. >Look, all I'm trying to do here is save time for other people, not >waste all of our time. The notion that the email list should be >the primary reference for this kind of issue is wrong. And it shouldn't >be this hard to try to help out either. The solution that the DLL has to be in the system path is not required for a sanctioned Cygwin release. But, then, we've seen before that clamwin insists on running in a non-cygwin environment. I don't want to be in the business of adding advice to the FAQ for fixing up other people's problems. If this is a problem with clamwin then people should be lobbying them for a fix, not suggesting that the Cygwin FAQ has to be modified as a workaround. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: What to do with "*** recreate_mmaps_after_fork_failed" ?
On Mar 30 17:21, Max Bowsher wrote: > I ran into a DLL base address problem, and rebased. > > However, instead of fixing this, rebasing just changed the error message to > this: > > 4 [main] ruby 2652 fhandler_disk_file::fixup_mmap_after_fork: > requested 0x3F != 0x0 mem alloc base 0x2F, state 0x1000, size > 12288, Win32 error 487 > M:\cygwin\bin\ruby.exe (2652): *** recreate_mmaps_after_fork_failed > 3 [main] ruby 2716 fork_parent: child 2652 died waiting for dll > loading > /home/max/devel/subversion/trunk/subversion/bindings/swig/ruby/test/util.rb:48: > > [BUG] rb_sys_fail(fork(2)) - errno == 0 > ruby 1.8.2 (2004-12-25) [i386-cygwin] > > > How should I proceed? Debugging? Just an idea... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: recv and errno during a connection reset/closed by peer
On Mar 30 10:18, Brian Ford wrote: > On Tue, 29 Mar 2005, Peter A. Castro wrote: > > > On Tue, 29 Mar 2005, Brian Ford wrote: > > > > > If you are doing a normal blocking recv without MSG_PEEK, any return of 0 > > > should mean a closed connection AFAIK. > > > > Unfortunately that's not true for all implementation. It's legal for a > > zero length data object to be sent. The network simply sends a header > > with no payload in it, but it's passed through the network anyways and is > > presented to the receiver. The receiver, which might be blocking at the > > time, will return from the call and get zero length data, but the > > connection is still valid at this point. I've seen AS/400's do just this > > sending zero length data to an AIX box. If the sender closes the > > connection normally, then subsequent calls to recv return zero with no > > indication that the connection is closed. Call it a bug if you want, but > > that's how it works. > > I agree that zero length data can be sent, but only for UDP or datagram > based sockets, not for TCP or stream based ones (nothing denotes a message > here). Even then, they are only sent by application choice, not just > randomly by the OS. Whether a connection is open or closed in this case > has little meaning. What Cygwin returns is what Cygwin gets from WinSock. If Cygwin gets 0, how should Cygwin suspect that something's wrong with the answer? I'm wondering how the OP has made sure that the connection has been closed non-gracefully. Has the process on the other side of the connection been killed forcefully? Or was the network cable plugged off? Otherwise there's a good chance that the process has closed the connection gracefully and the 0 return is perfectly fine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: recv and errno during a connection reset/closed by peert
On Tue, 29 Mar 2005, Peter A. Castro wrote: > On Tue, 29 Mar 2005, Brian Ford wrote: > > On Tue, 29 Mar 2005, Peter Stephens wrote: > >> I have thought about your suggestion and it makes a lot of sense. > >> > >> It seems like your suggestion would be very portable. A good > >> suggestion and the most likely route for me at this point. > > > > Not to me. Maybe I'm missing something, but it seems you are going to a > > lot of effort to poorly recreate poll/select? > > Why? A zero length return on a stream socket always means that the peer has closed its socket for writing. It may, however, still be open for reading (I don't remember the syscalls for doing such, but it can be done). A zero return on a datagram socket always means that a zero length message has been received. Counting zero returns is a poor hack at best and makes no sense to me since it never gives you any more information. > If you are doing sequential, non multi-plexed, reads why do poll or > select? You don't need to. > Sitting in read is more optimal and the read should return > either data or an error. Ok. > The flaw in recv is that it returns a non-error non-data status. It's not a flaw, it's the design (see above). > Perhaps it would be better to switch to using read() instead of recv? They usually have exactly the same semantics. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
Christopher Faylor wrote: On Wed, Mar 30, 2005 at 08:08:16AM -0800, Jim Kleckner wrote: Christopher Faylor wrote: OTOH, perhaps I'm oversimplifying things, but it seems like this thread went on for quite a while after the simple "delete the nonstandard DLL" advice was given. I don't see how any advice is going to be useful if it isn't followed. I agree completely. All the more reason to pull the concise answers out of the email list and into the FAQ. This thread wouldn't have existed at all. The concise answer is already in *cygwin itself*. The FAQ could arguably be updated to say "delete the dll that is not in c:\cygwin\bin". I guess it is assuming that someone has actually taken the time to read the error that cygwin presents. However, again, this concise answer was mentioned in the email list and not followed. I don't know why anyone would view the FAQ as more authoritative than the people they are soliciting for help here. Not true at all. The suggestion was followed. Note that the FAQ does not state to put the cygwin bin on the system path. Of course I knew that it would work to do that. As a Unix guy since 1978, I was curious to try using ln to see what it would do. Larry Hall helpfully pointed out that while it would work, it was a brittle solution. Look, all I'm trying to do here is save time for other people, not waste all of our time. The notion that the email list should be the primary reference for this kind of issue is wrong. And it shouldn't be this hard to try to help out either. Jim -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
GCC header libraries ... ?
All, Sorry if this is a newb question, but I am somwhat new to Cygwin and trying to write / compile programs using GCC. One thing I noticed is that when I try to compile code from others, I seem to be missing some header libraries. For example, in one recent program: #include I have had others tell me that on their native Linux installs, they have the nameser.h library -- so it seems to be just me (using Cygwin) that is having the issue. My question is: if I run into this situation (1) what is the best way to find and get the needed libraries, (2) is there something within the Cygwin installer or docs that tells me what libraries are installed with what package, etc? Thanks for the help- Jake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
What to do with "*** recreate_mmaps_after_fork_failed" ?
I ran into a DLL base address problem, and rebased. However, instead of fixing this, rebasing just changed the error message to this: 4 [main] ruby 2652 fhandler_disk_file::fixup_mmap_after_fork: requested 0x3F != 0x0 mem alloc base 0x2F, state 0x1000, size 12288, Win32 error 487 M:\cygwin\bin\ruby.exe (2652): *** recreate_mmaps_after_fork_failed 3 [main] ruby 2716 fork_parent: child 2652 died waiting for dll loading /home/max/devel/subversion/trunk/subversion/bindings/swig/ruby/test/util.rb:48: [BUG] rb_sys_fail(fork(2)) - errno == 0 ruby 1.8.2 (2004-12-25) [i386-cygwin] How should I proceed? Thanks, Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
On Wed, Mar 30, 2005 at 08:08:16AM -0800, Jim Kleckner wrote: >Christopher Faylor wrote: >>OTOH, perhaps I'm oversimplifying things, but it seems like this thread >>went on for quite a while after the simple "delete the nonstandard DLL" >>advice was given. I don't see how any advice is going to be useful if >>it isn't followed. > >I agree completely. All the more reason to pull the concise answers >out of the email list and into the FAQ. This thread wouldn't have >existed at all. The concise answer is already in *cygwin itself*. The FAQ could arguably be updated to say "delete the dll that is not in c:\cygwin\bin". I guess it is assuming that someone has actually taken the time to read the error that cygwin presents. However, again, this concise answer was mentioned in the email list and not followed. I don't know why anyone would view the FAQ as more authoritative than the people they are soliciting for help here. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: recv and errno during a connection reset/closed by peer
On Tue, 29 Mar 2005, Peter A. Castro wrote: > On Tue, 29 Mar 2005, Brian Ford wrote: > > > If you are doing a normal blocking recv without MSG_PEEK, any return of 0 > > should mean a closed connection AFAIK. > > Unfortunately that's not true for all implementation. It's legal for a > zero length data object to be sent. The network simply sends a header > with no payload in it, but it's passed through the network anyways and is > presented to the receiver. The receiver, which might be blocking at the > time, will return from the call and get zero length data, but the > connection is still valid at this point. I've seen AS/400's do just this > sending zero length data to an AIX box. If the sender closes the > connection normally, then subsequent calls to recv return zero with no > indication that the connection is closed. Call it a bug if you want, but > that's how it works. I agree that zero length data can be sent, but only for UDP or datagram based sockets, not for TCP or stream based ones (nothing denotes a message here). Even then, they are only sent by application choice, not just randomly by the OS. Whether a connection is open or closed in this case has little meaning. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
Christopher Faylor wrote: OTOH, perhaps I'm oversimplifying things, but it seems like this thread went on for quite a while after the simple "delete the nonstandard DLL" advice was given. I don't see how any advice is going to be useful if it isn't followed. I agree completely. All the more reason to pull the concise answers out of the email list and into the FAQ. This thread wouldn't have existed at all. Jim -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygexec mounted binaries don't inherit PATH during dynamic loading
On Tue, Mar 29, 2005 at 09:33:49PM -0800, Brian Dessent wrote: >So my question is simply this: in the case of spawning a cygexec-mounted >binary, shouldn't build_env at least fill in PATH from the calling >process' value, so that Windows can do its runtime DLL loading? Yes, it should. I've been closing my eyes to this problem for a while but this is the second time it's been reported in the span of a week (the other time was over in the crossgcc mailing list). There were several problems with the handling of PATH and other special environment variables. I hope I have fixed all of them in CVS. A new snapshot is being generated now. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: rxvt with libW11 bug: doubled KP_Subtract and KP_Add
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Bogossian
> Sent: Wednesday, March 30, 2005 3:52 AM
> To: cygwin@cygwin.com
> Subject: RE: rxvt with libW11 bug: doubled KP_Subtract and KP_Add
>
> >I never noticed the double ++ and --, but it happens for me too.
> >Removing the code to handle KP_Add and KP_Subtract (as the patch
> >suggests) may end up breaking the shift+ shift- font changer.
>
> Yes, indeed, I'm using a patched version of libW11 and the
> shift+ and shift- shortcuts don't work anymore...
>
> Pierre
1. Is there a reason for this "font changing" functionality? Is it size or
the actual font that this changes? Either way, it seems to me that working
numpad + and - trumps this obscure feature.
2. Shift-{+,-} is completely different from numpad-{+,-} under Windows, and
can fairly easily be separated out in the message loop. If nobody beats me
to it I might perhaps take a look. SteveO, how active are you in
maintaining rxvt these days? If I get a patch together can we get it
deployed in short order (weeks, not months)?
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: clamwin installs incompatible copy of cygwin1.dll
On Wed, Mar 30, 2005 at 09:31:50AM +0200, Corinna Vinschen wrote: >The idea of a "third party packager's guide" sounds good to me. I'd >rather have third parties not to pack Cygwin in their packages at all >and to point the user to install Cygwin from cygwin.com instead, but I >guess that's rather unrealistically. The problem with a "third party packager's guide" is that it would have to be written by a third party who understands the whole deal. I'm not aware of anyone actually trying to do this right. OTOH, perhaps I'm oversimplifying things, but it seems like this thread went on for quite a while after the simple "delete the nonstandard DLL" advice was given. I don't see how any advice is going to be useful if it isn't followed. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Errors in #include files when compiling a Legacy C++ Application
Original Message >From: Brian K. Whatcott >Sent: 28 March 2005 17:52 > I am forwarding this reply and the simpler example on to the mailing list. > The attached files are: > > hello.cc- Hello world that writes to a file, instead > of cout. > command.txt - The compile command. > hello_errors.txt- File with the errors from the compile. > cygcheck.out- The cycheck output file. > > All files are straight text (probably with Unix/Linux end of lines). Removing that bogus "-I/usr/include/machine" option helps. Don't try to second-guess the compiler! It knows perfectly well where to find all the system header files, and if you start needlessly adding -I options just because you think it "looks right", you'll only go and mess up its very-carefully arranged search path. The -I option should only ever be used to add the path(s) to *your* header files from your app, and the occasional library files (such as the X11R6 files), and never for system/compiler includes. After that you're just left with the error where you've typo'd 'oftream', which AFAIK is not any kind of C++ object, and the fact that you're trying to #include "strstream.h", which was deprecated and does not exist any more, and the fact that you aren't using ostream correctly, since (at least as far as I can see from a quick google) it doesn't construct from a string but from a reference to a streambuf-derived class object, but those are all general c++ programming errors that are not related to cygwin, and that I can't really advise on, because I don't know much about STL. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: rxvt with libW11 bug: doubled KP_Subtract and KP_Add
>I never noticed the double ++ and --, but it happens for me too. >Removing the code to handle KP_Add and KP_Subtract (as the patch >suggests) may end up breaking the shift+ shift- font changer. Yes, indeed, I'm using a patched version of libW11 and the shift+ and shift- shortcuts don't work anymore... Pierre -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
