Re: checking for working mmap...no

2004-09-15 Thread egor duda 
Sam Steingold wrote:
It appears that cygwin mmap() is lacking:
configure:20536: checking for working mmap
configure:20617: gcc -o conftest.exe -g -O2 conftest.c  >&5
configure:20620: $? = 0
configure:20622: ./conftest.exe
configure:20625: $? = 1
configure: program exited with status 1
configure: failed program was:
Maybe this:
http://www.cygwin.com/ml/cygwin/2000-09/msg00380.html
is the reason?
egor
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: cvs-1.11.17-1

2004-09-15 Thread Charles Wilson 
CVS is the 'Concurrent Versioning System', a widely-used package for 
maintianing revision histories of source code.  This port is based on 
the official cvs-1.11.17 release, and requires that libgdbm4-1.8.3-7 be 
installed as well.

CHANGES:

* updated to the latest release (thanks to Volker Quetschke for doing 
the heavy lifting)

-- 
Charles Wilson
cvs volunteer maintainer for cygwin

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

   *** 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:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.






--
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/

9-15 snap has newlib prob?

2004-09-15 Thread Gary R. Van Sickle 
Chris,

Did you build the 9-15 snapshot with the newlib problem?  I'm getting the
same symptom as the ones that did, i.e. bash hangs on startup and you never
get a prompt.

-- 
Gary R. Van Sickle
Brewer.  Patriot.


--
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: checking for working mmap...no

2004-09-15 Thread Igor Pechtchanski 
On Wed, 15 Sep 2004, Sam Steingold wrote:

> > * Christopher Faylor <[EMAIL PROTECTED]> [2004-09-15 17:07:51 -0400]:
> >
> > On Wed, Sep 15, 2004 at 03:20:50PM -0400, Sam Steingold wrote:
> >>It appears that cygwin mmap() is lacking:
> >>
> >>configure:20536: checking for working mmap
> >>configure:20617: gcc -o conftest.exe -g -O2 conftest.c  >&5
> >>configure:20620: $? = 0
> >>configure:20622: ./conftest.exe
> >>configure:20625: $? = 1
> >>configure: program exited with status 1
> >>configure: failed program was:
> >
> > It would be enormously helpful if you apprised us of exactly *what*
> > was wrong rather than expecting us to figure it out.
>
> Let me assure you that you know these matters much better than I do.
>
> The C program in my original e-mail is supposed to terminate with exit
> code 0 if mmap() works correctly.  It does, e.g., on Linux and Solaris.
>
> On cygwin, it terminates with exit code 1, which indicates that mmap()
> does not work correctly as it is supposed to according to the spec.
>
> Unfortunately, I am far from being an expert on these matters...

Well, it looks like what configure basically complains about is that the
following mmap() calls fail (i.e., return (void*)-1) when they should have
succeeded (i.e., returned the first parameter):

mmap(0xa00,40960,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0xb00,49152,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0xc00,49152,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0xd00,57344,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0xe00,57344,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0xf00,65536,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1000,65536,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1100,73728,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1200,73728,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1300,81920,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1400,81920,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1500,90112,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1600,90112,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1700,98304,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1800,98304,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1900,106496,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1a00,106496,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1b00,114688,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1c00,114688,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1d00,122880,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1e00,122880,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x1f00,131072,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x2000,131072,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x2100,139264,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)
mmap(0x2200,139264,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0)

BTW, I'm not at all sure this is abnormal behavior...  Especially given
that the 9 preceding mmap() calls and ~30 later calls succeed:

mmap(0x100,8192,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x100
mmap(0x200,8192,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x200
mmap(0x300,16384,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x300
mmap(0x400,16384,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x400
mmap(0x500,24576,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x500
mmap(0x600,24576,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x600
mmap(0x700,32768,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x700
mmap(0x800,32768,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x800
mmap(0x900,40960,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x900
[failures]
mmap(0x2300,147456,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x2300
mmap(0x2400,147456,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x2400
mmap(0x2500,155648,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x2500
mmap(0x2600,155648,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x2600
mmap(0x2700,163840,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x2700
mmap(0x2800,163840,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x2800
mmap(0x2900,172032,PROT_READ|PROT_WRITE,MAP_ANON|MAP_PRIVATE|MAP_FIXED,-1,0) => 
0x2900
mmap(0x2a00,172032,PROT_READ|PROT_WRITE,MAP_ANON

Cygwin install error (retrieving option)

2004-09-15 Thread electa 
Today I tried to retrieve all my installed packets, using "download from
internet" and the "reinstall" option, which marks all my packages with
"retrieve".

I downloaded all of them good, but I get "An error occurred while
downloading" at the very end (in the window I see that setup is downloading
"_update_info_dir..."
My full dowloads are compromized? then the setup wants to retrieve all
packages again...I stopped it!




--
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: Bizarre behaviour of "make --win32"

2004-09-15 Thread Bob Byrnes 
On Sep 15,  1:18pm, Dave Korn" wrote:
-- Subject: RE: Bizarre behaviour of "make --win32"
> 
> The only thing that has been going wrong here is that when make invokes
> the command through execvp it runs in the same unix-y environment that make
> is running in itself, which defies the purpose of the --win32 switch; when
> the redirection of the command disables this optimisation, it correctly
> launches cmd.exe to execute subcommands.

If your goal is to *always* use cmd.exe, i.e., to completely disable
the optimization, then it should suffice to add ...

SHELL = cmd.exe

... to your Makefile (you would still use make --win32 in order to enable
various other win32-style Makefile syntax rules).

> --win32 is supposed to use cmd.exe rather than sh.exe to launch
> subprocesses, in order to understand windoze-style backslash-separated paths
> without having to double up all the backslashes to avoid them being taken as
> metachar escapes by the *nix shell.  So it's basically wrong behaviour: this
> optimisation effectively launches the subprocess within a unix environment
> rather than a cmd.exe environment, regardless of MAKE_MODE.
> 
-- End of excerpt from "Dave Korn"

I would tend to agree that the run-simple-commands-directly optimization
is not so useful, or arguably even a bug, for make --win32.  The
optimization is not supposed to affect how the programs run, and it
clearly does.

--
Bob

--
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: login name changed

2004-09-15 Thread Larry Hall 
At 06:50 PM 9/15/2004, you wrote:
>Larry Hall wrote, On 9/14/2004 10:10 PM:
>>At 07:23 PM 9/14/2004, you wrote:
>>
>>>Due to administrative reason my login name changed from "gene" to "gene.us."  This 
>>>also produced a new directory under "Documents and Setting" called "gene-us" which 
>>>is my new default home directory for windows. However, cygwin never seems to get 
>>>the message and when I start cygwin (via rxvt) it thinks my home is still in 
>>>"gene."  How do I tell cygwin to use "gene.us" as my home?
>>
>>
>>Same as always.  Run 'mkpasswd'.  See the docs:
>>
>>'man mkpasswd'
>>and/or see '/etc/postinstall/base-files-profile.sh.done'.
>>
>>--
>>Larry Hall  http://www.rfk.com
>>RFK Partners, Inc.  (508) 893-9779 - RFK Office
>>838 Washington Street   (508) 893-9889 - FAX
>>Holliston, MA 01746 
>
>Thanks for the pointers.
>
>For the record:
>
>mkpasswd -d MYDOMAIN > /etc/passwd
>
>produced thousands of entries. Weeded it down to just me since I am the only relevant 
>user. 


The '-u' flag would remove the need to weed if you like a tidy '/etc/passwd'.


>Also, in /etc/passwd had to change /home/gene.us to /cyygdrive/c/Documents and 
>Settings/gene.us for it to work right running rxvt.


You can use a symbolic link or a mount point to do this too.


>Rxvt also complained that I need to run mkgroup. So I did
>
>mkgroup -d MYDOMAIN > /etc/group
>
>This also produced thousands of entries but since I was not sure which of the groups 
>I am in, just left them all in /etc/group. Complaint about mkgroup went away and rxvt 
>starts with ok speed.

'-c' may have been what you wanted here, though more entries than needed 
is not a problem.


>I assume this is all ok.


Sounds fine to me.


--
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: login name changed

2004-09-15 Thread geneSmith 
Larry Hall wrote, On 9/14/2004 10:10 PM:
At 07:23 PM 9/14/2004, you wrote:
Due to administrative reason my login name changed from "gene" to "gene.us."  This also produced a new directory under "Documents and Setting" called "gene-us" which is my new default home directory for windows. However, cygwin never seems to get the message and when I start cygwin (via rxvt) it thinks my home is still in "gene."  How do I tell cygwin to use "gene.us" as my home?


Same as always.  Run 'mkpasswd'.  See the docs:

'man mkpasswd'
and/or see '/etc/postinstall/base-files-profile.sh.done'.
--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


Thanks for the pointers.
For the record:
mkpasswd -d MYDOMAIN > /etc/passwd
produced thousands of entries. Weeded it down to just me since I am the 
only relevant user. Also, in /etc/passwd had to change /home/gene.us to 
/cyygdrive/c/Documents and Settings/gene.us for it to work right running 
rxvt.

Rxvt also complained that I need to run mkgroup. So I did
mkgroup -d MYDOMAIN > /etc/group
This also produced thousands of entries but since I was not sure which 
of the groups I am in, just left them all in /etc/group. Complaint about 
mkgroup went away and rxvt starts with ok speed.

I assume this is all ok.
-gene
--
Lit up like Levy's
--
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: checking for working mmap...no

2004-09-15 Thread Sam Steingold 
> * Christopher Faylor <[EMAIL PROTECTED]> [2004-09-15 17:07:51 -0400]:
>
> On Wed, Sep 15, 2004 at 03:20:50PM -0400, Sam Steingold wrote:
>>It appears that cygwin mmap() is lacking:
>>
>>configure:20536: checking for working mmap
>>configure:20617: gcc -o conftest.exe -g -O2 conftest.c  >&5
>>configure:20620: $? = 0
>>configure:20622: ./conftest.exe
>>configure:20625: $? = 1
>>configure: program exited with status 1
>>configure: failed program was:
>
> It would be enormously helpful if you apprised us of exactly *what*
> was wrong rather than expecting us to figure it out.

Let me assure you that you know these matters much better than I do.

The C program in my original e-mail is supposed to terminate with exit
code 0 if mmap() works correctly.  It does, e.g., on Linux and Solaris.

On cygwin, it terminates with exit code 1, which indicates that mmap()
does not work correctly as it is supposed to according to the spec.

Unfortunately, I am far from being an expert on these matters...

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
  
 
Bus error -- please leave by the rear door.

--
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: checking for working mmap...no

2004-09-15 Thread Christopher Faylor 
On Wed, Sep 15, 2004 at 03:20:50PM -0400, Sam Steingold wrote:
>It appears that cygwin mmap() is lacking:
>
>configure:20536: checking for working mmap
>configure:20617: gcc -o conftest.exe -g -O2 conftest.c  >&5
>configure:20620: $? = 0
>configure:20622: ./conftest.exe
>configure:20625: $? = 1
>configure: program exited with status 1
>configure: failed program was:

It would be enormously helpful if you apprised us of exactly *what*
was wrong rather than expecting us to figure it out.

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: [ANNOUNCEMENT] Updated: naim-0.11.7.2-1

2004-09-15 Thread Dr. Volker Zell 
> Daniel Reed writes:

> naim 0.11.7.2 is now available through the Cygwin package system.

The package is missing the libnaim_core.a library also libnaim_core.la
advertises it. The previous version had this file installed.

Ciao
  Volker



--
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/

checking for working mmap...no

2004-09-15 Thread Sam Steingold 
It appears that cygwin mmap() is lacking:

configure:20536: checking for working mmap
configure:20617: gcc -o conftest.exe -g -O2 conftest.c  >&5
configure:20620: $? = 0
configure:20622: ./conftest.exe
configure:20625: $? = 1
configure: program exited with status 1
configure: failed program was:

| /* confdefs.h.  */
| 
| #include 
| #ifdef HAVE_UNISTD_H
| #include 
| #endif
| #include 
| #ifdef OPEN_NEEDS_SYS_FILE_H
| #include 
| #endif
| #include 
| #include 
| int main () {
| 
|   int flags = MAP_ANON | MAP_PRIVATE;
|   int fd = -1;
| #define bits_to_avoid 0
| #define my_shift 24
| #define my_low   1
| #ifdef FOR_SUN4_29
| #define my_high  31
| #define my_size  32768 /* hope that 32768 is a multiple of the page size */
| /* i*32 KB for i=1..31 gives a total of 15.5 MB, which is close to what we need */
| #else
| #define my_high  64
| #define my_size  8192 /* hope that 8192 is a multiple of the page size */
| /* i*8 KB for i=1..64 gives a total of 16.25 MB, which is close to what we need */
| #endif
|  {long i;
| #define i_ok(i)  ((i) & (bits_to_avoid >> my_shift) == 0)
|   for (i=my_low; i<=my_high; i++)
| if (i_ok(i))
|   { caddr_t addr = (caddr_t)(i << my_shift);
| /* Check for 8 MB, not 16 MB. This is more likely to work on Solaris 2. */
| #if bits_to_avoid
| long size = i*my_size;
| #else
| long size = ((i+1)/2)*my_size;
| #endif
| if (mmap(addr,size,PROT_READ|PROT_WRITE,flags|MAP_FIXED,fd,0) == (void*)-1) 
exit(1);
| }
| #define x(i)  *(unsigned char *) ((i<=my_low; i--) if (i_ok(i)) { if (x(i) != y(i)) exit(1); }
|   exit(0);
| }}

Thanks!

the above is from the CLISP configure, see
http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/src/m4/mmap.m4

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
  
 
Those who value Life above Freedom are destined to lose both.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

2004-09-15 Thread Christopher Faylor 
On Wed, Sep 15, 2004 at 01:38:35PM -0400, Christopher Faylor wrote:
>On Wed, Sep 15, 2004 at 01:24:06PM -0400, Pierre A. Humblet wrote:
>>At any rate, trying to get status without waiting should be considered
>>a bug, and not a feature that Cygwin should work around.  Will someone
>>take responsibility to notify the bash maintainer?
>
>Ronald, I think this one is yours as the bash maintainer.  Could you
>notify the bash maintainer?
   ^
upstream

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

2004-09-15 Thread Christopher Faylor 
On Wed, Sep 15, 2004 at 01:24:06PM -0400, Pierre A. Humblet wrote:
>At any rate, trying to get status without waiting should be considered
>a bug, and not a feature that Cygwin should work around.  Will someone
>take responsibility to notify the bash maintainer?

Ronald, I think this one is yours as the bash maintainer.  Could you
notify the bash maintainer?

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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

2004-09-15 Thread Pierre A. Humblet 
On Wed, Sep 15, 2004 at 01:01:50PM -0400, Christopher Faylor wrote:
> On Wed, Sep 15, 2004 at 12:35:14PM -0400, Pierre A. Humblet wrote:
> >Christopher Faylor wrote:
> >> On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote:
> >> >Ok.  Running 09/14/04 snapshot is looking *good* so far.  I stopped the
> >> >test script at 150 passes.
> >> >
> >> >I'm starting my configure/build/redo test and will let that run
> >> >overnight.  I'll check in tomorrow AM and report on that.  1 successful
> >> >configure/build so far.
> >> 
> >> That points to a problem with bash, then, not cygwin.
> >> 
> >> If we can confirm this then we should probably notify the bash
> >> maintainer.
> >
> >He might be interested by the attachment below, obtained from
> >the bashstrace in http://cygwin.com/ml/cygwin/2004-09/msg00626.html
> >
> >fgrep ' 1696 ' bashstrace | grep '= fork\|wait4: call' > bashstrace_grep.txt
> >
> >Every fork is followed by a wait, except the one that leads to trouble.
> >Somehow bash draws conclusions about its status without doing a wait.
> >Pid reuse shouldn't be the root cause of this behavior.
> 
> But, the fork previous to the last fork had been seen 5 times previously and
> the gap between the last occurrence of pid 456 was 7 which is greater than
> the 4 pids that cygwin holds in check to prevent duplication.
> 
> Here's a useless table showing the occurrence of pids:
> 
>  PID PREV SEEN PID PREV SEEN PID PREV SEEN PID PREV SEEN
> 2308  -10 1432   61 2444  -10 2444   62
> 2036  -10 2308   62 1432   63  500  -10
> 1488  -10 2036   62 1488  103  456   64
>  456  -10 1488   62 2308   64 1488   55
> 2104  -10  456   62  928   51 2104  213
> 1432  -10 2104   62 2444   51 1432   85
> 2308   61 1432   62 2292  -10  316  -10
> 2036   61  652  -10  456  143 2296  -10
> 1488   61 2308   73 1432   74  888  -10
>  456   61 1744  -10 1488   74  456   75
> 2104   61  928  -10 2308   75 2016  -10
> 
> PID is the pid produced by fork.
> 
> PREV is how many forks ago we'd previously seen this same pid (-1 means
> never).
> 
> SEEN is how many times we've seen this pid.
> 
> There doesn't seem to be anything especially unique about pid 456 (the
> problematic one), at least from this table.  But, it sure is fun analyzing
> the data like bash was a black box...  It does seem like the correct number
> of pids to hold is probably 8, though so, maybe the temporary change to
> cygwin is a keeper.
> 
> >Also according the the following comment in bash code, the Cygwin style of
> >pid reuse should be no problem:
> >#if defined (RECYCLES_PIDS)
> >   /* LynxOS, for one, recycles pids very quickly -- so quickly
> >  that a new process may have the same pid as the last one
> >  created.  This has been reported to fix the problem. */
> 
> IIRC, bash keeps some kind of cache of pids which it has recently seen and
> incorrectly decides not to wait for pids in some cases.  The RECYCLES_PIDS
> define turned out not to be foolproof.  I had, at one point, turned off
> the code in cygwin which works around this problem when it looked like
> bash had a fix but the problem still manifested.

I have been poking at the bash code. It keeps all the pids in
the pipelines for each job, so the number can be very large.

At any rate, trying to get status without waiting should be considered
a bug, and not a feature that Cygwin should work around.
Will someone take responsibility to notify the bash maintainer?

Pierre

--
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: Program terminates with "cygheap version mismatch detected"

2004-09-15 Thread Christopher Faylor 
On Wed, Sep 15, 2004 at 12:57:10PM -0400, Igor Pechtchanski wrote:
>Or, you could simply do "cygcheck program.exe", where "program.exe" is the
>one you're trying to run.  It'll show all the DLLs that the program
>depends on statically.

Right.  I suspect that one of the DLLs needs to be rebased along with
the others that were previously rebased.

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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

2004-09-15 Thread Christopher Faylor 
On Wed, Sep 15, 2004 at 12:35:14PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>> On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote:
>> >Ok.  Running 09/14/04 snapshot is looking *good* so far.  I stopped the
>> >test script at 150 passes.
>> >
>> >I'm starting my configure/build/redo test and will let that run
>> >overnight.  I'll check in tomorrow AM and report on that.  1 successful
>> >configure/build so far.
>> 
>> That points to a problem with bash, then, not cygwin.
>> 
>> If we can confirm this then we should probably notify the bash
>> maintainer.
>
>He might be interested by the attachment below, obtained from
>the bashstrace in http://cygwin.com/ml/cygwin/2004-09/msg00626.html
>
>fgrep ' 1696 ' bashstrace | grep '= fork\|wait4: call' > bashstrace_grep.txt
>
>Every fork is followed by a wait, except the one that leads to trouble.
>Somehow bash draws conclusions about its status without doing a wait.
>Pid reuse shouldn't be the root cause of this behavior.

But, the fork previous to the last fork had been seen 5 times previously and
the gap between the last occurrence of pid 456 was 7 which is greater than
the 4 pids that cygwin holds in check to prevent duplication.

Here's a useless table showing the occurrence of pids:

 PID PREV SEEN PID PREV SEEN PID PREV SEEN PID PREV SEEN
2308  -10 1432   61 2444  -10 2444   62
2036  -10 2308   62 1432   63  500  -10
1488  -10 2036   62 1488  103  456   64
 456  -10 1488   62 2308   64 1488   55
2104  -10  456   62  928   51 2104  213
1432  -10 2104   62 2444   51 1432   85
2308   61 1432   62 2292  -10  316  -10
2036   61  652  -10  456  143 2296  -10
1488   61 2308   73 1432   74  888  -10
 456   61 1744  -10 1488   74  456   75
2104   61  928  -10 2308   75 2016  -10

PID is the pid produced by fork.

PREV is how many forks ago we'd previously seen this same pid (-1 means
never).

SEEN is how many times we've seen this pid.

There doesn't seem to be anything especially unique about pid 456 (the
problematic one), at least from this table.  But, it sure is fun analyzing
the data like bash was a black box...  It does seem like the correct number
of pids to hold is probably 8, though so, maybe the temporary change to
cygwin is a keeper.

>Also according the the following comment in bash code, the Cygwin style of
>pid reuse should be no problem:
>#if defined (RECYCLES_PIDS)
> /* LynxOS, for one, recycles pids very quickly -- so quickly
>that a new process may have the same pid as the last one
>created.  This has been reported to fix the problem. */

IIRC, bash keeps some kind of cache of pids which it has recently seen and
incorrectly decides not to wait for pids in some cases.  The RECYCLES_PIDS
define turned out not to be foolproof.  I had, at one point, turned off
the code in cygwin which works around this problem when it looked like
bash had a fix but the problem still manifested.

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: Program terminates with "cygheap version mismatch detected"

2004-09-15 Thread Igor Pechtchanski 
On Wed, 15 Sep 2004, Peter Rehley wrote:

> On Sep 15, 2004, at 5:54 AM, Joshua Wright wrote:
>
> > Jörg Schaible wrote:
> > > > c:\DEV\testing\asleap.exe (988): *** cygheap version mismatch detected -
> > > > 0x6178/0xBF. You have multiple copies of cygwin1.dll on your
> > > > system.
> >
> > > From your cygcheck output I've seen that you have or had a B15
> > > running ... do you still use it? Even it the dll name is cygwin.dll
> > > (just a guess, B15 was not my time ), it might already allocate
> > > the same shared memory than cygwin1.dll.
> >
> > I tried to remove all instances of Cygwin from my system in an effort to
> > troubleshoot:
> >  + Did a find with regedit and removed any keys with "cyg" in them
> >  + Removed the c:\cygwin tree
> >  + Did a Windows Find on "cyg" and removed all files
> >
> > Reinstalled cygwin, rebooted.  Same error. :(
> >
> > Any other thoughts?  Possibly a problem with Windows XP SP2?  I'm not sure
> > what to try next
>
> Maybe off the wall, but keep the program that you are trying to run.  Remove
> the cygwin tree (c:\cygwin) and then try running the exe again.  See what
> happens.  If the program runs, then there is a cygwin1.dll outside of the
> tree.  Check the path that the program uses to see where the dll might be
> lurking.

Or, you could simply do "cygcheck program.exe", where "program.exe" is the
one you're trying to run.  It'll show all the DLLs that the program
depends on statically.
Igor

> Could the dll have a different name then cygwin1?  Where I work we've created
> a special dll with a different name to prevent cross over problems from the
> regular cygwin dll.  When running a regular cygwin program in this custom
> space (i.e. start from bash in custom environment) the error message you've
> seen appears.
>
> Again off the wall things to try and check.
> Peter

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw
--
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: Program terminates with "cygheap version mismatch detected"

2004-09-15 Thread Peter Rehley 
On Sep 15, 2004, at 5:54 AM, Joshua Wright wrote:
Jörg Schaible wrote:
c:\DEV\testing\asleap.exe (988): *** cygheap version mismatch 
detected - 0x6178/0xBF. You have multiple copies of 
cygwin1.dll on your system.

From your cygcheck output I've seen that you have or had a B15
running ... do you still use it? Even it the dll name is cygwin.dll
(just a guess, B15 was not my time ), it might already allocate
the same shared memory than cygwin1.dll.
I tried to remove all instances of Cygwin from my system in an effort 
to troubleshoot:
 + Did a find with regedit and removed any keys with "cyg" in them
 + Removed the c:\cygwin tree
 + Did a Windows Find on "cyg" and removed all files

Reinstalled cygwin, rebooted.  Same error. :(
Any other thoughts?  Possibly a problem with Windows XP SP2?  I'm not 
sure what to try next
Maybe off the wall, but keep the program that you are trying to run.  
Remove the cygwin tree (c:\cygwin) and then try running the exe again.  
See what happens.  If the program runs, then there is a cygwin1.dll 
outside of the tree.  Check the path that the program uses to see where 
the dll might be lurking.

Could the dll have a different name then cygwin1?  Where I work we've 
created a special dll with a different name to prevent cross over 
problems from the regular cygwin dll.  When running a regular cygwin 
program in this custom space (i.e. start from bash in custom 
environment) the error message you've seen appears.

Again off the wall things to try and check.
Peter
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

2004-09-15 Thread Pierre A. Humblet 

Christopher Faylor wrote:
> 
> On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote:
> >Ok.  Running 09/14/04 snapshot is looking *good* so far.  I stopped the
> >test script at 150 passes.
> >
> >I'm starting my configure/build/redo test and will let that run
> >overnight.  I'll check in tomorrow AM and report on that.  1 successful
> >configure/build so far.
> 
> That points to a problem with bash, then, not cygwin.
> 
> If we can confirm this then we should probably notify the bash
> maintainer.

He might be interested by the attachment below, obtained from
the bashstrace in http://cygwin.com/ml/cygwin/2004-09/msg00626.html

fgrep ' 1696 ' bashstrace | grep '= fork\|wait4: call' > bashstrace_grep.txt

Every fork is followed by a wait, except the one that leads to trouble.
Somehow bash draws conclusions about its status without doing a wait.
Pid reuse shouldn't be the root cause of this behavior.

Also according the the following comment in bash code, the Cygwin style of
pid reuse should be no problem:
#if defined (RECYCLES_PIDS)
  /* LynxOS, for one, recycles pids very quickly -- so quickly
 that a new process may have the same pid as the last one
 created.  This has been reported to fix the problem. */


Pierre  117  872308 [main] bash 1696 fork: 2308 = fork()
  125  873876 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  137  927912 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  152 1115952 [main] bash 1696 fork: 2036 = fork()
  210 1117609 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  137 1223831 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  117 1662780 [main] bash 1696 fork: 1488 = fork()
  144 1664261 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  131 1867156 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  116 1914817 [main] bash 1696 fork: 456 = fork()
  139 1916356 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  146 2114502 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  120 2161965 [main] bash 1696 fork: 2104 = fork()
  143 2163481 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  145 2368793 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  118 2416409 [main] bash 1696 fork: 1432 = fork()
  165 2417863 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  145 2616099 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  119 2664589 [main] bash 1696 fork: 2308 = fork()
  159 2665939 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  148 2865875 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  129 2914912 [main] bash 1696 fork: 2036 = fork()
  676 2916792 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  146 3114780 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  204 3162946 [main] bash 1696 fork: 1488 = fork()
  126 3164271 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  203 3461625 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  155 3509295 [main] bash 1696 fork: 456 = fork()
  126 3510735 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  206 3712483 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  143 3765025 [main] bash 1696 fork: 2104 = fork()
  127 3766418 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  145 3965535 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  117 4125336 [main] bash 1696 fork: 1432 = fork()
  126 4126809 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  125 4358150 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  121 4405766 [main] bash 1696 fork: 2308 = fork()
  137 4407184 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  147 4611082 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  116 4659500 [main] bash 1696 fork: 2036 = fork()
  169 4661074 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  148 4866256 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  115 4913817 [main] bash 1696 fork: 1488 = fork()
  157 4915180 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  145 5116382 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  116 5165835 [main] bash 1696 fork: 456 = fork()
  163 5167204 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  145 5375291 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  130 5423472 [main] bash 1696 fork: 2104 = fork()
  655 5425369 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  342 5625852 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1
  115 5859774 [main] bash 1696 fork: 1432 = fork()
  127 5862344 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0
  145 5940525 [main] bash 1696 wait4: calling proc_subproc, pid

Re: Installation hangs because asks for input from terminal

2004-09-15 Thread Reini Urban 
Hi Alex,
Alexander Colesnicov schrieb:
I tried to install cygwin and it hanged when executing
/etc/postinstall/post-texmf.sh . To proceed further, I marked this
script as "done" and all the rest was OK. Then I started cygwin and run
this script manually. I found that it was a conflict with my existing
fpTeX installation (fpTeX is a TeTeX port to Windows) that defined an
environment variable TEXMFCNF to one of Windows directories. The script
post-texmf.sh diagnosted that and asked for user's reaction. I redefined
the variable in my .bashrc as TEXMFCNF="/usr/share/texmf/web2c:", and
the script run. The bad thing is that the terminal window does not exist
during setup.exe run. Therefore, the user can not react to script's
questions. My recommedation is to reprogram post-texmf.sh in such a
manner that it will never ask for user's intervention, and will set the
TEXMFCNF variable uncoditionally to its true value to avoid the
described conflict.
Could you please attach the output of
$ cygcheck -s -v -r > cygcheck.out
as described in http://cygwin.com/problems.html
Our setup.exe maintainers couldn't reproduce this problem on their 
systems. Any read in the postinstall script is just skipped.
Do you have Win95?
--
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: rlogin or rsh correct install

2004-09-15 Thread Larry Hall 
At 09:58 AM 9/15/2004, you wrote:
>At 05:52 AM 9/15/2004, you wrote:
>>I need to use the rlogin and I don't know witch package to use.
>
>You answer this question by consulting .  Type
>in the name of the file you're looking for.  It will tell you the package(s)
>and version(s) that contain this file.  For executables, it's often helpful
>to proceed the executable name with 'bin/' (i.e. 'bin/rlogin').  With the 

^^^
   *precede*
   
UGH!

>results of that, run 'setup' and install that package.  Simple. :-)




--
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: CTRL-C kills "ssh -X"

2004-09-15 Thread Rob S.i.k.l.o.s 
Just to close off this thread, in case anyone cares, adding "tty" the CYGWIN 
environment variable seems to solve this problem.

Rob.
- Original Message - 
From: "Rob S.i.k.l.o.s" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 09, 2004 12:39 PM
Subject: CTRL-C kills "ssh -X"


Hi All,
When I connect to any machine using "ssh -X", so that X display is
automatically tunelled over the ssh connection, hitting CTRL-C at any time
kills the ssh process, which outputs "Killed by signal 2."
This does not happen if I omit the "-X" when running ssh.
Cygcheck output attached.
Thanks,
Rob.



--
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: rlogin or rsh correct install

2004-09-15 Thread Larry Hall 
At 05:52 AM 9/15/2004, you wrote:
>I need to use the rlogin and I don't know witch package to use.

You answer this question by consulting .  Type
in the name of the file you're looking for.  It will tell you the package(s)
and version(s) that contain this file.  For executables, it's often helpful
to proceed the executable name with 'bin/' (i.e. 'bin/rlogin').  With the 
results of that, run 'setup' and install that package.  Simple. :-)


>The command rsh is giving me this error
>
>rsh.exe: remote terminal session not supported
>
>Runs commands on remote hosts running the RSH service. 
>
>RSH host [-l username] [-n] command
>
>  hostSpecifies the remote host on which to run command.
>  -l username Specifies the user name to use on the remote host. If 
>  omitted, the logged on user name is used.
>  -n  Redirects the input of RSH to NULL.
>  command Specifies the command to run.
>
>What am I doing wrong?



You're using the Windows version of 'rsh'. ;-)  

You may want to consider installing and using 'openssh' instead, if security
is an issue.  It's a secure replacement for r* commands.




--
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: Program terminates with "cygheap version mismatch detected"

2004-09-15 Thread Joshua Wright 
Jörg Schaible wrote:
c:\DEV\testing\asleap.exe (988): *** cygheap version mismatch 
detected - 0x6178/0xBF. You have multiple copies of 
cygwin1.dll on your system.

From your cygcheck output I've seen that you have or had a B15
running ... do you still use it? Even it the dll name is cygwin.dll
(just a guess, B15 was not my time ), it might already allocate
the same shared memory than cygwin1.dll.
I tried to remove all instances of Cygwin from my system in an effort to 
troubleshoot:
 + Did a find with regedit and removed any keys with "cyg" in them
 + Removed the c:\cygwin tree
 + Did a Windows Find on "cyg" and removed all files

Reinstalled cygwin, rebooted.  Same error. :(
Any other thoughts?  Possibly a problem with Windows XP SP2?  I'm not 
sure what to try next.

Thanks,
-Josh
--
-Joshua Wright
[EMAIL PROTECTED]
http://home.jwu.edu/jwright/
pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73
Today I stumbled across the world's largest hotspot.  The SSID is "linksys".
--
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: Bizarre behaviour of "make --win32"

2004-09-15 Thread Dave Korn 
> -Original Message-
> From: cygwin-owner On Behalf Of Bob Byrnes
> Sent: 15 September 2004 01:25

> On Sep 14,  4:01pm, Dave Korn wrote:
> -- Subject: Bizarre behaviour of "make --win32"
> >
> > It appears to be using sh.exe, regardless of the --win32 
> flag.  But if I
> > add stdout redirection to the command in question, it uses cmd.exe.
> > 
> -- End of excerpt from "Dave Korn"
> 
> On non-Cygwin, UNIX platforms, GNU make will optimize away the shell
> invocation for simple commands, which are identified by lack of known
> shell metacharacters (like ">").  For example, "foo bar baz" would be
> executed directly, using something like execvp(), but "foo bar > baz"
> would run /bin/sh -c "foo bar > baz".

  Bingo.  That sounds like the one.  This is causing me complicated
interactions with the fact that windows shell doesn't follow cygwin
softlinks, but something launched from within a cygwin process does.  Which
is ultimately why my makefiles sometimes succeed in launching python.exe (a
softlink) and sometimes fail, according to whether redirection is in use or
not.

> If the Makefile sets the SHELL make variable to something other than
> the default /bin/sh, then this opimization is disabled: GNU make
> conservatively assumes that it has no idea about the syntax for the
> nonstandard shell, ignores potential metacharacters, and just always
> runs $(SHELL) -c "command".  This can have performance implications,
> as you might imagine.
>
> I don't know offhand what happens with --win32, 

  --win32 is supposed to use cmd.exe rather than sh.exe to launch
subprocesses, in order to understand windoze-style backslash-separated paths
without having to double up all the backslashes to avoid them being taken as
metachar escapes by the *nix shell.  So it's basically wrong behaviour: this
optimisation effectively launches the subprocess within a unix environment
rather than a cmd.exe environment, regardless of MAKE_MODE.

>but the difference in
> behavior with stdout redirection that you report is probably related
> to this optimization.  I thought --win32 was supposed to use cmd.exe,
> but I don't know what the equivalent of execvp() would be for simple
> commands, or if make --win32 knows about cmd.exe metacharacters.
> What makes you think that sh.exe is being used?

  NTFileMon from sysinternals, but on closer inspection, it turns out to be
a red herring: sh.exe is in fact not being invoked from make directly, but
by a call to os.system () in a python script; some activity from it just
at the point where make was launching a subcommand got in the way and fooled
me.

  The only thing that has been going wrong here is that when make invokes
the command through execvp it runs in the same unix-y environment that make
is running in itself, which defies the purpose of the --win32 switch; when
the redirection of the command disables this optimisation, it correctly
launches cmd.exe to execute subcommands.

  Now that I've got the inconsistent behaviour explained, I need to figure
out how to make it possible to invoke python from a makefile that might be
run from either bash.exe or cmd.exe and use either cygwin python or win32
python according to which is installed, and without any dependency on which
order in $PATH they come..

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: Program terminates with "cygheap version mismatch detected"

2004-09-15 Thread Joshua Wright 
Christopher Faylor wrote:
c:\DEV\testing\asleap.exe (988): *** cygheap version mismatch detected 
- 0x6178/0xBF.
You have multiple copies of cygwin1.dll on your system.
Find the extra cygwin1.dlls and delete them.
Use only the one in cygwin\bin

You probably need to run rebaseall (q.v.).
Well, I ran rebaseall, rebooted my system and still have the same 
results with this program.  Any other suggestions?

Many thanks,
-Josh
--
-Joshua Wright
[EMAIL PROTECTED]
http://home.jwu.edu/jwright/
pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73
Today I stumbled across the world's largest hotspot.  The SSID is "linksys".
--
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/

rlogin or rsh correct install

2004-09-15 Thread Marcos Rebelo 
I need to use the rlogin and I don't know witch package to use.

The command rsh is giving me this error

rsh.exe: remote terminal session not supported

Runs commands on remote hosts running the RSH service. 

RSH host [-l username] [-n] command

  hostSpecifies the remote host on which to run command.
  -l username Specifies the user name to use on the remote host. If 
  omitted, the logged on user name is used.
  -n  Redirects the input of RSH to NULL.
  command Specifies the command to run.

What am I doing wrong?

Thanks
Marcos Rebelo


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.11 - tcp problems

2004-09-15 Thread Corinna Vinschen 
On Sep 15 10:01, Marcus Davage wrote:
> Firstly, sorry, but I am afriad I cannot CYMTNQREAIYR - it's out of my
> control.

I don't think so.  The last resort is called "hand editing".  That should
always work sufficiently.

> Next, my dir /etc/services returns
> services -> C:\WINNT\system32\drivers\etc\services*
> so it IS a symlink to Windows.

I'm wondering if C:\WINNT\system32\drivers\etc\services is readable
for everyone.  Could you go into the above directory and call

  chmod a+r services

and try again?  Other than that, please follow the guidelines on
http://cygwin.com/problems.html

Attaching the cygcheck output could perhaps give us a clue what's
going wrong on your system.


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: 1.5.11 - tcp problems

2004-09-15 Thread Marcus Davage 
Firstly, sorry, but I am afriad I cannot CYMTNQREAIYR - it's out of my
control.
Next, my dir /etc/services returns
services -> C:\WINNT\system32\drivers\etc\services*
so it IS a symlink to Windows.

Marcus


--Original Mail--
Marcus,

First off, .  Thanks.

Secondly, the /etc/services file seems ok, but in Cygwin it's actually
a
symlink to the one in the Windows system directory.  Do you have the
symlink on your system, or is /etc/services a file?  If it's a file,
Windows (in particular, winsock) won't be aware of it.
Igor


--
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: Cygwin licensing issue

2004-09-15 Thread Corinna Vinschen 
On Sep 15 10:42, [EMAIL PROTECTED] wrote:
> 
> There is someone that can make me understand what is intendend for "proprietary
> use" at
> 
> http://cygwin.com/faq/faq_7.html#SEC132
> 
> other authoritary information in Cygwin FAQ section about cygwin software
> licensing
> 
> http://cygwin.com/faq/faq_1.html#SEC4
> 
> I would to know if I can use Cygwin on my company for using the product,
> not for selling software developed with Cygwin libraries...
> 
> I would to know if I can make a C++ application, makeing an executable .exe
> and then use in my company to simplify my work; remark: I not sell this
> application, and I write source code with GPL licensing.

In that case your definitely off the hook :-)


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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

2004-09-15 Thread Bogdan Vacaliuc 
Chris,

My local tests and all reports from rtems-users so far are successes.

-bogdan


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ekberg
> Sent: Wednesday, September 15, 2004 3:24 AM
> To: [EMAIL PROTECTED]
> Subject: RE: 1.5.10: expr + configure failure + testcase 
> (also on 1.5.11-1)
> 
> 
> Christopher Faylor wrote:
> > Grr...  This was the newlib problem previously mentioned.  
> I forgot to 
> > generate the snapshot in such a way as to work around this problem.
> > 
> > The new snapshot should work better.
> 
> Indeed it does. I have tried a couple of times without any 
> hickups. With 1.5.11 a have not been able to get my testcase 
> to even pass once if straceing. With this snapshot I now have 
> 5 consecutive successes (and no failures).
> 
> I'm afraid I don't understand the issue and why the temporary 
> change in the snapshot points at bash, so someone else is 
> probably better suited to notify the bash maintainer. (If the 
> evidence in this message qualifies as confirmation.)
> 
> BTW, thanks for helping out with debugging!
> 
> Cheers,
> Peter
> 
> --
> 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/

Cygwin licensing issue

2004-09-15 Thread lorenzo . delana 

There is someone that can make me understand what is intendend for "proprietary
use" at

http://cygwin.com/faq/faq_7.html#SEC132

other authoritary information in Cygwin FAQ section about cygwin software
licensing

http://cygwin.com/faq/faq_1.html#SEC4

I would to know if I can use Cygwin on my company for using the product,
not for selling software developed with Cygwin libraries...

I would to know if I can make a C++ application, makeing an executable .exe
and then use in my company to simplify my work; remark: I not sell this
application, and I write source code with GPL licensing.


Any suggestion appreciated,
Lorenzo



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

2004-09-15 Thread Peter Ekberg 
Christopher Faylor wrote:
> Grr...  This was the newlib problem previously mentioned.  I forgot to
> generate the snapshot in such a way as to work around this problem.
> 
> The new snapshot should work better.

Indeed it does. I have tried a couple of times without any hickups.
With 1.5.11 a have not been able to get my testcase to even pass
once if straceing. With this snapshot I now have 5 consecutive
successes (and no failures).

I'm afraid I don't understand the issue and why the temporary change
in the snapshot points at bash, so someone else is probably better
suited to notify the bash maintainer. (If the evidence in this message
qualifies as confirmation.)

BTW, thanks for helping out with debugging!

Cheers,
Peter

--
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: Also unison/ssh [Re: Win XP SP2: cvs over ssh problems]

2004-09-15 Thread Robert Schmidt 
Robert Schmidt wrote:
OK, here's some more info from the hanging unison over ssh on 1.5.11.
> ...
Sorry, forgot the cygcheck -s -v -r output.
Cheers,
Rob

Cygwin Configuration Diagnostics
Current System Time: Wed Sep 15 09:01:32 2004

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\ATI Technologies\ATI Control Panel
C:\cygwin\bin
C:\Private\bin
C:\Program Files\Schlumberger\Smart Cards and Terminals\Cyberflex Access 
Kits\v4\

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1003(robert) GID: 513(None)
513(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1003(robert) GID: 513(None)
0(root)  513(None)
544(Administrators)  545(Users)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

CYGWIN = `ntsec'
HOME = `C:\Private'
Path = `C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\ATI 
Technologies\ATI Control Panel;C:\cygwin\bin;C:\Private\bin;C:\Program 
Files\Schlumberger\Smart Cards and Terminals\Cyberflex Access Kits\v4\'

.arj = `va'
.bmp = `start'
.diz = `l'
.gif = `start'
.jpg = `start'
.mp3 = `start'
.nfo = `l'
.pl = `perl -w'
.rar = `vr'
.txt = `l'
.zip = `vz'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\robert\Application Data'
CLIENTNAME = `Console'
CMDLINE = `cygcheck -s -v -r'
CommonProgramFiles = `C:\Program Files\Common Files'
COMPUTERNAME = `WHITEBOX'
ComSpec = `C:\Private\4nt\4nt.exe'
FP_NO_HOST_CHECK = `NO'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\robert'
INCLUDE = `C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\'
LIB = `C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\'
LOGONSERVER = `\\WHITEBOX'
NUMBER_OF_PROCESSORS = `1'
ON_SERVER = `0'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 9 Stepping 5, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0905'
ProgramFiles = `C:\Program Files'
PROMPT = [EMAIL PROTECTED]'
SESSIONNAME = `Console'
SystemDrive = `C:'
SystemRoot = `C:\WINDOWS'
TEMP = `C:\DOCUME~1\robert\LOCALS~1\Temp'
title = `C:\TEMP'
TMP = `C:\DOCUME~1\robert\LOCALS~1\Temp'
USERDOMAIN = `WHITEBOX'
USERNAME = `robert'
USERPROFILE = `C:\Documents and Settings\robert'
VS71COMNTOOLS = `C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\'
windir = `C:\WINDOWS'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   76316Mb  46% CP CS UN PA FC 
d:  cd   N/AN/A
e:  fd   N/AN/A
f:  cd   N/AN/A
p:  hd  NTFS   76316Mb  46% CP CS UN PA FC 
r:  net NTFS   58635Mb  68% CP CS UN PA FC Dasken
s:  net NTFS   761635Mb  46% CP CS UN PA FC RAID

C:\cygwin  /  system  binmode
C:\cygwin/bin  /usr/bin   system  binmode
C:\cygwin/lib  /usr/lib   system  binmode
.  /cygdrive  system  binmode,cygdrive

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Not Found: cpp (good!)
Found: C:\cygwin\bin\find.exe
Not Found: gcc
Not Found: gdb
Found: C:\cygwin\bin\grep.exe
Not Found: ld
Found: C:\cygwin\bin\ls.exe
Not Found: make
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe

   55k 2004/09/14 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
  "cygbz2-1.dll" v0.0 ts=2004/9/14 6:16
  841k 2004/03/17 C:\cygwin\bin\cygcrypto-0.9.7.dll - os=4.0 img=1.0 sys=4.0
  "cygcrypto-0.9.7.dll" v0.0 ts=2004/3/17 23:58
   45k 2001/04/25 C:\cygwin\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
  "cygform5.dll" v0.0 ts=2001/4/25 7:28
   35k 2002/01/09 C:\cygwin\bin\cygform6.dll - os=4.0 img=1.0 sys=4.0
  "cygform6.dll" v0.0 ts=2002/1/9 7:03
   48k 2003/08/09 C:\cygwin\bin\cygform7.dll - os=4.0 img=1.0 sys=4.0
  "cygform7.dll" v0.0 ts=2003