Re: Patch for fhandler_tty.cc
On Oct 6 12:10, Mark Paulus wrote:
> --- fhandler_tty_old.cc 2004-10-06 12:05:54.196444800 -0600
> +++ fhandler_tty.cc 2004-10-06 12:06:13.465645500 -0600
> @@ -766,7 +766,7 @@ fhandler_tty_slave::read (void *ptr, siz
>w4[0] = signal_arrived;
>w4[1] = input_available_event;
>
> - DWORD waiter = !ptr ? 0 : INFINITE;
> + DWORD waiter = time_to_wait;
>while (len)
> {
>rc = WaitForMultipleObjects (2, w4, FALSE, waiter);
Looks good. I've applied it. Just a matching ChangeLog entry would
have been nice.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:[EMAIL PROTECTED]
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: Add requirement for SYSTEMROOT to FAQ?
On Oct 6 21:53, Christopher Faylor wrote: > Didn't we resolve that the need for SYSTEMROOT in the environment should > be in the FAQ at some point? > > Joshua, could you add something about how SYSTEMROOT is required for proper > operation with winsock? That would be good. > Or, even better yet, Corinna could we force SYSTEMROOT to be used > somehow but masked if someone removes it from the environment? Hmm, usually applications which suffer from a missing SYSTEMROOT are spawned by a parent process which has explicitely created a new environment block for the child and then calls execvp. So the new child is already missing SYSTEMROOT on process startup. What about always adding SYSTEMROOT to the windows env created in build_env, if it's missing? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] 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: Misleading warning from mount?
On Oct 7 16:57, [EMAIL PROTECTED] wrote: > bash-2.05b$ mount c:/temp/mnt/tmp /tmp > mount: warning - /tmp does not exist. > > Maybe I still misunderstand. In what sense does /tmp not exist? Under Unix, the directory in which you mount a partition must exist: $ mount /dev/hda /nirvana mount: /nirvana: No such file or directory or a similar message. From the perspective of Cygwin's mount, there's no /tmp directory at the moment you use it to mount c:\temp\mnt\tmp into it. That's all. In contrast to Unix, that's not breaking the mount, so you only get a warning. Use mount's -f option to suppress the warning message. Cornina -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] 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: Misleading warning from mount?
On 7 Oct, Corinna Vinschen wrote: > or a similar message. From the perspective of Cygwin's mount, there's > no /tmp directory at the moment you use it to mount c:\temp\mnt\tmp > into it. That's all. In contrast to Unix, that's not breaking the > mount, so you only get a warning. Use mount's -f option to suppress > the warning message. Ah! At last I understand. Thanks, Corinna. luke -- 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: Cygserver 100% CPU
forgot the log file. Here is it. ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com cygserver.log.bz2 Description: cygserver.log.bz2 -- 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: Spurious "You have multiple copies of cygwin1.dll on your syste m."
> -Original Message- > From: cygwin-owner On Behalf Of luke.kendall > Sent: 07 October 2004 07:50 > On 7 Oct, Christopher Faylor wrote: > > On Thu, Oct 07, 2004 at 02:49:29PM +1000, > [EMAIL PROTECTED] wrote: Tsk! CGF! PCYM! You too Luke! > Now you have a situation where cygwin1.dll is loaded in memory from > across the network. And if you have Cygwin installed on the local > machine, you don't get error messages about multiple Cygwin versions > installed on your PC. You can run all the Cygwin commands. Same thing can also happen if you leave a cygwin-based service running when you do an update. > So even knowing that the error message is imprecise and misleading in > this situation, and that it probably means that Cygwin tried > to load up > cygwin1.dll from a different path to a copy that's already loaded, and > that it's incompatible with the one that's already loaded, I > don't know > why Cygwin is trying to load this other DLL. Standard windoze behaviour is to first search for dlls in the same dir as the app, only then if not found look in the standard system dirs and path. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas e/loadlibrary.asp > I suspect the error message should be "Attempting to load an > inconsistent version of cygwin1.dll". > > I freely confess I'm doing something unusual. Maybe I'm the first > person on the planet to attempt to automate Cygwin installation via a > shell script from an already existing and stable copy of Cygwin > installed elsewhere on the network? It's possible. Is there a reason you aren't using setup.exe? It's automatable and easily customisable and it has the benefit in this situation of being a plain non-cygwin win32 exe. 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: Openssh on Windows XP SP2 sshd service stops when attempting to connect
Ok, I have cleared out my ssh_host* keys, and cleared the contents of .ssh, so as to start over. I regenerated the keys by running ssh-host-config. I also changed my CYGWIN= to tty ntsec binmode So I get prompted for a password, and looking at the event security log, I get the following: SYSTEM: Successful Account Logon for user "paul" (680) paul: Successful Logon/Logoff (528) paul: Successful privilage use (privilages assigned) (576) SYSTEM: Failed Account Logon for user "paul" (680) paul: Failed Logon/Logoff (An error occured during logon) (537) paul: Successful Logon/Logoff (538) Here is the tail end of the sshd.log during this: debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug3: Trying to reverse map address 127.0.0.1. Last login: Thu Oct 7 20:02:22 2004 from zenzoom debug1: permanently_set_uid: 1003/513 setreuid 1003: Permission denied debug1: do_cleanup debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 6 c -1 Connection to 127.0.0.1 closed. debug1: Transferred: stdin 0, stdout 0, stderr 33 bytes in 0.5 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 69.9 debug1: Exit status 255 koan wrote: Hello, I have read what I can find, but am getting stuck with sshd. I am using Openssh 3.9p1-2. My service starts fine, and I am running it with -d -d -d -e parameters (set in registry), I used -v -v -v on the ssh command line. My key files are owned by SYSTEM:none, and are read-write for owner only. /var/empty is owned by SYSTEM:SYSTEM, and is 700, I have run ssh-host-config, and ssh-user-config, and I have mkpasswd and mkgroup synced my Windows users with cygwins. If I try ssh to localhost, 127.0.0.1 on the machine the sshd service is running, it negotiates for a bit, and then the connection fails, and the sshd service stops. I want to use password authentication. I have tried a seperate client (secureCrt) If I run change ownership of /var/empty to my own user, and then run sshd in a window, I can connect ok (last time I tried). Please find attached my cygcheck.out, the sshd.log and the ssh.log from the console. If anyone can help, it would be great. koan debug2: load_server_config: filename /etc/sshd_config debug2: load_server_config: done config len = 187 debug2: parse_server_config: config /etc/sshd_config len 187 debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-d' debug1: rexec_argv[4]='-e' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug3: fd 4 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 187 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug3: recv_rexec_state: entering fd = 5 debug3: ssh_msg_recv entering debug3: recv_rexec_state: done debug2: parse_server_config: config rexec len 187 debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: inetd sockets after dupping: 3, 3 Connection from 127.0.0.1 port 3669 debug1: Client protocol version 2.0; client software version Ope
Re: Spurious "You have multiple copies of cygwin1.dll on your system."
On Thu, 7 Oct 2004, luke.kendall wrote: > On 7 Oct, Christopher Faylor wrote: > > On Thu, Oct 07, 2004 at 02:49:29PM +1000, [EMAIL PROTECTED] wrote: Erghm... > > >After installing Cygwin by using a shell script running by executing > > >bash from a network-installed Cygwin, the script fails when it tries to > > >run a post-install script. The error reported is: > > > > > >bash-2.05b$ post-install.sh -which latest -fresh > > >c:\cygwin\bin\bash.exe (3208): *** cygheap version mismatch detected - > > > 0x616D/0x6178. > > >You have multiple copies of cygwin1.dll on your system. > > >Search for cygwin1.dll using the Windows Start->Find/Search facility > > >and delete all but the most recent version. The most recent version *should* > > >reside in x:\cygwin\bin, where 'x' is the drive on which you have > > >installed the cygwin distribution. > > > > > >A search showed that there really is only c:\cygwin\bin\cygwin1.dll - > > >the message is wrong. > > > > > >I'd say the sanity-check is detecting cygwin1.dll associated with the > > >bash that's running from the network-mounted drive. > > > > You wouldn't say that if you knew what "cygheap" was. This is an > > indication that a child executable is detecting that its cygheap is > > not at the same location as the parent. Since the cygheap lives at > > the end of the cygwin DLL it's hard to see how this could be anything > > other than two different versions of cygwin being invoked. > > Okay, and in fact there are two (possibly different) versions of > cygwin1.dll available to be loaded into memory. I don't know why > Cygwin attempted to load the freshly-installed cygwin1.dll, though. > It wasn't on the PATH of the network-loaded shell script. As Dave said, Windows loads the DLLs from the app directory before going through the PATH. I'd bet there's a /bin/sh (or something of the sort) call in the post-install script, which, after you've changed the mounts, points to c:/bin (which is the newly-installed Cygwin). Basically, it's not enough to share the network directory -- you also have to have the "/", "/usr/bin", and "/usr/lib" mounts pointing to it for the network copy of Cygwin to work properly. So, your mount changing idea may not be so off the mark after all, but in the other direction (i.e., switch "/" back to the network drive)... Unfortunately, anything written to those directories will then also go back to the network drive, which isn't what you want. Sort of a Catch-22 here... One question is: do you have to use the actual POSIX paths in your install script? If you can have a uniquely-named mount (say, "/local-install"), and use that in your install script (e.g., "/local-install/bin", etc), you should be able to circumvent this issue. Since you're the administrator, you can just decree that your users shan't have a mount named "/local-install" on their existing Cygwin installations). > To be pedantic, the warning is wrong because it says you have multiple > copies of cygwin1.dll on your system. There aren't, and indeed a > Search for cygwin1.dll using the Windows Start->Find/Search facility > confirms that there is only a single cygwin1.dll, freshly installed. Well, network drives are technically drives on your system too. If you can't find multiple copies of cygwin1.dll on your local drives, but an extra copy exists on a network drive, the error is correct. > Try this: from a machine on your network, with Cygwin installed, share > the c:/cygwin directory (i.e. the path where you installed Cygwin). > > On another PC, start a DOS window. set PATH=this network Cygwin path > Type bash. You get a bash prompt. > > Now you have a situation where cygwin1.dll is loaded in memory from > across the network. And if you have Cygwin installed on the local > machine, you don't get error messages about multiple Cygwin versions > installed on your PC. You can run all the Cygwin commands. ...Until you use an absolute path to invoke a command (e.g., /bin/sh) with mounts pointing to the local installation... > So even knowing that the error message is imprecise and misleading in > this situation, and that it probably means that Cygwin tried to load up > cygwin1.dll from a different path to a copy that's already loaded, and > that it's incompatible with the one that's already loaded, I don't know > why Cygwin is trying to load this other DLL. Mounts. > I suspect the error message should be "Attempting to load an > inconsistent version of cygwin1.dll". How's "version mismatch" different from "inconsistent version"? > I freely confess I'm doing something unusual. Maybe I'm the first > person on the planet to attempt to automate Cygwin installation via a > shell script from an already existing and stable copy of Cygwin > installed elsewhere on the network? Likely you are. There just aren't that many people using Cygwin, and even fewer that are administering it (and even fewer that are doing it remotely, I
Re: Spurious "You have multiple copies of cygwin1.dll on your syste m."
On Thu, Oct 07, 2004 at 10:22:18AM +0100, Dave Korn wrote: >> -Original Message- >> From: cygwin-owner On Behalf Of luke.kendall >> Sent: 07 October 2004 07:50 > >> On 7 Oct, Christopher Faylor wrote: >> > On Thu, Oct 07, 2004 at 02:49:29PM +1000, >> [EMAIL PROTECTED] wrote: > > Tsk! CGF! PCYM! You too Luke! Can you give this a rest, please? I've mentioned that mutt does this automatically if there is no user name associated with an email address. I am not going to go out of my way to police my email if a person is going to send their mail in a nonstandard way. So you can save yourself the extra 15 seconds a month that you expend every time this happens. I'm not going to bother with this corner case and you don't need to admonish me every time it happens. 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: Add requirement for SYSTEMROOT to FAQ?
On Thu, Oct 07, 2004 at 10:20:53AM +0200, Corinna Vinschen wrote: >On Oct 6 21:53, Christopher Faylor wrote: >> Didn't we resolve that the need for SYSTEMROOT in the environment should >> be in the FAQ at some point? >> >> Joshua, could you add something about how SYSTEMROOT is required for proper >> operation with winsock? > >That would be good. > >> Or, even better yet, Corinna could we force SYSTEMROOT to be used >> somehow but masked if someone removes it from the environment? > >Hmm, usually applications which suffer from a missing SYSTEMROOT are >spawned by a parent process which has explicitely created a new >environment block for the child and then calls execvp. So the new >child is already missing SYSTEMROOT on process startup. What about >always adding SYSTEMROOT to the windows env created in build_env, >if it's missing? That's what I was thinking. And then lying about its existence if someone queries the environment via getenv and SYSTEMROOT is "not supposed to be there". What an amazingly lame requirement... 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: Spurious "You have multiple copies of cygwin1.dll on your system."
On Thu, 7 Oct 2004, Igor Pechtchanski wrote: -snip- > Basically, it's not enough to share the network directory -- you also have > to have the "/", "/usr/bin", and "/usr/lib" mounts pointing to it for the > network copy of Cygwin to work properly. So, your mount changing idea may > not be so off the mark after all, but in the other direction (i.e., switch > "/" back to the network drive)... Unfortunately, anything written to > those directories will then also go back to the network drive, which isn't > what you want. Sort of a Catch-22 here... -snip- ...Without speaking to any of the other issues of this thread, I can provide commentary about the above comments; In short, it's not very difficult to configure a shared installation with as much local deviation as you wish. We do it here with a great many software packages that were "never intended" to be managed this way. Here's the go: Start with an intact, proven working installation directory tree that's on a served network drive (by whatever means). Then, on each "installation client" provide a complete directory tree that matches the structure of the networked tree in every particular, at least in so far as local modifications are desired. Then, each directory on the client nodes are populated with links back to the network counterpart. When particular sections of the tree don't need any local variant, a link can be provided at the directory level to present entire branches of the directory tree from the networked installation. Of course, this has nothing to do with Cygwin, and, now that I think of it, I'm not sure I've ever done this with a Cygwin-served (Windows-served) directory tree, but I can't think of any reason why this wouldn't work just fine in an all-Windows environment. Hope this helps, Richard P.S. Igor, regarding execv(), I had indeed 'malloc'ed just enough memory for nargv and the extra null was in fact in non-malloced memory! Arg! What surprised me was that the write to that memory space was permitted and it failed sometime later when that memory location was needed/used for something else! (wtf? -frown- ) Tnx, RT P.P.S. My Windows XP Pro _doesn't_ have ping or dig/nslookup?! -frown- Tnx again, RT -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
qmail, DJB licensing
What are the isues about qmail license restrictions now? Most know that it's vastly "superior" over other MTA's. (i.e. people tend to like it more) E.g. sourceware uses qmail http://sources.redhat.com/lists.html#what-software I see in the thread around http://www.cygwin.com/ml/cygwin/2003-05/msg01651.html, that qmail has no acceptable license to include it into cygwin, because it cannot be guaranteed that it will work reliably on that "crappy platform" (simplified). Maybe just with dropping vpopmail support. Still the last word? Maybe provide a source package only? Igor suggested such a trick, but then the thread drifted into something completely different. (RPM support, ant, ...) Sergey's original porting thread http://www.cygwin.com/ml/cygwin/2003-05/msg01593.html also drifted into something completely different. (mysql server) Still waiting on DJB's approval? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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: qmail, DJB licensing
On Thu, Oct 07, 2004 at 05:18:41PM +0200, Reini Urban wrote: >What are the isues about qmail license restrictions now? > >Most know that it's vastly "superior" over other MTA's. >(i.e. people tend to like it more) >E.g. sourceware uses qmail > http://sources.redhat.com/lists.html#what-software > >I see in the thread around > http://www.cygwin.com/ml/cygwin/2003-05/msg01651.html, >that qmail has no acceptable license to include it into cygwin, >because it cannot be guaranteed that it will work reliably on that >"crappy platform" (simplified). Maybe just with dropping vpopmail support. > >Still the last word? >Maybe provide a source package only? Igor suggested such a trick, but >then the thread drifted into something completely different. (RPM >support, ant, ...) > >Sergey's original porting thread > http://www.cygwin.com/ml/cygwin/2003-05/msg01593.html >also drifted into something completely different. (mysql server) > >Still waiting on DJB's approval? It's vanishingly unlikely that we'll get DJB's approval. You might check into how the netqmail does this: http://www.qmail.org/netqmail/ They don't seem to offer binaries, so I assume the licensing problems still exist. Why not concentrate on sendmail or postfix instead? These days, I don't think qmail has anything over postfix. I use all three and prefer postfix. 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/
Fw: cron doesnt run jobs (sometimes)!
- Original Message - From: "Reini Urban" <[EMAIL PROTECTED]> To: "russ" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 07, 2004 1:22 AM Subject: Re: cron doesnt run jobs (sometimes)! > russ schrieb: > > > Hi there list! > > > > 1st off .im new to cygwin. > > > > i have built some scripts to do tape backups > > basically a find, then a cpio, then tar it to tape. > > > > it runs from the command line. > > > > it doesnt run from crontab, although from event viewer i see that cron ran. > > > > also i put another line in crontab to run ls -l >> /usr/tmp/test every > > minute. > > this works just fine!. > > > > ive lightly tapped all my scripts with chmod 777 still doesnt work! > > not the script! the data must be readable for SYSTEM. > > > btw its a win2k server (dc) > > > > > > any ideas? > > check if it runs under okay in a "sysbash" shell. must be the permissions. > > search the ml archives for "sysbash". still not a package > or run manually: > > at /interactive bash --login -i > > -- > Reini Urban > http://xarch.tu-graz.ac.at/home/rurban/ Ah! it seems to work now. fantastic! does anyone know how to get a system owned bash shell from an RDP session, i can only get one at the console. which is 300 miles away :-< Russ -- 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: Calls to system() blocks return of SIGCHLD signal
On Wed, 6 Oct 2004, Christopher Faylor wrote:
> On Wed, Oct 06, 2004 at 12:24:48PM -0400, Remy Gauthier wrote:
> >We have noticed (on V1.5.10-1 and V1.5.11-1) that after a call to
> >system(), the handlers were not being called after the child process
> >stopped. This program has this behaviour (removing the call to
> >system() will restore correct SIGCHLD handling):
[snip; from Linux system(3)]
> During execution of the command, SIGCHLD will be blocked, and SIGINT and
> SIGQUIT will be ignored.
Um..., I think you missed the point here cgf as this didn't answer the
question. The key word above is "During". He was reporting that it was
still in effect "after", and he identified the cause here:
> >Then, when the child has completed, a cleanup process is done:
> >
> >static void
> >do_cleanup (void *args)
> >{
> ># define cleanup ((pthread_cleanup *) args)
[snip]
> >if (cleanup->oldmask)
> >sigprocmask (SIG_SETMASK, &(cleanup->oldmask), NULL);
> ># undef cleanup
> >}
[snip]
> >... but when the signal mask was previously empty (no blocked signals),
> >the sigprocmask call will not be done, therefore leaving SIGCHLD
> >blocked
Maybe I haven't had enough coffee yet this morning, but I'm inclined to
agree that this is a bug.
--
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: Add requirement for SYSTEMROOT to FAQ?
I hope that one or the other occurs. I spent free time for weeks trying to figure out why my perl cgi scripts didn't work under cygwin/apache. At least with a faq entry, a google for "cygwin socket error" would turn up something useful. -- Now that I think of it, this thread will probably also come up through the mail list archives. :-) dar On Wed, 6 Oct 2004, Christopher Faylor wrote: > Didn't we resolve that the need for SYSTEMROOT in the environment should > be in the FAQ at some point? > > Joshua, could you add something about how SYSTEMROOT is required for proper > operation with winsock? > > Or, even better yet, Corinna could we force SYSTEMROOT to be used > somehow but masked if someone removes it from the environment? > > 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/ > > > -- 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: qmail, DJB licensing
Christopher Faylor schrieb: It's vanishingly unlikely that we'll get DJB's approval. True. You might check into how the netqmail does this: http://www.qmail.org/netqmail/ They don't seem to offer binaries, so I assume the licensing problems still exist. So we could follow Igor's suggestion providing the sources in the binary package and compile it after download. http://www.cygwin.com/ml/cygwin/2003-05/msg01654.html At least better than nothing. exim would need a comparative and simplier MTA. I failed with trying to do some heavy processing with my new postgresql postinstall script. The compile step in a postinstall script would need to open a seperate console detached from setup.exe probably. Otherwise I see no light. Why not concentrate on sendmail or postfix instead? These days, I don't think qmail has anything over postfix. I use all three and prefer postfix. Well, if I had to choose, I would prefer exim over postfix, (having both in production, with funky mysql vhosts and users) and exim is already available as cygwin package. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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: Add requirement for SYSTEMROOT to FAQ?
On Thu, Oct 07, 2004 at 11:26:47AM -0500, David A. Rogers wrote: >I hope that one or the other occurs. I spent free time for weeks trying >to figure out why my perl cgi scripts didn't work under cygwin/apache. > >At least with a faq entry, a google for "cygwin socket error" would turn >up something useful. > >-- Now that I think of it, this thread will probably also come up through >the mail list archives. :-) I'm in the process of trying to add a workaround in cygwin. Heads up to Corinna. I'll stop if you're already doing this. 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: Add requirement for SYSTEMROOT to FAQ?
Christopher Faylor wrote: > >On Thu, Oct 07, 2004 at 10:20:53AM +0200, Corinna Vinschen wrote: >> >>What about >>always adding SYSTEMROOT to the windows env created in build_env, >>if it's missing? > >That's what I was thinking. And then lying about its existence if >someone queries the environment via getenv and SYSTEMROOT is "not >supposed to be there". Won't lying about the existence of SYSTEMROOT lead to some problems debugging a SYSTEMROOT-related issue? "What's the SYSTEMROOT?" "How do I find out?" "Add echo $SYSTEMROOT to [something]" "It says SYSTEMROOT is empty" etc. -Richard Campbell. -- 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: Spurious "You have multiple copies of cygwin1.dll on your system."
> -Original Message-
> From: cygwin-owner On Behalf Of Richard Troy
> Sent: 07 October 2004 15:57
[ We're getting a bit OT here, since this is generic programming stuff
rather than cygspecific, so if you want to discuss the generalities here any
further we should TITTTL. ]
> P.S. Igor,
I'm not Igor, but I'll do, since I was in the earlier thread!
> regarding execv(), I had indeed 'malloc'ed just
> enough memory
> for nargv and the extra null was in fact in non-malloced
> memory! Arg! What
> surprised me was that the write to that memory space was
> permitted and it
> failed sometime later when that memory location was needed/used for
> something else! (wtf? -frown- )
That's because the way that malloc implementations generally work is that
the crt startup code supplies a big block of memory ('heap'), and malloc
then allocates chunks from within that block for the application to use;
malloc only has to go back to the OS for more memory space every once in a
while, when the current heap runs out, rather than on every single
malloc/free operation. This makes for a good deal more efficiency, but has
the side effect that the memory chunks malloc gives you are in the middle of
the heap, with other valid malloc'd memory chunks on either side, rather
than in an isolated part of the process memory map with guard pages on each
side.
Overwriting the end of a buffer is a very heisenbug situation, since what
gets placed after any given buffer is highly variable, depending as it does
on some/all/many of the following factors, including: underlying OS/cpu
architecture, size of process environment, version of compiler and settings
of flags used to build application, versions of system libraries... you
get the picture.
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: Calls to system() blocks return of SIGCHLD signal
On Thu, Oct 07, 2004 at 11:30:42AM -0500, Brian Ford wrote: >On Wed, 6 Oct 2004, Christopher Faylor wrote: > >> On Wed, Oct 06, 2004 at 12:24:48PM -0400, Remy Gauthier wrote: >> >We have noticed (on V1.5.10-1 and V1.5.11-1) that after a call to >> >system(), the handlers were not being called after the child process >> >stopped. This program has this behaviour (removing the call to >> >system() will restore correct SIGCHLD handling): >[snip; from Linux system(3)] >> During execution of the command, SIGCHLD will be blocked, and SIGINT and >> SIGQUIT will be ignored. > >Um..., I think you missed the point here cgf as this didn't answer the >question. The key word above is "During". He was reporting that it >was still in effect "after", and he identified the cause here: Shame on me for not reading the original message more thoroughly and ass*u*me ing that it was a standard complaint about documented system() behavior. The fix is trivial and checked in. I apologize for my incorrect answer and for any confusion I caused. This will be in the next snapshot, which I've just kicked off now: http://cygwin.com/snapshots/ 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: Add requirement for SYSTEMROOT to FAQ?
On Oct 7 12:38, Christopher Faylor wrote: > On Thu, Oct 07, 2004 at 11:26:47AM -0500, David A. Rogers wrote: > >I hope that one or the other occurs. I spent free time for weeks trying > >to figure out why my perl cgi scripts didn't work under cygwin/apache. > > > >At least with a faq entry, a google for "cygwin socket error" would turn > >up something useful. > > > >-- Now that I think of it, this thread will probably also come up through > >the mail list archives. :-) > > I'm in the process of trying to add a workaround in cygwin. > > Heads up to Corinna. I'll stop if you're already doing this. I had some spare time between GDB builds so I began. But my current solution doesn't work so I have to debug it. But there's no need to do it twice so stop if you like. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] 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: qmail, DJB licensing
On Thu, Oct 07, 2004 at 06:34:52PM +0200, Reini Urban wrote: >Christopher Faylor schrieb: >>You might check into how the netqmail does this: >> http://www.qmail.org/netqmail/ >> >>They don't seem to offer binaries, so I assume the licensing problems >>still exist. > >So we could follow Igor's suggestion providing the sources in the binary >package and compile it after download. > http://www.cygwin.com/ml/cygwin/2003-05/msg01654.html >At least better than nothing. exim would need a comparative and simplier >MTA. I was pointing you to netqmail to show that the licensing problem hadn't been solved. Since this solution would require the existence of gcc on the system. I don't think its worth the hassle. >I failed with trying to do some heavy processing with my new postgresql >postinstall script. The compile step in a postinstall script would need >to open a seperate console detached from setup.exe probably. Otherwise I >see no light. You're requiring a C compiler in postinstall? That's not very nice. >>Why not concentrate on sendmail or postfix instead? These days, I don't >>think qmail has anything over postfix. I use all three and prefer >>postfix. > >Well, if I had to choose, I would prefer exim over postfix, >(having both in production, with funky mysql vhosts and users) >and exim is already available as cygwin package. Ok, problem solved then. 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: Add requirement for SYSTEMROOT to FAQ?
On Oct 7 10:52, Christopher Faylor wrote: > On Thu, Oct 07, 2004 at 10:20:53AM +0200, Corinna Vinschen wrote: > >On Oct 6 21:53, Christopher Faylor wrote: > >> Or, even better yet, Corinna could we force SYSTEMROOT to be used > >> somehow but masked if someone removes it from the environment? > > > >Hmm, usually applications which suffer from a missing SYSTEMROOT are > >spawned by a parent process which has explicitely created a new > >environment block for the child and then calls execvp. So the new > >child is already missing SYSTEMROOT on process startup. What about > >always adding SYSTEMROOT to the windows env created in build_env, > >if it's missing? > > That's what I was thinking. And then lying about its existence if > someone queries the environment via getenv and SYSTEMROOT is "not > supposed to be there". > > What an amazingly lame requirement... Why is that a requirement anyway? Why is it necessary to hide $SYSTEMROOT? I don't see a reason for that? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] 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: Patch for fhandler_tty.cc
Corinna,
Thanks for applying this, and I apologize for not following
protocol. Subsequent patches will go to cygwin-patches,
and will be accompanied by ChangeLog entries as well.
On Thu, 07 Oct 2004 10:01:49 +0200, Corinna Vinschen wrote:
>On Oct 6 12:10, Mark Paulus wrote:
>> --- fhandler_tty_old.cc 2004-10-06 12:05:54.196444800 -0600
>> +++ fhandler_tty.cc 2004-10-06 12:06:13.465645500 -0600
>> @@ -766,7 +766,7 @@ fhandler_tty_slave::read (void *ptr, siz
>>w4[0] = signal_arrived;
>>w4[1] = input_available_event;
>>
>> - DWORD waiter = !ptr ? 0 : INFINITE;
>> + DWORD waiter = time_to_wait;
>>while (len)
>> {
>>rc = WaitForMultipleObjects (2, w4, FALSE, waiter);
>Looks good. I've applied it. Just a matching ChangeLog entry would
>have been nice.
>Thanks,
>Corinna
>--
>Corinna Vinschen Please, send mails regarding Cygwin to
>Cygwin Project Co-Leader mailto:[EMAIL PROTECTED]
>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: Add requirement for SYSTEMROOT to FAQ?
On Thu, Oct 07, 2004 at 07:07:23PM +0200, Corinna Vinschen wrote: >On Oct 7 10:52, Christopher Faylor wrote: >> On Thu, Oct 07, 2004 at 10:20:53AM +0200, Corinna Vinschen wrote: >> >On Oct 6 21:53, Christopher Faylor wrote: >> >> Or, even better yet, Corinna could we force SYSTEMROOT to be used >> >> somehow but masked if someone removes it from the environment? >> > >> >Hmm, usually applications which suffer from a missing SYSTEMROOT are >> >spawned by a parent process which has explicitely created a new >> >environment block for the child and then calls execvp. So the new >> >child is already missing SYSTEMROOT on process startup. What about >> >always adding SYSTEMROOT to the windows env created in build_env, >> >if it's missing? >> >> That's what I was thinking. And then lying about its existence if >> someone queries the environment via getenv and SYSTEMROOT is "not >> supposed to be there". >> >> What an amazingly lame requirement... > >Why is that a requirement anyway? Why is it necessary to hide >$SYSTEMROOT? I don't see a reason for that? I was talking about the need for SYSTEMROOT being lame. I was theorizing that some program might become confused if it did something like: 1) Wipe out everything from the environment 2) Check the environment 3) Hey! The environment isn't empty after I tried to empty it! ABORT!!! ABORT!!! ABORT!!! However, since cygwin is *already* trying to do the right thing with SYSTEMROOT, and already keeps other things in the environment even after someone says to nuke them, all that is required is a little extra caching of the SYSTEMROOT environment variable. That's how I was going to handle this. 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: qmail, DJB licensing
Reini Urban wrote: > So we could follow Igor's suggestion providing the sources in the binary > package and compile it after download. >http://www.cygwin.com/ml/cygwin/2003-05/msg01654.html > At least better than nothing. exim would need a comparative and simplier > MTA. > > I failed with trying to do some heavy processing with my new postgresql > postinstall script. The compile step in a postinstall script would need > to open a seperate console detached from setup.exe probably. Otherwise I > see no light. I don't see why you're interested in making an extremely unwieldy pseudo-binary package for this. It just seems like a nightmare to support for both packagers and users, all because DJB won't let you distribute anything but pristine sources. Does maildir even work without resorting to managed mounts? Have you considered that too? It sounds like even if it were possible to package qmail there would be many hurdles that would cause it to be hardly a "drop-in" package. 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: Add requirement for SYSTEMROOT to FAQ?
On Thu, 7 Oct 2004, Corinna Vinschen wrote: > On Oct 7 10:52, Christopher Faylor wrote: > > Why is that a requirement anyway? Why is it necessary to hide > $SYSTEMROOT? I don't see a reason for that? > > Corinna > > apache strips it out before launching cgi programs. cgi programs that need to access a socket can't because they don't have a $SYSTEMROOT variable. dar -- 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: Add requirement for SYSTEMROOT to FAQ?
On Thu, Oct 07, 2004 at 01:21:48PM -0500, David A. Rogers wrote: >On Thu, 7 Oct 2004, Corinna Vinschen wrote: >> On Oct 7 10:52, Christopher Faylor wrote: No, I didn't. >> Why is that a requirement anyway? Why is it necessary to hide >> $SYSTEMROOT? I don't see a reason for that? > >apache strips it out before launching cgi programs. cgi programs that >need to access a socket can't because they don't have a $SYSTEMROOT >variable. Corinna and I were having a technical discussion. We both understand the requirements. We were discussing the best way to implement things. 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/
ssh/BitKeeper connection does not work on cygwin1.5.11?
I have a few user reporting the following problem: After upgrading from cygwin 1.5.10-3 to cygwin 1.5.11; Using Bitkeeper over a ssh connection just hang after the password prompt. [I can reproduce it at will too] I ran the test with the same version of openssh (3.9.p1) It worked in cygwin1.5.10 and failed in cygwin1.5.11. Does anyone had any idea what caused this? Thanks Andrew Chang -- 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: Add requirement for SYSTEMROOT to FAQ?
On Thu, 7 Oct 2004, Christopher Faylor wrote: > On Thu, Oct 07, 2004 at 01:21:48PM -0500, David A. Rogers wrote: > >On Thu, 7 Oct 2004, Corinna Vinschen wrote: > >> On Oct 7 10:52, Christopher Faylor wrote: > > No, I didn't. True enough. Snipped incorrectly. > > >> Why is that a requirement anyway? Why is it necessary to hide > >> $SYSTEMROOT? I don't see a reason for that? > > > >apache strips it out before launching cgi programs. cgi programs that > >need to access a socket can't because they don't have a $SYSTEMROOT > >variable. > > Corinna and I were having a technical discussion. We both understand > the requirements. We were discussing the best way to implement things. > Corrina asked why it was necessary to hide SYSTEMROOT. I read that as "What is the reason for hiding SYSTEMROOT?" In any case, I don't think an attempt to be helpful warrents a snippy response. dar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: ssh/BitKeeper connection does not work on cygwin1.5.11?
Hi Andrew... Are those usere using Windows XP SP2? If so, this sounds like the pipe problem with cygwin on XP SP2 that is being worked. Thanks, ...Karl From: Andrew Chang To: [EMAIL PROTECTED] Subject: ssh/BitKeeper connection does not work on cygwin1.5.11? Date: Thu, 7 Oct 2004 13:32:07 -0700 I have a few user reporting the following problem: After upgrading from cygwin 1.5.10-3 to cygwin 1.5.11; Using Bitkeeper over a ssh connection just hang after the password prompt. [I can reproduce it at will too] I ran the test with the same version of openssh (3.9.p1) It worked in cygwin1.5.10 and failed in cygwin1.5.11. Does anyone had any idea what caused this? Thanks Andrew Chang _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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: Add requirement for SYSTEMROOT to FAQ?
David A. Rogers wrote: > ... > Corrina asked why it was necessary to hide SYSTEMROOT. I read that as "What > is the reason for hiding SYSTEMROOT?" Reading skills needed! Her name is Corinna. Also, if you'd read the whole thread you'd have seen that your information was already known. Perhaps you are new to this forum, and are not aware that cgf and Corinna are the two key Cygwin developers. It's unlikely either would need to be told again what the SYSTEMROOT problem is. I understood Corinna's question to be "Why should the Cygwin kernel need to hide the fact that the SYSTEMROOT environment variable is set from a Cygwin app (yet still pass it on to a Windows subprocess)". You didn't answer that. > In any case, I don't think an attempt to be helpful warrents a snippy > response. The word is "warrants". I think the "snippy" (?) response was from frustration on cgf's part. Not only did you misappropriate a quote to him, you didn't answer the question asked, and gave already known information. -- Cliff -- 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/
libtool bug
Hi, I'm trying to compile guile-1.7.1 on cygwin, with a recently installed libtool, ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) At some point, make issues the following command line, /bin/bash ../libtool --mode=install /usr/bin/install -c libguile-srfi-srfi-1-v-2.la /usr/local/lib/libguile-srfi-srfi-1-v-2.la libtool: install: warning: relinking `libguile-srfi-srfi-1-v-2.la' (cd /home/Hanwen/src/guile-1.7.1/srfi; /bin/bash ../libtool --mode=relink gcc -g -O2 -Wall -Wmissing-prototypes -Werror -o libguile-srfi-srfi-1-v-2.la -rpath /usr/local/lib -no-undefined -export-dynamic -version-info 2:0:0 srfi-1.lo ../libguile/libguile.la -lpthread -lgmp -lcrypt -lm ) libtool: link: warning: `/lib/libgmp.la' seems to be moved which is translated to the following GCC command line gcc -shared .libs/srfi-1.o -L/lib -L/usr/lib -L/home/Hanwen/src/guile-1.7.1/libguile-ltdl/.libs -L/usr/local/lib -lguile -lpthread -lgmp -lcrypt -o .libs/cygguile-srfi-srfi-1-v-2-2.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libguile-srfi-srfi-1-v-2.dll.a this fails, because gcc cannot figure out that /home/Hanwen/src/guile-1.7.1/libguile-ltdl/.libs/libguile.dll.a is the actual library to be linked. Manually adding libguile.dll.a to the command line results in a succesful link. I'm attaching libguile.la and libguile-srfi-srfi-1-v-2.la libguile-srfi-srfi-1-v-2.la Description: Binary data libguile.la Description: Binary data -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen -- 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/
libtool bug
[EMAIL PROTECTED] writes: > > > Hi, > > I'm trying to compile guile-1.7.1 on cygwin, with a recently installed > libtool, > > ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) > addendum: 1.5.10 has the same behavior. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen -- 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: Fw: cron doesnt run jobs (sometimes)!
At 11:50 AM 10/7/2004, you wrote: >- Original Message - >From: "Reini Urban" <[EMAIL PROTECTED]> >To: "russ" <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Thursday, October 07, 2004 1:22 AM >Subject: Re: cron doesnt run jobs (sometimes)! > > >> russ schrieb: >> >> > Hi there list! >> > >> > 1st off .im new to cygwin. >> > >> > i have built some scripts to do tape backups >> > basically a find, then a cpio, then tar it to tape. >> > >> > it runs from the command line. >> > >> > it doesnt run from crontab, although from event viewer i see that cron >ran. >> > >> > also i put another line in crontab to run ls -l >> /usr/tmp/test every >> > minute. >> > this works just fine!. >> > >> > ive lightly tapped all my scripts with chmod 777 still doesnt work! >> >> not the script! the data must be readable for SYSTEM. >> >> > btw its a win2k server (dc) >> > >> > >> > any ideas? >> >> check if it runs under okay in a "sysbash" shell. must be the permissions. >> >> search the ml archives for "sysbash". still not a package >> or run manually: >> > at /interactive bash --login -i >> >> -- >> Reini Urban >> http://xarch.tu-graz.ac.at/home/rurban/ > > > >Ah! it seems to work now. fantastic! >does anyone know how to get a system owned bash shell from an RDP session, i >can only get one >at the console. which is 300 miles away :-< You can run it from an rxvt or xterm and reroute that way if you want/need. Or the VNC route should allow you to see what you need without being local. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Add requirement for SYSTEMROOT to FAQ?
At 05:07 PM 10/7/2004, you wrote: >In any case, I don't think an attempt to be helpful warrents a snippy >response. Maybe I've been on this list too long but I didn't find Chris's response to be snippy at all. Just very descriptive and declarative. To each his own. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ssh/BitKeeper connection does not work on cygwin1.5.11?
On Thursday 07 October 2004 14:25, Karl M wrote: > Hi Andrew... > > Are those usere using Windows XP SP2? yes, it is XP with SP2 > If so, this sounds like the pipe > problem with cygwin on XP SP2 that is being worked. Thanks, that helps a lot.. > > Thanks, > > ...Karl > > From: Andrew Chang To: [EMAIL PROTECTED] > > >Subject: ssh/BitKeeper connection does not work on cygwin1.5.11? > >Date: Thu, 7 Oct 2004 13:32:07 -0700 > > > >I have a few user reporting the following problem: > >After upgrading from cygwin 1.5.10-3 to cygwin 1.5.11; > > Using Bitkeeper over a ssh connection just hang after the > > password prompt. > > > >[I can reproduce it at will too] > >I ran the test with the same version of openssh (3.9.p1) > >It worked in cygwin1.5.10 and failed in cygwin1.5.11. > >Does anyone had any idea what caused this? > > > >Thanks > >Andrew Chang > > _ > Express yourself instantly with MSN Messenger! Download today - it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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: libtool bug
Hello Han-Wen,
> libtool: install: warning: relinking `libguile-srfi-srfi-1-v-2.la'
I saw also problems with the useless relinking, I think it is time to
remove this for Cygwin completely. I have already fixed it in my
local copy:
$ diff -ud ltmain.sh.old ltmain.sh
--- ltmain.sh.old 2004-10-08 01:56:36.797564800 +0200
+++ ltmain.sh 2004-10-02 02:24:08.852576000 +0200
@@ -2416,7 +2416,7 @@
{ test "$prefer_static_libs" = no || test -z "$old_library"; }; then
if test "$installed" = no; then
notinst_deplibs="$notinst_deplibs $lib"
- need_relink=yes
+ need_relink=no
fi
# This is a shared library
Gerrit
--
=^..^=
--
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: Add requirement for SYSTEMROOT to FAQ?
There is a snapshot up there now which contains Corinna's workaround for this problem. We both came up with very similar solutions to the problem. So that means it just has to be perfect. Please try out the snapshot: http://cygwin.com/snapshots/ . 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: Spurious "You have multiple copies of cygwin1.dll on your syste m."
On 7 Oct, Igor Pechtchanski wrote: > On Thu, 7 Oct 2004, luke.kendall wrote: > > > On 7 Oct, Christopher Faylor wrote: > > > On Thu, Oct 07, 2004 at 02:49:29PM +1000, [EMAIL PROTECTED] wrote: > > Erghm... We all make mistakes. :-) > > > >After installing Cygwin by using a shell script running by executing > > > >bash from a network-installed Cygwin, the script fails when it tries to > > > >run a post-install script. The error reported is: > > > > > > > >bash-2.05b$ post-install.sh -which latest -fresh > > > >c:\cygwin\bin\bash.exe (3208): *** cygheap version mismatch detected - > > > > 0x616D/0x6178. > > > >You have multiple copies of cygwin1.dll on your system. > > > >Search for cygwin1.dll using the Windows Start->Find/Search facility > > > >and delete all but the most recent version. The most recent version > > > > *should* > > > >reside in x:\cygwin\bin, where 'x' is the drive on which you have > > > >installed the cygwin distribution. > > > > > > > >A search showed that there really is only c:\cygwin\bin\cygwin1.dll - > > > >the message is wrong. > > > > > > > >I'd say the sanity-check is detecting cygwin1.dll associated with the > > > >bash that's running from the network-mounted drive. > > > > > > You wouldn't say that if you knew what "cygheap" was. This is an > > > indication that a child executable is detecting that its cygheap is > > > not at the same location as the parent. Since the cygheap lives at > > > the end of the cygwin DLL it's hard to see how this could be anything > > > other than two different versions of cygwin being invoked. > > > > Okay, and in fact there are two (possibly different) versions of > > cygwin1.dll available to be loaded into memory. I don't know why > > Cygwin attempted to load the freshly-installed cygwin1.dll, though. > > It wasn't on the PATH of the network-loaded shell script. > > As Dave said, Windows loads the DLLs from the app directory before going > through the PATH. I'd bet there's a /bin/sh (or something of the sort) > call in the post-install script, which, after you've changed the mounts, > points to c:/bin (which is the newly-installed Cygwin). Ah, I'll bet you're right. I can invoke them directly via sh/bash. > Basically, it's not enough to share the network directory -- you also have > to have the "/", "/usr/bin", and "/usr/lib" mounts pointing to it for the > network copy of Cygwin to work properly. So, your mount changing idea may > not be so off the mark after all, but in the other direction (i.e., switch > "/" back to the network drive)... Erm, yes. But to just run shell scripts and things like grep, sed, etc., do you think I might get away without them? Because, as you say: > Unfortunately, anything written to > those directories will then also go back to the network drive, which isn't > what you want. Sort of a Catch-22 here... Yes. I'm about to start investigating what's happened to /etc/profile and a whole bunch of other files in /etc that aren't there following my 2nd trial of the shell-driven install, with /tmp mounted (but not /). It may be as simple as doing a mount c:/cygwin / before starting setup.exe. > One question is: do you have to use the actual POSIX paths in your install > script? If you can have a uniquely-named mount (say, "/local-install"), > and use that in your install script (e.g., "/local-install/bin", etc), you > should be able to circumvent this issue. Since you're the administrator, > you can just decree that your users shan't have a mount named > "/local-install" on their existing Cygwin installations). I don't quite understand, though I can see roughly the value in using unique mount points to separate the network Cygwin from the installed (or about-to-be-upgraded) Cygwin. I need to have "/" mounted on the local filesystem. So if I make a /local-install directory under /, and mount the network Cygwin filesystem there, and set PATH to have that first, and always run #!/bin/sh scripts by explicit "sh the-script", then it should be okay? > > To be pedantic, the warning is wrong because it says you have multiple > > copies of cygwin1.dll on your system. There aren't, and indeed a > > Search for cygwin1.dll using the Windows Start->Find/Search facility > > confirms that there is only a single cygwin1.dll, freshly installed. > > Well, network drives are technically drives on your system too. If you > can't find multiple copies of cygwin1.dll on your local drives, but an > extra copy exists on a network drive, the error is correct. :-) I think you're stretching things a little there. :-) Most people wouldn't consider network filesystems to be "on" their system. But since I'm being very pedantic anyway, I shouldn't argue any more about that. :-) > > Try this: from a machine on your network, with Cygwin installed, share > > the c:/cygwin directory (i.e. the path where you installed Cygwin). > > > > On another PC, start
Re: Spurious "You have multiple copies of cygwin1.dll on your syste m."
On Fri, Oct 08, 2004 at 10:53:30AM +1000, [EMAIL PROTECTED] wrote: >On 7 Oct, Igor Pechtchanski wrote: >> On Thu, 7 Oct 2004, luke.kendall wrote: >> >> > On 7 Oct, Christopher Faylor wrote: >> > > On Thu, Oct 07, 2004 at 02:49:29PM +1000, [EMAIL PROTECTED] wrote: >> >> Erghm... > >We all make mistakes. :-) and we all make conscious decisions. >>>To be pedantic, the warning is wrong because it says you have multiple >>>copies of cygwin1.dll on your system. There aren't, and indeed a >>>Search for cygwin1.dll using the Windows Start->Find/Search facility >>>confirms that there is only a single cygwin1.dll, freshly installed. >> >>Well, network drives are technically drives on your system too. If you >>can't find multiple copies of cygwin1.dll on your local drives, but an >>extra copy exists on a network drive, the error is correct. > >:-) I think you're stretching things a little there. :-) Most people >wouldn't consider network filesystems to be "on" their system. But >since I'm being very pedantic anyway, I shouldn't argue any more about >that. :-) No, we are not stretching things. Most people would assume that they had to search for everything accessible to their system when they were being told that there was another copy of cygwin interfering. The logic of thinking "Oh, this is a network drive so it couldn't *possibly* be affecting anything to do with cygwin", is really nonsensical given that you are installing cygwin applications on the network drive. Assuming that the error was so precise as to pinpoint only local drives makes no sense. >> > I freely confess I'm doing something unusual. Maybe I'm the first >> > person on the planet to attempt to automate Cygwin installation via a >> > shell script from an already existing and stable copy of Cygwin >> > installed elsewhere on the network? >> >> Likely you are. There just aren't that many people using Cygwin, > >?! I would have thought tens of thousands minimum, but you'd know >better than me. It is at least tens of thousands, yes. Geoff Noer used to claim that cygwin downloads numbered in the millions. >>that this is in no way approved by the Cygwin team: >> >>*If* you know what you're doing, and *if* you're careful, and *if* you >>have a real need (which I suspect you do in this case), you *can* run >>two mismatched versions of Cygwin occasionally. Take a look at the way >>the Cygwin test suite is run -- it runs with a newly-built DLL all the >>time. Note that you'll need to have a unique cygheap id for the >>network copy of Cygwin that is guaranteed to differ from any installed >>Cygwin's id. The easiest way to do that is have your network Cygwin >>built with debugging enabled. As long as you don't try doing anything >>exotic (e.g., start network services using both copies of cygwin1.dll), >>it should work. > >So far I've never built a Cygwin from source, and it may require more >time than I scrape together away from my real work. If I've >understood, you're saying that you link the cygwin1.dll with a >different BASE address? But from W2K on, Windows allows the loading of >different versions of the same DLL, provided you use full pathnames >(and the paths are different, obviously). No, that's not what he's saying and I would really not recommend using the approach that the test suite uses. The test suite gets away with it because it is designed to avoid cross-pollination between different cygwin versions. Unless you know what you're doing, you shouldn't even consider using this technique. For your problem, in particular, you are asking for trouble. 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: Spurious "You have multiple copies of cygwin1.dll on your system."
On Fri, 8 Oct 2004, luke.kendall wrote: > On 7 Oct, Igor Pechtchanski wrote: > > On Thu, 7 Oct 2004, luke.kendall wrote: > > > > > On 7 Oct, Christopher Faylor wrote: > > > > On Thu, Oct 07, 2004 at 02:49:29PM +1000, [EMAIL PROTECTED] wrote: > > > > Erghm... > > We all make mistakes. :-) Well, "erghm" to you, then... Could you please add a fullname to your e-mail address, so that these mistakes happen less often? ;-) > > > > >After installing Cygwin by using a shell script running by executing > > > > >bash from a network-installed Cygwin, the script fails when it tries to > > > > >run a post-install script. The error reported is: > > > > > > > > > >bash-2.05b$ post-install.sh -which latest -fresh > > > > >c:\cygwin\bin\bash.exe (3208): *** cygheap version mismatch detected - > > > > > 0x616D/0x6178. > > > > >You have multiple copies of cygwin1.dll on your system. > > > > >Search for cygwin1.dll using the Windows Start->Find/Search facility > > > > >and delete all but the most recent version. The most recent version > > > > > *should* > > > > >reside in x:\cygwin\bin, where 'x' is the drive on which you have > > > > >installed the cygwin distribution. > > > > > > > > > >A search showed that there really is only c:\cygwin\bin\cygwin1.dll - > > > > >the message is wrong. > > > > > > > > > >I'd say the sanity-check is detecting cygwin1.dll associated with the > > > > >bash that's running from the network-mounted drive. > > > > > > > > You wouldn't say that if you knew what "cygheap" was. This is an > > > > indication that a child executable is detecting that its cygheap is > > > > not at the same location as the parent. Since the cygheap lives at > > > > the end of the cygwin DLL it's hard to see how this could be anything > > > > other than two different versions of cygwin being invoked. > > > > > > Okay, and in fact there are two (possibly different) versions of > > > cygwin1.dll available to be loaded into memory. I don't know why > > > Cygwin attempted to load the freshly-installed cygwin1.dll, though. > > > It wasn't on the PATH of the network-loaded shell script. > > > > As Dave said, Windows loads the DLLs from the app directory before going > > through the PATH. I'd bet there's a /bin/sh (or something of the sort) > > call in the post-install script, which, after you've changed the mounts, > > points to c:/bin (which is the newly-installed Cygwin). > > Ah, I'll bet you're right. I can invoke them directly via sh/bash. > > > Basically, it's not enough to share the network directory -- you also have > > to have the "/", "/usr/bin", and "/usr/lib" mounts pointing to it for the > > network copy of Cygwin to work properly. So, your mount changing idea may > > not be so off the mark after all, but in the other direction (i.e., switch > > "/" back to the network drive)... > > Erm, yes. But to just run shell scripts and things like grep, sed, > etc., do you think I might get away without them? Nope. Read on. > Because, as you say: > > > Unfortunately, anything written to those directories will then also go > > back to the network drive, which isn't what you want. Sort of a > > Catch-22 here... > > Yes. I'm about to start investigating what's happened to /etc/profile > and a whole bunch of other files in /etc that aren't there following my > 2nd trial of the shell-driven install, with /tmp mounted (but not /). > It may be as simple as doing a mount c:/cygwin / before starting > setup.exe. That's if you want to run local install scripts using the local install (which may not be fully installed yet -- catch-22 again) [meta-note: have I used the word "install" often enough?]. As I see it, there are two issues: the one I just mentioned (incomplete install), and triggering Cygwin processes using the local cygwin1.dll from a shell using the remote cygwin1.dll. The latter I already mentioned a solution for; risking the former is a judgement call. > > One question is: do you have to use the actual POSIX paths in your > > install script? If you can have a uniquely-named mount (say, > > "/local-install"), and use that in your install script (e.g., > > "/local-install/bin", etc), you should be able to circumvent this > > issue. Since you're the administrator, you can just decree that your > > users shan't have a mount named "/local-install" on their existing > > Cygwin installations). > > I don't quite understand, though I can see roughly the value in using > unique mount points to separate the network Cygwin from the installed > (or about-to-be-upgraded) Cygwin. The idea is that your install script will treat the local Cygwin installation as just another data directory tree. You could use templates to generate config files, etc -- if your installations are standardized, you may even get away with it... :-) > I need to have "/" mounted on the local filesystem. Note: eventually. You can re-mount everything locally after you've finished running
RE: qmail, DJB licensing
[Making a conscious decision to snip in-the-clear email addresses, because I'm not Above The Law] > Reini Urban wrote: > > > So we could follow Igor's suggestion providing the sources in the > > binary package and compile it after download. > >http://www.cygwin.com/ml/cygwin/2003-05/msg01654.html > > At least better than nothing. exim would need a comparative and > > simplier MTA. > > > > I failed with trying to do some heavy processing with my new > > postgresql postinstall script. The compile step in a postinstall > > script would need to open a seperate console detached from > setup.exe > > probably. Otherwise I see no light. > > I don't see why you're interested in making an extremely > unwieldy pseudo-binary package for this. It just seems like > a nightmare to support for both packagers and users, all > because DJB won't let you distribute anything but pristine sources. > > Does maildir even work without resorting to managed mounts? Nope, it can't. Special chars in the filenames which Windows either doesn't support at all or treats differently than Unii. Maildir is a decent idea implemented in a non-POSIX, non-portable manner. -- 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: qmail, DJB licensing
Gary R. Van Sickle schrieb: >cgf: Does maildir even work without resorting to managed mounts? Nope, it can't. Special chars in the filenames which Windows either doesn't support at all or treats differently than Unii. Maildir is a decent idea implemented in a non-POSIX, non-portable manner. And thinking of it longer, it will only make sense on a decent fast filesystem with so many files in the dirs. ReiserFS e.g. We even added the quota (size in bytes) to the filename in our maildir hack, so that a single readdir gives us the complete size of the dir. No stat's of the files needed. NTFS is way too slow, only simple mboxes work fine. Same would go for news servers. Don't we have one? Hmm. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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: Spurious "You have multiple copies of cygwin1.dll on your syste m."
On 7 Oct, Igor Pechtchanski wrote: > On Fri, 8 Oct 2004, luke.kendall wrote: > > > On 7 Oct, Igor Pechtchanski wrote: > > > On Thu, 7 Oct 2004, luke.kendall wrote: > > > > > > > On 7 Oct, Christopher Faylor wrote: > > > > > On Thu, Oct 07, 2004 at 02:49:29PM +1000, [EMAIL PROTECTED] wrote: > > > > > > Erghm... > > > > We all make mistakes. :-) > > Well, "erghm" to you, then... Could you please add a fullname to your > e-mail address, so that these mistakes happen less often? ;-) Apologies, I hadn't understood that the source of the error was me. Unfortunately I think I'm overdue to change over to a new MUA - despite having "Use From Address" set to: "Luke Kendall" [EMAIL PROTECTED] it doesn't seem to do the right thing. So I'll just have to suffer until I change clients, which seems fair. > > Ah, I'll bet you're right. I can invoke them directly via sh/bash. > > > > > Basically, it's not enough to share the network directory -- you also have > > > to have the "/", "/usr/bin", and "/usr/lib" mounts pointing to it for the > > > network copy of Cygwin to work properly. So, your mount changing idea may > > > not be so off the mark after all, but in the other direction (i.e., switch > > > "/" back to the network drive)... > > > > Erm, yes. But to just run shell scripts and things like grep, sed, > > etc., do you think I might get away without them? > > Nope. Read on. > > > Because, as you say: > > > > > Unfortunately, anything written to those directories will then also go > > > back to the network drive, which isn't what you want. Sort of a > > > Catch-22 here... > > > > Yes. I'm about to start investigating what's happened to /etc/profile > > and a whole bunch of other files in /etc that aren't there following my > > 2nd trial of the shell-driven install, with /tmp mounted (but not /). > > It may be as simple as doing a mount c:/cygwin / before starting > > setup.exe. > > That's if you want to run local install scripts using the local install > (which may not be fully installed yet -- catch-22 again) [meta-note: have > I used the word "install" often enough?]. :-) Yes. But I don't want to run local install scripts using the local (incomplete) s=install. I want to run them on the local system from a complete network install of Cygwin on, say, a fileserver. > As I see it, there are two > issues: the one I just mentioned (incomplete install), and triggering > Cygwin processes using the local cygwin1.dll from a shell using the remote > cygwin1.dll. The latter I already mentioned a solution for; risking the > former is a judgement call. I wouldn't dream of attempting the former - running from an incomplete install would be asking for huge amounts of endless trouble. > > > One question is: do you have to use the actual POSIX paths in your > > > install script? If you can have a uniquely-named mount (say, > > > "/local-install"), and use that in your install script (e.g., > > > "/local-install/bin", etc), you should be able to circumvent this > > > issue. Since you're the administrator, you can just decree that your > > > users shan't have a mount named "/local-install" on their existing > > > Cygwin installations). > > > > I don't quite understand, though I can see roughly the value in using > > unique mount points to separate the network Cygwin from the installed > > (or about-to-be-upgraded) Cygwin. > > The idea is that your install script will treat the local Cygwin > installation as just another data directory tree. You could use templates > to generate config files, etc -- if your installations are standardized, > you may even get away with it... :-) That's what I do, including a post-install after the Cygwin installation is complete. This all works fine if kicked off from a DOS ..bat file, but that can't be guaranteed to work because the batch file can't know that the user actually installed Cygwin in the standard place, so can't necessarily find the installed bash to run the post-install script. That's my motivation for .sh scripting the install rather than .bat scripting it. Well, that plus the ten times greater effort to write a ..bat script rather than a .sh script. > > I need to have "/" mounted on the local filesystem. > > Note: eventually. You can re-mount everything locally after you've > finished running your install scripts (as a last step of the install > script, in fact). Really? I thought that setup.exe ran a lot of shell scripts as part of the package post-installs, and these of course expect to find / and /etc and install and modify config files there. > > So if I make a /local-install directory under /, and mount the network > > Cygwin filesystem there, and set PATH to have that first, and always run > > #!/bin/sh scripts by explicit "sh the-script", then it should be okay? > > Nope. What if those scripts invoke /bin/grep? Or /usr/bin/perl? That would seem like bad practice to use explicit paths. T
Re: Spurious "You have multiple copies of cygwin1.dll on your syste m."
On 7 Oct, Christopher Faylor wrote: > I've mentioned that mutt does this automatically if there is no user name > associated with an email address. I am not going to go out of my way > to police my email if a person is going to send their mail in a nonstandard > way. > > So you can save yourself the extra 15 seconds a month that you expend every > time this happens. I'm not going to bother with this corner case and you > don't need to admonish me every time it happens. That's perfectly fair. I'm the one at fault there, for not being able to include a fullname in my from address. luke -- 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: libtool bug
Gerrit P. Haase wrote:
$ diff -ud ltmain.sh.old ltmain.sh
--- ltmain.sh.old 2004-10-08 01:56:36.797564800 +0200
+++ ltmain.sh 2004-10-02 02:24:08.852576000 +0200
@@ -2416,7 +2416,7 @@
{ test "$prefer_static_libs" = no || test -z "$old_library"; }; then
if test "$installed" = no; then
notinst_deplibs="$notinst_deplibs $lib"
- need_relink=yes
+ need_relink=no
fi
# This is a shared library
Obviously, this patch can't go back to the "real" libtool because it
turns off relinking for all platforms, not just cygwin. I'm testing
something related in the libtool-2.0pre baseline...stay tuned.
I recall this came up earlier but I can't find it in the archives. What
was my objection back then? I'm sure someone objected, because
otherwise it would have gone in; and I'm sure it was me, because nobody
else cares about the libtool internals. :-)
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Spurious "You have multiple copies of cygwin1.dll on your syste m."
On 8 Oct, [EMAIL PROTECTED] wrote: > Now to see if I can find where /etc/profile went, and if no joy, try > again with the modified scripts and new knowledge... No joy. /etc/profile, passwd, and group were simply missing. Even doing a grep for /etc/profile in setup.log and .full showed no errors or warnings that mentioned /etc/profile. (In fact, a grep -i for warning or error only showed installation of files with that as part of their name - i.e. it seemed like a clean install). It seems possible to me that it's something I've done wrong. I'll scrub Cygwin again from the test machine and try again with my improved scripts. The reason I suspect me, is that /etc/passwd didn't exist, even after running the script that runs the mkpasswd and mgroup commands to fully populate both. There is a /etc/defaults/etc/profile, it just doesn't seem to have been installed. Maybe a side-effect of doing a mount of "/" in the previous test attempt before this last one. Anyway, I'll try again now. BTW, since Dave Korn replied to this: > > I freely confess I'm doing something unusual. Maybe I'm the first > > person on the planet to attempt to automate Cygwin installation via a > > shell script from an already existing and stable copy of Cygwin > > installed elsewhere on the network? Dave: > It's possible. Is there a reason you aren't using setup.exe? It's > automatable and easily customisable and it has the benefit in this situation > of being a plain non-cygwin win32 exe. I should clarify that I *am* using Cygwin's setup.exe - the scripts just do all the other automation around that: Advise installer of local URLs for local stable/latest cygwin mirrors. Report on completeness/incompleteness of local mirror, with warning if incomplete. Start appropriate setup.exe for them (stable/latest), with extra arguments. Fix problem in WindowMaker by modifying "exitscript". Provide simple, reliable, flexible X startup script. Detect home mount point for local conventions. Setup home directory upon 1st login. Configure sshd. Check ownership of and fix /etc/ssh* and /var/empty. Fix enscript.cfg to use A4 for paper size. Configure ssmtp for local settings. Install extra local utility files. Test for updated local utility files and auto-install any. Setup links to various local network utilities. Add .sh script under /etc/profile.d for extra local login stuff. Create some extra desktop shortcuts and Start Menu Cygwin menu items. Setup default .xinitrc and .profile. Provide auto-remapping of shared drives when laptops are off network. Install CygwinPromptHere. Fix X font problem on stable Cygwin snapshot; fix man JNROFF stuff on latest Cygwin snapshot. And possibly other things I've forgotten. luke -- 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: compilig error: storage size of `st' isn't known (FAQ alert)
On Wed, 6 Oct 2004 11:13:46 -0400, Christopher Faylor <[EMAIL PROTECTED]> wrote: > >What needs to be done in Cygwin to see "struct stat" ? > > There is no stat64 in cygwin. Use stat. > > This. Is a recording. > > I guess it should be a FAQ. Well, OK, it will be. -- 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: Add requirement for SYSTEMROOT to FAQ?
On Thu, 7 Oct 2004 20:37:07 -0400, Christopher Faylor <[EMAIL PROTECTED]> wrote: > There is a snapshot up there now which contains Corinna's workaround for > this problem. We both came up with very similar solutions to the > problem. So that means it just has to be perfect. > > Please try out the snapshot: http://cygwin.com/snapshots/ . Um, so is there any need for a FAQ then? -- 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: Memory debugging under cygwin
Dan Osborne wrote: Could you get the test program to work? That shows how it wants to play. The only problem I found with it was that it wouldn't follow shared objects. Yeah, that seems to be the problem I have to. Unfortunately the memory corruption I'm looking for is *in* a shared object. And compiling the whole app static isn't an option, because it also involves a dynamically loaded module :( Great shame that valgrind isn't ported to cygwin! Yup... Maarten -- 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/
