[Packaging error] Re: [ANNOUNCEMENT] Updated: ccache-3.1.9-1 (x86 / x86_64)
> Christopher Faylor writes: > A new version of ccache is now available. ccache is a C compiler cache > for improving recompilation. This version is just a refresh of the > package from upstream sources. This package contains an empty /usr/man/man1 directory. Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
SIGKILL and TerminateProcess
Hello List, I have a question, as to why CYGWIN does not use the TerminateProcess approach when dealing with SIGKILL sent to a process (in the manner the CYGWIN's own kill utility does when invoked with -f)? Usually SIGKILL is expected to reliably terminate its victim (let alone it can't be intercepted, hence, does not need any "handling" provisions). Yet under CYGWIN, if the point of execution is found as "unsafe" in the target process, the signal cannot be delivered quickly. Such as when the process is busy dealing with a time-consuming Windows API (the dumbest example is Sleep() ;-), then the process will not get killed even with SIGKILL. Could CYGWIN please consider special-casing SIGKILL to perform something similar to the force-killing of the command-line utility? Thanks, Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
fork() and NT error 0xC0000135 (STATUS_DLL_NOT_FOUND)
Hello All,
I can't find a similar problem reported earlier, so please excuse the question
if it looks familiar.
We have a software package that installs like a miniature CYGWIN deployment
(basically, only cygwin1.dll and just a few other libraries in /bin
along with cygrunsrv.exe), and there are no shells.
cygrunsrv.exe is used to register and launch a Windows service with a binary
located under "/opt/..." (which is a ported UNIX server). The binary is started
just fine, but when it tries to fork(), it gets the error 0xC135 (w/
errno=11,
EAGAIN). I traced it down to the fact that before fork() there is chdir("/") in
that server binary. Can it be the reason for the failed fork() that it can no
longer
find cygwin1.dll? Unfortunately, I can't extend Windows PATH to include the
CYGWIN /bin directory (because the cygrunsrv runs under an unmanaged service
account). Is there any other fix?
Thanks,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Some first questions.
Hello list. I have some first questions for cygwin works on windows 7 by compile sources I normally just fine compile on my linux systems but not like to compile well and by cygwin. The sources I trying to compile is been packed on linux with tar archiwing program so I can get the sources over to windows 7 and cygwin. So it is then this then. 1. where is the best place to unpack the sources for compile by cygwin. My windows cygwin is installed on c:\cygwin and by installing cygwin is the cygwin download sources been put at k:\cygwinsrc. 2. if the extra sources is best to be places at k:\cygwin, then is it then best to handle them for cygwin ? 3. Then is it that - the sources have makefiles .cyg and other compilers + some main configs like Makefile and huskymak.cfg. When I have copied the file makefile.cyg to makefile.cfg and then have this file in the main home dir for example - \...\husky\smapi\ and then is got in to \smapi source dir and then run make to compile the sources for smapi goes it fine to I getting a error of gcc -mno-cygwin and then error 2 of it not can find some file it should make and when I checking out for the file is it where it should be by not compile to make a .o files for more compile finish. Regards, Gert -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fork() and NT error 0xC0000135 (STATUS_DLL_NOT_FOUND)
On 10/29/2013 12:13 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Hello All,
I can't find a similar problem reported earlier, so please excuse the question
if it looks familiar.
We have a software package that installs like a miniature CYGWIN deployment
(basically, only cygwin1.dll and just a few other libraries in /bin
along with cygrunsrv.exe), and there are no shells.
cygrunsrv.exe is used to register and launch a Windows service with a binary
located under "/opt/..." (which is a ported UNIX server). The binary is started
just fine, but when it tries to fork(), it gets the error 0xC135 (w/
errno=11,
EAGAIN). I traced it down to the fact that before fork() there is chdir("/") in
that server binary. Can it be the reason for the failed fork() that it can no
longer
find cygwin1.dll? Unfortunately, I can't extend Windows PATH to include the
CYGWIN /bin directory (because the cygrunsrv runs under an unmanaged service
account). Is there any other fix?
I'll go out on a limb and say that all UNIX/POSIX platforms expect /bin
and/or /usr/bin to be in your path if you're not specifying an absolute
path when invoking your binaries. This is not an unusual expectation
and isn't confined to the UNIX/POSIX world. There isn't any "fix" that
will be forthcoming in the Cygwin DLL that will change this expectation,
though there may be others on this list that have some clever workarounds
that you could try.
--
Larry
_
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fork() and NT error 0xC0000135 (STATUS_DLL_NOT_FOUND)
On Oct 29 13:15, Larry Hall (Cygwin) wrote:
> On 10/29/2013 12:13 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> >Hello All,
> >
> >I can't find a similar problem reported earlier, so please excuse the
> >question
> >if it looks familiar.
> >
> >We have a software package that installs like a miniature CYGWIN deployment
> >(basically, only cygwin1.dll and just a few other libraries in /bin
> >along with cygrunsrv.exe), and there are no shells.
> >
> >cygrunsrv.exe is used to register and launch a Windows service with a binary
> >located under "/opt/..." (which is a ported UNIX server). The binary is
> >started
> >just fine, but when it tries to fork(), it gets the error 0xC135 (w/
> >errno=11,
> >EAGAIN). I traced it down to the fact that before fork() there is
> >chdir("/") in
> >that server binary. Can it be the reason for the failed fork() that it can
> >no longer
> >find cygwin1.dll? Unfortunately, I can't extend Windows PATH to include the
> >CYGWIN /bin directory (because the cygrunsrv runs under an unmanaged service
> >account). Is there any other fix?
>
> I'll go out on a limb and say that all UNIX/POSIX platforms expect /bin
> and/or /usr/bin to be in your path if you're not specifying an absolute
> path when invoking your binaries. This is not an unusual expectation
> and isn't confined to the UNIX/POSIX world. There isn't any "fix" that
> will be forthcoming in the Cygwin DLL that will change this expectation,
> though there may be others on this list that have some clever workarounds
> that you could try.
Two points:
- cygrunsrv adds /bin to $PATH before calling the service executable.
- STATUS_DLL_NOT_FOUND does *not* imply that cygwin1.dll isn't found.
It could be any other DLL required by the executable but not in $PATH.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpPOZNVf0J1Q.pgp
Description: PGP signature
Re: SIGKILL and TerminateProcess
On Tue, Oct 29, 2013 at 03:47:47PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >Hello List, > >I have a question, as to why CYGWIN does not use the TerminateProcess approach >when >dealing with SIGKILL sent to a process (in the manner the CYGWIN's own kill >utility >does when invoked with -f)? Usually SIGKILL is expected to reliably terminate >its victim (let alone it can't be intercepted, hence, does not need any >"handling" >provisions). Yet under CYGWIN, if the point of execution is found as "unsafe" >in the >target process, the signal cannot be delivered quickly. Such as when the >process is busy dealing with a time-consuming Windows API (the dumbest example >is Sleep() ;-), >then the process will not get killed even with SIGKILL. Could CYGWIN please >consider >special-casing SIGKILL to perform something similar to the force-killing of the >command-line utility? Sorry but we aren't going to redesign the signal delivery mechanism for your use case. Cygwin does not guarantee delivery of signals to processes which are calling Windows API functions directly. If you do that you should be prepared to deal with problems. If you are finding that SIGKILL does not reliably kill a blocking UNIX function, however, that is a bug. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fork() and NT error 0xC0000135 (STATUS_DLL_NOT_FOUND)
On Tue, Oct 29, 2013 at 04:13:14PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
wrote:
>Hello All,
>
>I can't find a similar problem reported earlier, so please excuse the question
>if it looks familiar.
>
>We have a software package that installs like a miniature CYGWIN deployment
>(basically, only cygwin1.dll and just a few other libraries in /bin
>along with cygrunsrv.exe), and there are no shells.
>
>cygrunsrv.exe is used to register and launch a Windows service with a binary
>located under "/opt/..." (which is a ported UNIX server). The binary is
>started
>just fine, but when it tries to fork(), it gets the error 0xC135 (w/
>errno=11,
>EAGAIN). I traced it down to the fact that before fork() there is chdir("/")
>in
>that server binary. Can it be the reason for the failed fork() that it can no
>longer
>find cygwin1.dll? Unfortunately, I can't extend Windows PATH to include the
>CYGWIN /bin directory (because the cygrunsrv runs under an unmanaged service
>account). Is there any other fix?
Cygwin doesn't rely on the PATH environment variable to find the binary
being forked. It would be disastrous if it did.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Some first questions.
On Tue, Oct 29, 2013 at 05:23:50PM +0100, Gert Koefoed Andersen wrote: >Hello list. > >I have some first questions for cygwin works on windows 7 by compile sources >I normally just fine compile on my linux systems but not like to compile >well and by cygwin. >The sources I trying to compile is been packed on linux with tar archiwing >program so I can get the sources over to windows 7 and cygwin. > >So it is then this then. >1. where is the best place to unpack the sources for compile by cygwin. That isn't really a question that is answerable. Make a directory and extract the files to it. No one can tell you the name of a directory to use. You can create a directory in your home directory or, e.g., create a /usr/src/foo directory and extract files there. It's entirely up to you. > My windows cygwin is installed on c:\cygwin and by installing cygwin is >the cygwin download sources been put at k:\cygwinsrc. >2. if the extra sources is best to be places at k:\cygwin, then is it then >best to handle them for cygwin ? Cygwin doesn't use paths like c:\cygwin. If your cygwin installation is c:\cygwin then that means that is your root directory: /. k:/cygwin would be referenced, by Cygwin, as /cygdrive/k/cygwin. It's ok if you want to put files there but you should use the Cygwin method for referencing this location. >3. Then is it that - the sources have makefiles .cyg and other compilers + >some main configs like Makefile and huskymak.cfg. >When I have copied the file makefile.cyg to makefile.cfg and then have this >file in the main home dir for example - \...\husky\smapi\ and then is got in >to \smapi source dir and then run make to compile the sources for smapi goes >it fine to I getting a error of gcc -mno-cygwin and then error 2 of it not >can find some file it should make and when I checking out for the file is it >where it should be by not compile to make a .o files for more compile >finish. -mno-cygwin is an ancient option that is no longer supported (it only took me 10 years or so to get rid of it). If you are building binaries which don't use Cygwin then you should use a mingw compiler, installed from setup.exe. Or, you should just be using MinGW directly from mingw.org. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: fork() and NT error 0xC0000135 (STATUS_DLL_NOT_FOUND)
> platforms expect /bin and/or /usr/bin to be in your path
I'm not following... cygrunsrv.exe is started by Windows service controller,
and then spawns the server binary. There's no point in this sequence of actions
to modify PATH. I also believe, PATH is made compliant with what POSIX
requirement
by that very cygwin1.dll implicitly (and that happens when cygrunsrv gets
launched,
so cygwin1.dll figures out the CYGWIN "root" directory, then evaluates the path
where
to expect all other CYGWIN dlls). For cygrunsrv, the server binary is
specified as an
absolute path with -p "/opt/path/to/bin/server.exe", which is within the
rudimentary
CYGWIN tree that also has "/bin" (rooted at some Windows directory,
C:\Apps\CYGWIN).
> Two points:
>
> - cygrunsrv adds /bin to $PATH before calling the service executable.
>
> - STATUS_DLL_NOT_FOUND does *not* imply that cygwin1.dll isn't found.
> It could be any other DLL required by the executable but not in $PATH.
>
Without chdir("/") fork() is able to succeed; and the server binary does not
depend on any other non-Windows DLLs that are not in the "/bin" CYGWIN
directory.
But with chdir("/") in place, if I insert (when manually simulating the very
same
failure from a limited user account) "C:\Apps\CYGWIN\bin" into Windows PATH
before
calling the server binary, it is able to fork successfully. (Without the
addition,
it fails same way with the same error 0xC0135 even when run interactively.)
Anton Lavrentiev
Contractor NIH/NLM/NCBI
RE: SIGKILL and TerminateProcess
> Sorry but we aren't going to redesign the signal delivery mechanism for > your use case. It wasn't exactly a redesign I was asking about; rather an addition (or an improvement, if you will) for only the case of that one KILL signal, which is already a special thing in all aspects even on UNIX. > Cygwin does not guarantee delivery of signals to processes which are > calling Windows API functions directly. If you do that you should be > prepared to deal with problems. Windows Sleep() was just a convenient dummy to demonstrate how SIGKILL does not kill. CYGWIN lets me access some Windows-specific APIs (the same way one would do by using some UNIX-flavor-specific libraries), without having to port them all to CYGWIN first. Such code becomes a real problem in pipelining because it cannot be reliably managed from other processes (which would all require modifications to do TerminateProcess tricks throughout; or use the special CYGWIN command-like utility) where just kill(9) would have been sufficient.. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SIGKILL and TerminateProcess
On Tue, Oct 29, 2013 at 06:37:46PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >> Sorry but we aren't going to redesign the signal delivery mechanism for >> your use case. > >It wasn't exactly a redesign I was asking about; rather an addition >(or an improvement, if you will) for only the case of that one KILL >signal, which is already a special thing in all aspects even on UNIX. As the person who wrote the signal handling code, I think I get to specify what I consider to be a redesign. >>Cygwin does not guarantee delivery of signals to processes which are >>calling Windows API functions directly. If you do that you should be >>prepared to deal with problems. > >Windows Sleep() was just a convenient dummy to demonstrate how SIGKILL >does not kill. You may notice that I didn't specify Sleep() in my explanation. >CYGWIN lets me access some Windows-specific APIs (the same way one >would do by using some UNIX-flavor-specific libraries), without having >to port them all to CYGWIN first. Such code becomes a real problem in >pipelining because it cannot be reliably managed from other processes >(which would all require modifications to do TerminateProcess tricks >throughout; or use the special CYGWIN command-like utility) where just >kill(9) would have been sufficient.. To be a broken record: The whole point of Cygwin is to run UNIX based programs on Windows. Asking for the addition of special-case code so that people can use Windows functions in their programs completely misses the point of this project. That said, however, the Cygwin "kill" command does have a "-f" option which forces the termination of a process if it can't be killed with Cygwin's signal mechanism (I added it so that I could kill processes that were hung while I was working on Cygwin's signal code). If it is essential that you be able to summarily terminate Windows programs then use that. Otherwise, I guarantee that continuing to insist that you need this will avail you naught. Your suggested change is not going to be implemented. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with multiprocessing module from Python
Le Fri, 25 Oct 2013 19:53:42 +, Jean-Pierre Flori a écrit : > Le Fri, 25 Oct 2013 17:08:50 +0200, Jean-Pierre Flori a écrit : >> This is true both with Cygwin's shipped Python 2.7.x and the one I >> built for Sage. >> Here is a small snippet of code reproducing the problem: >> """ >> [Blah python stuff] > from multiprocessing import Pool p = Pool(3) > p.map(anything suitable) >> ... >> ValueError: semaphore or lock released too many times """ >> This might be a problem with Python but I seem to remember succeeding >> in this test some time ago with the same version of Python. >> I tried Cygwin's GCC (4.7.3) and a custom built FSF GCC 4.8.2 without >> success. I also tried to replace Cygwin binaries with version 1.7.0 and >> a few others before 1.7.25 without apparent changes. >> So I'm a little lost now. >> >> Can anyone reporduce that? >> Any help would be appreciated! >> > For your info, I was unable to reproduce such a behavior on Cygwin 32 v > 1.7.25 installs running on 64 bits Windows 7 both on real hardware and > VirtualBox 4.3... > > JP I went on with further testing and could reproduce the problem with the Cygwin shipped Pythons on a 64 bit Windows 7 running under VirtualBox 4.3 with Cygwin 64 and on a 32 bit Windows 7 running on real hardware (intel Atom). Best, JP -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with multiprocessing module from Python
Le Tue, 29 Oct 2013 19:40:10 +, Jean-Pierre Flori a écrit : >> For your info, I was unable to reproduce such a behavior on Cygwin 32 v >> 1.7.25 installs running on 64 bits Windows 7 both on real hardware and >> VirtualBox 4.3... >> >> JP > I went on with further testing and could reproduce the problem with the > Cygwin shipped Pythons on a 64 bit Windows 7 running under VirtualBox > 4.3 with Cygwin 64 and on a 32 bit Windows 7 running on real hardware > (intel Atom). > > Best, > JP Same problem with Python 2.6.8 from Cygwin on the 32 bit Windows 7 running on Intel Atom. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with multiprocessing module from Python
On Tue, Oct 29, 2013 at 08:41:07PM +, Jean-Pierre Flori wrote: >Le Tue, 29 Oct 2013 19:40:10 +, Jean-Pierre Flori a ??crit??: >>> For your info, I was unable to reproduce such a behavior on Cygwin 32 v >>> 1.7.25 installs running on 64 bits Windows 7 both on real hardware and >>> VirtualBox 4.3... >>> >> I went on with further testing and could reproduce the problem with the >> Cygwin shipped Pythons on a 64 bit Windows 7 running under VirtualBox >> 4.3 with Cygwin 64 and on a 32 bit Windows 7 running on real hardware >> (intel Atom). >> >> Best, >> JP >Same problem with Python 2.6.8 from Cygwin on the 32 bit Windows 7 running >on Intel Atom. If you want this fixed, the easiest way to get that to happen is to post a simple test case which reproduces the problem. That is not the code snippet that you sent. A real working example would be required. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with multiprocessing module from Python
Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a écrit : > If you want this fixed, the easiest way to get that to happen is to post > a simple test case which reproduces the problem. That is not the code > snippet that you sent. A real working example would be required. Sorry about that. Here you go: """ from multiprocessing import Pool def f(x): return x p = pool(2) p.map(f, [1, 2]) """ Best, JP -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with multiprocessing module from Python
Le Tue, 29 Oct 2013 20:41:07 +, Jean-Pierre Flori a écrit : > Le Tue, 29 Oct 2013 19:40:10 +, Jean-Pierre Flori a écrit : >>> For your info, I was unable to reproduce such a behavior on Cygwin 32 >>> v 1.7.25 installs running on 64 bits Windows 7 both on real hardware >>> and VirtualBox 4.3... >>> >>> JP >> I went on with further testing and could reproduce the problem with the >> Cygwin shipped Pythons on a 64 bit Windows 7 running under VirtualBox >> 4.3 with Cygwin 64 and on a 32 bit Windows 7 running on real hardware >> (intel Atom). >> >> Best, >> JP > Same problem with Python 2.6.8 from Cygwin on the 32 bit Windows 7 > running on Intel Atom. Some additional info on another 64 bit Windows running on a Corei7: * no problem with Cygwin 32 up-to-date. * with Cygwin 64, i first tested with the old 1.7.22 which was installed and got "ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770." when issuing "p = Pool(2)"; then updated (to 1.7.25 as well as all packages) and got the "ValueError" as originally reported. Best, JP -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with multiprocessing module from Python
Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a écrit : > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a écrit : >> If you want this fixed, the easiest way to get that to happen is to >> post a simple test case which reproduces the problem. That is not the >> code snippet that you sent. A real working example would be required. > Sorry about that. > > Here you go: > """ > from multiprocessing import Pool > > def f(x): return x > > p = pool(2) > > p.map(f, [1, 2]) > """ And I managed to introduce a typo. The third line should read Pool, so it is: """ from multiprocessing import Pool def f(x): return x p = Pool(2) p.map(f, [1, 2]) """ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: gcc-4.8.2-1 (x86_64)
I have updated gcc for 64bit Cygwin to the latest released version. There aren't any Cygwin specific changes introduced since 4.8.1, so it should work similarly. The last 32bit 4.8.x build didn't go so well, will try again this weekend. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. signature.asc Description: OpenPGP digital signature
setup(32)-2.830 catching which processes are still running (neat, but...misses services)
New version of setup shows me which processes are running and offers to stop them.. neat. I stopped them manually as needed to make sure work was saved. Tried again... this time it said it was still in use: turns out it seems to miss all of the processes running as services. *cygserver/dbus-daemon.. Though it looks like it restarted them when it was done? Odd... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
"which gcc" doesn't work but "which gcc.exe" does
hi, i've just installed cygwin on a new windows 8.1 pro laptop and am having the wierd problem that i can't invoke gcc without actually typing "gcc.exe". e.g. $ gcc --version -bash: gcc: command not found $ gcc.exe --version gcc (GCC) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. ... similarly: $ which gcc which: no gcc in (...) $ which gcc.exe /usr/bin/gcc.exe this isn't happening for any other executable i've tried (e.g. ls, less, bash, make, ld) so it seems quite odd. cygcheck -sr shows some registry entries for a now-deleted 64bit cygwin installation but i don't know if that's important. the full output is below. thanks for any help, raf p.s. another odd thing is that running "cygcheck -sr >cygcheck-sr.out 2>&1" in Cygwin Terminal as the Administrator user produced a file with "\r\n" line endings (i.e. "ASCII text, with CRLF line terminators") but running it in Cygwin Terminal as a normal user produced a file with "\r\r\n" line endings (i.e. "ASCII text, with CRLF, LF line terminators"). why the difference? - output of "cygcheck -sr >cygcheck-sr.out 2>&1" as Administrator Cygwin Configuration Diagnostics Current System Time: Wed Oct 30 02:51:07 2013 Windows 8 Professional N Ver 6.2 Build 9200 Running under WOW64 on AMD64 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\Program Files (x86)\Intel\iCLS Client C:\Program Files\Intel\iCLS Client C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\Program Files\Intel\Intel(R) Management Engine Components\DAL C:\Program Files\Intel\Intel(R) Management Engine Components\IPT C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT C:\Program Files (x86)\Windows Live\Shared C:\Program Files\Intel\WiFi\bin C:\Program Files\Common Files\Intel\WirelessCommon C:\Python27 C:\Python27\Scripts C:\Program Files (x86)\PostgreSQL\9.3\lib C:\Program Files (x86)\PostgreSQL\9.3\bin Output from C:\cygwin\bin\id.exe UID: 1001(mary) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'mary' PWD = '/home/mary' HOME = '/home/mary' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\C:\cygwin64' c5e39b7a9d22bafb = '\??\C:\cygwin' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin User: Key: e022582115c10879 Path: C:\cygwin64 (ORPHANED) User: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS939939Mb 5% CP CS UN PA FC OS d: cd N/AN/A C:\cygwin/ system binary,auto C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,posix=0,auto Found: C:\cygwin\bin\awk -> C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\WINDOWS\system32\find.exe Found: C:\cygwin\bin\gcc.exe Found: C:\cygwin\bin\gcc Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Not Found: patch Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Found: C:\cygwin\bin\vi.exe Found: C:\cygwin\bin\vim.exe 449k 2013/01/01 C:\cygwin\bin\cygasn1-8.dll 14k 2012/05/04 C:\cygwin\bin\cygattr-1.dll 62k 2011/05/21 C:\cygwin\bin\cygbz2-1.dll 115k 2013/04/11 C:\cygwin\bin\cygcloog-0.dll 10k 2013/03/11 C:\cygwin\bin\cygcom_err-2.dll 7k 2012/05/07 C:\cygwin\bin\cygcrypt-0.dll 1518k 2013/02/12 C:\cygwin\bin\cygcrypto-1.0.0.dll 929k 2011/11/10 C:\cygwin\bin\cygdb-4.5.dll 93k 2011/11/10 C:\cygwin\bin\cygdb_cxx-4.5.dll 159k 2013/10/20 C:\cygwin\bin\cygedit-0.dll 153k 2013/07/31 C:\cygwin\bin\cygexpat-1.dll 43k 2010/01/02 C:\cygwin\bin\cygform-10.dll 47k 2010/01/02 C:\cygwin\bin\cygformw-10.dll 103k 2013/06/16 C:\cygwin\bin\cyggcc_s-1.dll 19k 2009/02/26 C:\cygwin\bin\cyggdbm-4.dll 8k 2009/02/26 C:\
Re: fork() and NT error 0xC0000135 (STATUS_DLL_NOT_FOUND)
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]!
> I can't find a similar problem reported earlier, so please excuse the question
> if it looks familiar.
> We have a software package that installs like a miniature CYGWIN deployment
> (basically, only cygwin1.dll and just a few other libraries in /bin
> along with cygrunsrv.exe), and there are no shells.
> cygrunsrv.exe is used to register and launch a Windows service with a binary
> located under "/opt/..." (which is a ported UNIX server). The binary is
> started
> just fine, but when it tries to fork(), it gets the error 0xC135 (w/
> errno=11,
> EAGAIN). I traced it down to the fact that before fork() there is chdir("/")
> in
> that server binary. Can it be the reason for the failed fork() that it can
> no longer
> find cygwin1.dll? Unfortunately, I can't extend Windows PATH to include the
> CYGWIN /bin directory (because the cygrunsrv runs under an unmanaged service
> account). Is there any other fix?
Add cygwin1.dll to the list of known system libraries.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
May help.
But this doesn't change the fact that the server SHOULD NOT unconditionally
change the CWD to the ROOT of a file system.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 30.10.2013, <10:44>
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
