Re: grep and words

[Jim Easton]

Hi,

Guy Przytula wrote:
> > another question from newbie ..
> > is it possible with grep to select only the rows where the second word
> > applies, because the pattern can occur at different places like :
> > row 1 :   zzz
> > row 2 :   zzz
> > I need only the row where word 2 = 
> > grep  would also return row 2
> > Thanks for all info
> > Best Regards, Guy Przytula

As others have pointed out this is hardly a cygwin question and
there are lots of ways of doing it.  However here is one that fits
your sample data (note: it uses egrep and that I've added a couple
of test lines):

HTH
Jim

#!/bin/sh

egrep '.*  * ' <<'END'
  zzz
  zzz
    zzz
   f zzz
END

--
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.21s mmap error

[Corinna Vinschen]

On Jul 12 15:57, Brian Ford wrote:
> On Wed, 12 Jul 2006, Corinna Vinschen wrote:
> 
> > The problem results from introducing MAP_NORESERVE in 1.5.19.  That's
> > the reason the same code works on 1.5.18.  Your code simply defines
> > MAP_NORESERVE to 0 under 1.5.18.
> 
> While that is true, I compiled the STC with MAP_NORESERVE defined under
> the 1.5.21s headers, and then ran the binary without recompiling it under
> 1.5.[18-20].  So, you must have ignored the MAP_NORESERVE value in the
> older releases since it was passed to mmap in my test.

Right, only the correctness of the POSIX flags is checked at the start
of mmap.  Any non-standard flags are usually ignored.

> > This might succeed on Linux, but it's not guaranteed.  It certainly
> > doesn't work this way on Cygwin.  Call something like `mprotect (addr,
> > virt_size, PROT_READ|PROT_WRITE)' before accessing the mmap'ed memory.
> 
> Why?  I already told mmap it should have these attributes.
> 
> There is a bug in one of our understandings of MAP_NORESERVE symantics.
> My understanding of MAP_NORESERVE is from the Solaris man page:
> 
>  The MAP_NORESERVE option specifies that  no  swap  space  be
>  reserved for a mapping. Without this flag, the creation of a
>  writable MAP_PRIVATE mapping reserves swap  space  equal  to
>  the  size  of the mapping; when the mapping is written into,
>  the reserved space  is employed to hold  private  copies  of
>  the  data.  A  write  into  a MAP_NORESERVE mapping produces
>  results which depend on the  current  availability  of  swap
>  space  in  the  system.   If  space  is available, the write
>  succeeds and a  private copy of the written page is created;
>  if  space  is not available, the write fails and a SIGBUS or
>  SIGSEGV  signal  is  delivered  to  the   writing   process.
>  MAP_NORESERVE  mappings are inherited across  fork(); at the
>  time of the fork(), swap space is reserved in the child  for
>  all  private  pages  that  currently  exist  in  the parent;
>  thereafter the child's mapping behaves as described above.
> 
> So, the only difference with MAP_NORESERVE is that swap space is not
> reserved up front, but on reference (read is unclear from this
> description, but write is definately clear).  If on reference we run out
> of swap, SIGBUS is generated.
> 
> What am I missing?

I just read the Linux man page (again), and I seem to have missed some
important bits.  The above semantics are not implemented this way in
Cygwin.  A private anonymous mmap is actually just an area allocated
with VirtualAlloc.  A MAP_NORESERVE area is not commited (MEM_COMMIT)
but just reserved (MEM_RESERVE).  What's missing is the automatic
commiting when a page fault on one of these pages occurs.  I added an
(hopefully) appropriate patch, which commits a page within a
MAP_NORESERVE area when memory in this page is accessed by the
application.  If commiting the memory fails, SIGBUS is generated.
Please test CVS HEAD or the next developer snapshot from
http://cygwin.com/snapshots/

Note however, that MAP_NORESERVE is only implemented for private
anonymous mappings.  Shared anonymous maps seem to be possible (and
would probably make sense to minimze the swap space footprint), but are
somewhat tricky since it's not quite clear what happens to memory which
is commited in one process and then accessed in another.  This would
require some extensive testing which I'm not willing to do yet.

File-backed mappings are always ignoring the MAP_NORESERVE flag and are
using committed memory, since uncommitted file maps are not supported on
Windows.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: error OpenSSL required

[Corinna Vinschen]

On Jul 12 23:07, openmikey wrote:
> 
> I'm sure i'm missing something only a noob would, but i'm trying to compile
> createtorrent from www.createtorrent.com.
> 
> When i run ./configure, i get the following error:
> 
> checking for SHA1 in -lssl... no
> configure: error: error, OpenSSL required
> 
> However i am sure that openssl and openssl-dev 0.098 and 0.097 are
> installed.  Please help me get some sleep :/

You should debug the configure script, which usually starts with
examining the config.log file.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: child node copy

[Robin Walker]

--On 12 July 2006 19:20 -0500 Deepa Mahajan wrote:


When I execute any script I get errors along the lines of

 12 [main] cvs 7412 child_copy: linked dll data write copy failed,
0x3F4000.
.0x3F4030, done 0, windows pid 2279572, Win32 error 487
cvs [checkout aborted]: cannot fork: Resource temporarily unavailable


"cannot fork: Resource temporarily unavailable"
Sometimes this is an interaction with other software on the PC.  For 
instance, sometimes, webcam software has been implicated.


--
Robin Walker

--
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: "replaced while being copied" - was ... RE: Solved partially by findutils 4.3 - RE: "inode changed", ...

[Corinna Vinschen]

On Jul 12 14:39, Ty Sarna wrote:
> Corinna Vinschen wrote:
> > No, I think that's enough for now.  As suggested by somebody on this
> > list some weeks ago, I will change the condition on which I use the real
> > inode number instead of faking the inode number using a hash value
> > depending on the FILE_SUPPORTS_OBJECT_IDS flag, except for Samba file
> > systems.  This should lower the chance to get unreliable inode numbers.
> 
> I'm running a cygwin install from yesterday (lib 1.5.20) and running
> into this issue.  The remote filesyste is a Samba share (2.2.8a), part
> of which is local to that box and other parts of which are in turn NFS
> mounted from NetApps and various other things.  I don't have much/any
> control of this environment... 
> 
> Even if I could get the Samba upgraded to a newer one that reported the
> correct file IDs, I don't know that it would help since sometimes it
> would be reporting the information from NetApp, which I understand can
> also be wrong? Further even if Cygwin has logic to deal with the NetApp
> it won't help in this case because it won't realize that's what it's
> ultimately talking to...
> 
> Perhaps the best thing to do is add a registry key/env var/some other
> kind of override that users can set, to prevent cygwin from trying to be
> intelligent here and just use the old hashing method always for Samba
> (which worked fine for me in this exact setup with older Cygwin)
> 
> It's nice when software can guess what the right thing is, but it's always
> good to have an override knob in case the guess is wrong :-)

Sorry, but I still think it's possible to get it right in Cygwin w/o
such a knob.  What about helping to debug why that happens instead
and get a knob-free solution?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: rebae ms url danging

[Jason Tishler]

Mark,

See the following:

http://cygwin.com/acronyms#PPIOSPE

On Thu, Jul 13, 2006 at 03:44:16AM -0700, Mark Charney wrote:
> In rebase 2.4.3 you have a URL in the file:
> 
>  /usr/share/doc/Cygwin/rebase-2.4.3.README
> 
> That points to here:
> 
>   http://msdn.microsoft.com/library/en-us/tools/tools/rebase.asp
> 
> That URL is not valid at MS, although it shows up in their own MSDN
> search engine. I *know* you don't maintain the MS web site :-) I did
> find it via the MSDN search in the Visual Studio MSDN search function:
> 
> ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.WIN32COM.v10.en/tools/tools/rebase.htm

I found its new location:

http://windowssdk.msdn.microsoft.com/en-us/library/ms726650.aspx

I have updated my README accordingly.

> Thansk for an interesting application!

You are quite welcome.

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

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

RE: make (v. 3.81) fails -- "target pattern contains no `%'"

[Dave Korn]

On 13 July 2006 01:47, Christopher Faylor wrote:

> On Wed, Jul 12, 2006 at 05:32:04PM -0700, Jim Lawson wrote:
 Date: Wed, 12 Jul 2006 20:15:27 -0400
>>> From: "Aslam Karachiwala" <[EMAIL PROTECTED]>

>>>  The error -- target pattern contains no `%' --
>>> occurs at a target
>>> such as the following:
>>> 
>>> releaseproducts  :: $(RELEASEDIR)/$(BINIMAGE)
>> 
>> I think you'll find that this is due to the dropping of support for
>> Windows paths in the new (3.81) version of make.  I suspect
>> $(RELEASEDIR) has a ':' in it somewhere.
>> 
>> Try something like this:
>> 
>> RELEASEDIR:=$(shell cygpath -u $(RELEASEDIR))
> 
> That is an inspired guess which never would have occurred to me.  I'll
> bet you're right, though.  That may even become a FAQ at some point.
> 
> If this isn't the case then we'll (obviously?) need to see more of
> the makefile than the one failing line.


  It's absolutely the case, I had the exact same problem myself when I built
(re)make from source without the cygwin-specific patches.

  In my case I fixed it by porting the diffs from the cygwin make-3.80 source
package.  (I have users who require a mixed-mode make environment).



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: GCC linker problem since last cygwin update

[Dave Korn]

On 13 July 2006 04:00, Olivier Langlois wrote:


> -Wl,--end-group
> /cygdrive/c/tools/PS2/usr.gcc/local/sce/ee/gcc/bin/../lib/gcc-lib/ee/3.2
> -ee-030926/../../../../ee/bin/ld:
> /cygdrive/c/tools/PS2/usr.gcc/local/sce/ee/gcc/bin/../lib/gcc-lib/ee/3.2
> -ee-030926/../../../../ee/bin/ld: cannot execute binary file
> 
> First, I have no clue what the error message means and from where it
> comes from.

  When you have an error message you don't understand, the first thing you
should do is enter it into google and see what comes up.  It took about ten
seconds to figure out that this is an error message from bash (or whichever
shell you're using) to say that the file you're trying to invoke does not seem
to be an executable but just looks like binary data.

  So, what output do you get from running 

file
/cygdrive/c/tools/PS2/usr.gcc/local/sce/ee/gcc/bin/../lib/gcc-lib/ee/3.2-ee-03
0926/../../../../ee/bin/ld

...?

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: python test failures

[Jason Tishler]

Neal,

On Tue, Jul 11, 2006 at 10:21:26PM -0700, Neal Norwitz wrote:
> We were originally running with 1.5.19. We supposedly upgraded to
> 1.5.20-1, however from one of the error msgs, it looks like we're
> still be running the old version.

Yes, see below...

> I didn't see anything in the CHANGELOG for 1.5.20 -1that looked like
> these issues were fixed though.  I'll try to get this upgraded for
> real.

Please do or try the latest snapshot:

http://cygwin.com/snapshots/

and report back your findings.

> [snip]
> 
> 15 [main] python 3232 python.exe: *** fatal error - unable to
> remap lib.cygwin-1.5.19-i686-2.5\datetime.dll to same address as
> parent(0x1920) != 0x6660

Besides needing to rebase your system, the above implies you are still
running 1.5.19.  Upgrade to 1.5.20 or the latest snapshot.  Then, create
a symlink lib.cygwin-1.5.20-i686-2.5 or lib.cygwin-1.5.21-i686-2.5 to
lib.cygwin-1.5.19-i686-2.5, respectively.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

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

rsync with one or two colons?

[siegfried]

I was reading about the different ways to run rsync. It looks like
connecting to an rsync deamon is very similar to connecting to an rsync
shell like ssh.

Are there situations where the deamon is superior to the ssh? Are there
situations where ssh is superior to the deamon?

Thanks,
Siegfried


--
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: Can't scp to a server running cygwin

[Ken Gough]

HA! I found it. 

I am using cygwin scp in order to interact with Mercury ITG (Kintana). 
They advised running a modified shell to avoid an error where bash processes 
remain after exiting. The modification they recommended follows:
/bin/bash --login --noediting -i

All is OK if I ditch their recommendation and use the normal bash shell. 

I will go on their forum and warn about this.

Thanks for the help,
Ken





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

Re: GCC linker problem since last cygwin update

[Larry Hall (Cygwin)]

Olivier Langlois wrote:

Hi Larry,

I would suggest you start by reading and following the problem

reporting

guidelines outlined here:


Problem reports:   http://cygwin.com/problems.html

Ok, I will

In particular, you want to look closely at whether you're actually

using

Cygwin's tools.  Your paths look suspect to me.


You are right. The compiler/linker that I'm using are not part of cygwin
but I think that I need cygwin since the compiler is based on gcc and my
OS is Windows. cygwin is somehow involved in my problem since
'/cygwin/c' is displayed in the error message but my cygwin knowledge is
big enough to fully understand the interaction between my compiler and
cygwin. All I know is that it was working fine few minutes before my
upgrade that included

cygwin DLL (1.5.20-1), coreutils (5.97-1) and binutils (20060709-1)

(My novice instinct makes me suspect these modules...)

and right after it was not working anymore.



I'd recommend looking at your paths then.  You can also try running
from a Cygwin shell.  I'd recommedn using POSIX paths as well.  Beyond
that, I can't make any more detailed recommendations with the
information you've provided so far.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (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: 1.5.21s mmap error

[Brian Ford]

On Thu, 13 Jul 2006, Corinna Vinschen wrote:

> I just read the Linux man page (again), and I seem to have missed some
> important bits.  The above semantics are not implemented this way in
> Cygwin.  A private anonymous mmap is actually just an area allocated
> with VirtualAlloc.  A MAP_NORESERVE area is not commited (MEM_COMMIT)
> but just reserved (MEM_RESERVE).  What's missing is the automatic
> commiting when a page fault on one of these pages occurs.

I figured as much based on your previous response, but I wanted to point
out that that was not the typical meaning of MAP_NORESERVE.

> I added an (hopefully) appropriate patch, which commits a page within a
> MAP_NORESERVE area when memory in this page is accessed by the
> application.  If commiting the memory fails, SIGBUS is generated. Please
> test CVS HEAD or the next developer snapshot from
> http://cygwin.com/snapshots/

Wow!  Thanks.  Given my limited Windows API knowledge, that sounded
difficult to accomplish properly.  I'll test it for you shortly.

> Note however, that MAP_NORESERVE is only implemented for private
> anonymous mappings.

I think the private restriction is typical, so...

> Shared anonymous maps seem to be possible (and would probably make sense
> to minimze the swap space footprint), but are somewhat tricky since it's
> not quite clear what happens to memory which is commited in one process
> and then accessed in another.  This would require some extensive testing
> which I'm not willing to do yet.

Huh, what does a shared anonymous (/dev/zero) mapping even mean?  You
can't modify /dev/zero, so the only thing that makes sense to me is that
changes made would be visible by the whole process tree containing the
mapping?  I'm not aware of any OS that supports this.

> File-backed mappings are always ignoring the MAP_NORESERVE flag and are
> using committed memory, since uncommitted file maps are not supported on
> Windows.

That's too bad :-(.  Does the above mean that a private file-backed
mapping consumes the full mapping size of swap space just in case all the
pages are dirtied?  Obviously, the file is the backing store until the
page is written, so there is no extra swap usage then.

BTW, If you haven't already, you might consider transparently changing
/dev/zero mappings to anonymous ones so MAP_NORESERVE is possible there.

Thanks again.

-- 
Brian Ford
Lead 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: rsync with one or two colons?

[Brian Ford]

On Thu, 13 Jul 2006, siegfried wrote:

> I was reading about the different ways to run rsync. It looks like
> connecting to an rsync deamon is very similar to connecting to an rsync
> shell like ssh.
>
> Are there situations where the deamon is superior to the ssh? Are there
> situations where ssh is superior to the deamon?

Since this isn't a Cygwin specific question, you'd probably get a better
answer if you asked it on the rsync list.

-- 
Brian Ford
Lead 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/

Imagemagick / GraphicsMagick on a brand new install

[Peter Pimley]

Hello everybody

I have just installed cygwin 1.5.20-1 on a fresh machine (4 fresh machines in 
fact), along with the ImageMagick package.

If I run ImageMagick's convert, mogrify or identify tools (and possibly others, 
I've not tried), they silently fail:



[EMAIL PROTECTED] ~
$ convert -version

[EMAIL PROTECTED] ~
$ convert -version && echo working

[EMAIL PROTECTED] ~
$ convert -version || echo not working
not working


This is the same on all the machines I've tried.

I believe convert.exe is failing with exit code 53.  I've got a makefile that 
calls convert.exe, and if I run it, it says "make: *** [(target)] Error 53"

The equivalents from GraphicsMagick fail in exactly the same way.

Another set of machines (identical hardware, OS, etc) that had cygwin installed 
on it a few months ago all work fine:

$ convert -version
Version: ImageMagick 6.0.4 Tue Aug 10 2004 Q16 
Copyright: Copyright (C) 1999-2004 ImageMagick Studio LLC
These machines run cygwin all day, every day, and have had no previous upsets.  
On one of these good machines, I ran setup.exe and let it install new versions 
of whatever it wanted.  If I ran convert.exe afterwards, it failed in exactly 
the same way.

If I run setup.exe on another 'good' machine, I can see from the 'select 
packages' page which packages would be updated.  ImageMagick is not in that 
list, and neither is any library that is obviously required.  The full list is:

Package old version good version

binutils 20050610-1 20060709-1 
coreutils 5.94-1 5.97-1 
curl 7.15.1-1 7.15.4-1 
cygwin 1.5.19-4 1.5.20-1 
gzip 1.3.5-1 1.3.5-2 
libcurl3 7.15.1-1 7.15.4-1 
make 3.80-1 3.81-1 
mingw-runtime 3.9-2 3.10-1 
openssl 0.9.8a-1 0.9.8a-1 
openssl097 0.9.7i-1 0.9.7j-1 
python 2.4.1-1 2.4.3-1 
run 1.1.9-1 1.1.10-1 
rxvt 20050409-1 20050409-3 
suite3270 (none) 3.3.4p7-1 
tcltk 20030901-1 20060202-1 
texinfo 4.8-2 4.8-3 
vim 6.4-4 7.0.035-1 
xorg-x11-base, xorg-x11-bin, xorg-x11-bin-dlls, xorg-x11-bin-Indir, 
xorg-x11-etc, xorg-x11-libs-data 6.8.2.0-1 6.8.99.901-1 
xorg-x11-fenc 6.8.1.0-2 6.8.99.901-1 
xorg-x11-fnts 6.8.1.0-3 6.8.99.901-1 
xorg-x11-xwin 6.8.2.0-4 6.8.99.901-1


On one of the new machines, I tried reverting the cygwin package back to 
1.5.19-4.  I ran convert.exe again, and I got a Windows dialog box complaining 
about not being able to find cygdpstk-1.dll.

Can anybody give me some pointers on what would be a good thing to try next?  
I'm out of ideas.

Thanks in advance,
Peter Pimley

__
Information contained in this e-mail is intended for the use of the addressee 
only, and is confidential and may be the subject of Legal Professional 
Privilege.  Any dissemination, distribution, copying or use of this 
communication without prior permission of the addressee is strictly 
prohibited.The views of the author may not necessarily constitute the views of 
Kuju Entertainment Ltd. Nothing in this email shall bind Kuju Entertainment Ltd 
in any contract or obligation.

The contents of an attachment to this e-mail may contain software viruses which 
could damage your own computer system. While Kuju Entertainment has taken every 
reasonable precaution to minimise this risk, we cannot accept liability for any 
damage which you sustain as a result of software viruses. You should carry out 
your own virus checks before opening the attachment.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
_

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

RE: GCC linker problem since last cygwin update

[Olivier Langlois]

Hi,

This is just to tell you that I have found a fix for my problem. In my
bin directory I have 2 files:

ld and ld.exe

To fix my problem, I just renamed ld to ld.tmp to make sure that it is
the ld.exe that get executed and it fixed the problem. Is this possible
that the order in which the executable names are evaluated is something
that has changed recently?

Anyhow, thanks to Larry and Dave for your help and suggestions!

Greetings,
Olivier Langlois
http://www.olivierlanglois.net


--
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: Perl failure

[Yitzchak Scott-Thoennes]

On Wed, Jul 12, 2006 at 05:08:43PM -0700, Bruce Dobrin wrote:
> Hi,
> 
> I have a server that has been doing back end maintenance using perl on
> cygwin for 6 years now.  I recently upgraded from win2k and cyg1.5.9 to
> XP sp3 and cyg1.5.19 (to be fare,  I also cleaned up the perl code a
> bit).  The script checks versioning and build info on about 600+ windows
> systems.  Since the upgrade,  it gets thru about 500 of them ( almost
> exactly 2 hours)  and then:
> 
> panic: MUTEX_LOCK (45) [util.c:2266] at
> /c/dist_and_install_files/source/dist2/spUpdate2d.pl line 24, 
> line 277.
> panic: MUTEX_LOCK (45) [op.c:354],  line 277.

This indicates EDEADLK being returned from posix_mutex_lock.
 
> It hits a slightly different time and position in the list each time,
> but always after approximately 2 hours.  I found a few old mails
> suggesting rebaseall,  which I ran to no effect.  The system pretty much
> runs nothing but this. I've been running a version of this script since
> cyg1.3.9 and never had a problem like this one.
> 
> Any suggestions?

Can you revert one or more of the many things you changed, and see if 
it makes a difference?

--
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: Imagemagick / GraphicsMagick on a brand new install

[Angelo Graziosi]

Peter Pimley wrote:

> If I run ImageMagick's convert, mogrify or identify tools (and possibly
> others, I've not tried), they silently fail


As was observed (http://cygwin.com/ml/cygwin-xfree/2006-05/msg00034.html),
this seems to depend on new xorg*-6.8.99.901-1.

Perhaps you can use Netpbm, instead.


Cheers,

   Angelo.



--
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: Updatedb does not finish

[Arun Biyani]

This morning there were no "find" jobs running. It appears that adding 
/proc to prunepaths

did work.

/usr/bin/updatedb --localpaths="/  /c" --prunepaths="/a/proc"

Arun

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Arun Biyani on 7/10/2006 5:23 PM:
  

I have been running "updatedb" via a cron job for almost 6 months now.
It is started
at 11PM & is usually done in an hour. Recently, I have been noticing
that there is a
"find" job still running when I get in, in the morning.



This looks like this thread may be relevant:
http://cygwin.com/ml/cygwin/2006-07/msg00331.html

Can you try setting PRUNEPATHS=/proc in your environment, and see if that
helps cut down the time updatedb takes by cutting down what it traverses?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtOus84KuGfSFAYARAqHQAJ9V7E+cpmeAg0N6/hRECKnU/llz1ACfW0qM
gIAx2qKja7aGYiH1jW06XjA=
=Zeur
-END PGP SIGNATURE-



  




--
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.20: Occasional crash at address 0x6100365f (cygthread::stub() in cygthread.cc)

[Christopher Faylor]

On Mon, Jul 10, 2006 at 04:51:21PM +1000, Kiyo Kelvin Lee wrote:
>Using 1.5.20, occasionally sh.exe would crash with the standard Windows 
>crash dialog with these information:
>
>[sh.exe - Application Error]
>The instruction at "0x6100365f" referenced memory at "0x006cda90". The 
>memory could not be "written".
>Click on OK to terminate the program.
>Click on CANCEL to debug the program.
>
>Tested snapshot 20060707 and the problem persists.
>
>With gdb, I found the address corresponding to the function 
>cygthread:stub() of cygthread.cc (snapshot 20060707) at line 65:
>   _my_tls._ctinfo = info;
>
>Reported the problem before but, however, I hope the little further 
>information can help resolving the problem.

Is /bin/sh.exe bash or ash on your system.

Also, could you include the cygcheck output as mentioned at
http://cygwin.com/problems.html ?

I appreciate that you've taken the steps to debug this but without a way
to duplicate the problem there isn't much that can be done.  I've run
both bash and ash in every way I could think of to duplicate this
problem with no success.  I'm stumped as to how and why a cygthread
could be firing while a process is exiting.

If you can capture this state in gdb and get backtraces of all of the
running threads, that would probably help.

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.21s mmap error

[Corinna Vinschen]

On Jul 13 10:07, Brian Ford wrote:
> On Thu, 13 Jul 2006, Corinna Vinschen wrote:
> > Shared anonymous maps seem to be possible (and would probably make sense
> > to minimze the swap space footprint), but are somewhat tricky since it's
> > not quite clear what happens to memory which is commited in one process
> > and then accessed in another.  This would require some extensive testing
> > which I'm not willing to do yet.
> 
> Huh, what does a shared anonymous (/dev/zero) mapping even mean?  You
> can't modify /dev/zero, so the only thing that makes sense to me is that
> changes made would be visible by the whole process tree containing the
> mapping?  I'm not aware of any OS that supports this.

Huh?  Say "shared memory" multiple times...  think again... and?

> > File-backed mappings are always ignoring the MAP_NORESERVE flag and are
> > using committed memory, since uncommitted file maps are not supported on
> > Windows.
> 
> That's too bad :-(.  Does the above mean that a private file-backed
> mapping consumes the full mapping size of swap space just in case all the
> pages are dirtied?  Obviously, the file is the backing store until the
> page is written, so there is no extra swap usage then.

Isn't that what !MAP_NORESERVE usually means?  To re-quote from your
Solaris quote:

  Without this flag, the creation of a writable MAP_PRIVATE mapping
  reserves swap  space  equal  to the  size  of the mapping.

It might be possible to get MAP_NORESERVE working for files on NT.
I see how it could work, but further mmap enhacements are pretty
low on my overlong TODO list.

> BTW, If you haven't already, you might consider transparently changing
> /dev/zero mappings to anonymous ones so MAP_NORESERVE is possible there.

Did you try it lately, say, in the last 5 1/2 years?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: make (v. 3.81) fails -- "target pattern contains no `%'"

[Aslam Karachiwala]

Thanks, guys. I'll try this when I get a chance to reinstall 3.81, and
report back. At the moment I''ve reverted to 3.80, and have a deadline
approaching...you know how it is :)

On 7/13/06, Dave Korn <[EMAIL PROTECTED]> wrote:

On 13 July 2006 01:47, Christopher Faylor wrote:

> On Wed, Jul 12, 2006 at 05:32:04PM -0700, Jim Lawson wrote:
 Date: Wed, 12 Jul 2006 20:15:27 -0400
>>> From: "Aslam Karachiwala" <[EMAIL PROTECTED]>

>>>  The error -- target pattern contains no `%' --
>>> occurs at a target
>>> such as the following:
>>>
>>> releaseproducts  :: $(RELEASEDIR)/$(BINIMAGE)
>>
>> I think you'll find that this is due to the dropping of support for
>> Windows paths in the new (3.81) version of make.  I suspect
>> $(RELEASEDIR) has a ':' in it somewhere.
>>
>> Try something like this:
>>
>> RELEASEDIR:=$(shell cygpath -u $(RELEASEDIR))
>
> That is an inspired guess which never would have occurred to me.  I'll
> bet you're right, though.  That may even become a FAQ at some point.
>
> If this isn't the case then we'll (obviously?) need to see more of
> the makefile than the one failing line.


  It's absolutely the case, I had the exact same problem myself when I built
(re)make from source without the cygwin-specific patches.

  In my case I fixed it by porting the diffs from the cygwin make-3.80 source
package.  (I have users who require a mixed-mode make environment).



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/





--
Aslam Karachiwala
http://www.mythicflow.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/

RE: Imagemagick / GraphicsMagick on a brand new install

[Peter Pimley]

As was observed (http://cygwin.com/ml/cygwin-xfree/2006-05/msg00034.html),
this seems to depend on new xorg*-6.8.99.901-1.

---

Oh yes, how embarassing!  I didn't know there was such a thing as 
GraphicsMagick until today, so I didn't google for it.

I rolled back my X packages, and it all works fine.  Thanks for pointing it 
out.  Hopefully it'll be fixed in some future release.

__
Information contained in this e-mail is intended for the use of the addressee 
only, and is confidential and may be the subject of Legal Professional 
Privilege.  Any dissemination, distribution, copying or use of this 
communication without prior permission of the addressee is strictly 
prohibited.The views of the author may not necessarily constitute the views of 
Kuju Entertainment Ltd. Nothing in this email shall bind Kuju Entertainment Ltd 
in any contract or obligation.

The contents of an attachment to this e-mail may contain software viruses which 
could damage your own computer system. While Kuju Entertainment has taken every 
reasonable precaution to minimise this risk, we cannot accept liability for any 
damage which you sustain as a result of software viruses. You should carry out 
your own virus checks before opening the attachment.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
_

--
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: Perl failure

[Yitzchak Scott-Thoennes]

On Thu, Jul 13, 2006 at 08:53:09AM -0700, Yitzchak Scott-Thoennes wrote:
> On Wed, Jul 12, 2006 at 05:08:43PM -0700, Bruce Dobrin wrote:
> > Hi,
> > 
> > I have a server that has been doing back end maintenance using perl on
> > cygwin for 6 years now.  I recently upgraded from win2k and cyg1.5.9 to
> > XP sp3 and cyg1.5.19 (to be fare,  I also cleaned up the perl code a
> > bit).  The script checks versioning and build info on about 600+ windows
> > systems.  Since the upgrade,  it gets thru about 500 of them ( almost
> > exactly 2 hours)  and then:
> > 
> > panic: MUTEX_LOCK (45) [util.c:2266] at
> > /c/dist_and_install_files/source/dist2/spUpdate2d.pl line 24, 
> > line 277.
> > panic: MUTEX_LOCK (45) [op.c:354],  line 277.
> 
> This indicates EDEADLK being returned from posix_mutex_lock.

Err, I mean pthread_mutex_lock.

--
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.21s mmap error

[Brian Ford]

On Thu, 13 Jul 2006, Brian Ford wrote:
> On Thu, 13 Jul 2006, Corinna Vinschen wrote:
> > I added an (hopefully) appropriate patch, which commits a page within a
> > MAP_NORESERVE area when memory in this page is accessed by the
> > application.  If commiting the memory fails, SIGBUS is generated. Please
> > test CVS HEAD or the next developer snapshot from
> > http://cygwin.com/snapshots/
>
> Wow!  Thanks.  Given my limited Windows API knowledge, that sounded
> difficult to accomplish properly.  I'll test it for you shortly.

One problem found.  If the memory is not touched before using it as a
buffer to a read call, the read returns -1 with errno set to ISDIR.  STC
attached.

Thanks again for looking at this.

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...
.

#include 
#include 
#include 
#include 
#include 
#include 
#include 


int
main(int argc, char * argv[])
{
int   virt_size, fd;
void *addr;

addr  = NULL;
virt_size = 0x1800;
addr = mmap(addr, virt_size, (PROT_READ|PROT_WRITE),
(MAP_NORESERVE|MAP_PRIVATE|MAP_ANON), -1, 0);
if (addr == MAP_FAILED)
{
perror("mapping VM scratch space");
return -1;
}

fd = open("/proc/self/exe", O_RDONLY);
if (fd < 0)
{
perror("open self");
return -1;
}

#ifdef PRE_TOUCH
memset(addr, -1, sysconf(_SC_PAGESIZE));
#endif

if (read(fd, addr, sysconf(_SC_PAGESIZE)) < 0)
{
perror("read");
close(fd);
return -1;
}

close(fd);

return 0;
}
--
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: autossh-1.4a-1

[Schulman . Andrew]

A new version of the autossh package is available in the Cygwin
distribution.  autossh is a program to start an instance of ssh and
monitor it, restarting it if it should die or stop passing traffic.

Changes in version 1.4a-1:
* New upstream release: bug fixes.

Andrew E. Schulman


***


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

1.5.20-1 perl 2328 sig_send: wait for sig_complete event failed

[William Sheehan]

We have a collection of perl scripts that run every night.  Just recently we
updated Cygwin to 1.5.20-1 using the latest setup.exe on the site, and
updated all the other binaries as part of it.  Unfortunately, I cannot
remember what version we upgraded from; it was a long time ago, I'd guess
about 5 months.  However, as of the update, we are always seeing the
following messages in one of the later scripts:

  2 [unknown (0xD8)] perl 2328 sig_send: wait for sig_complete event
failed, signal -41, rc 258, Win32 error 0
  14776 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -41, rc 258, Win32 error 0
60040177 [unknown (0xD8)] perl 2328 sig_send: wait for sig_complete event
failed, signal -34, rc 258, Win32 error 0
60040273 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -34, rc 258, Win32 error 0
120065422 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -34, rc 258, Win32 error 0
180075174 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -34, rc 258, Win32 error 0
240084816 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
305125262 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
370150140 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
435174910 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
500199735 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
565224563 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
630249383 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
695289861 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
760314652 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
825339473 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
890364299 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
955389118 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
1020429594 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
1085454400 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
1150479299 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0
1215504053 [unknown (0x44C)] perl 2328 sig_send: wait for sig_complete event
failed, signal -40, rc 258, Win32 error 0


-
Observations
-

This always happens in the same script, though I have been unable to produce
a simple testcase that exhibits this behavior.  Unfortunately, I cannot do a
simple attachment/paste of our scripts, since they contain a lot of private
information.  I am working on creating a public version that can be
reviewed, but it is going to take a while.  I will try to summarize as best
I can in the meantime.  Here are some important details about the
environment and the errors:

* The script uses Perl's ithreads (summary of what the script does is below)

* The signal numbers that you see in the output are always the same; always
2x -41, 4x -34, 16x -40.  After that last -40, I need to kill the sh.exe
process to get a prompt back; Ctrl+C does nothing.  Killing perl.exe does
not work.  After killing sh.exe, perl.exe is still running.  If nothing is
killed, the script will hang indefinitely (well, at least for 17 hours).

* The numbers at the very beginning of the lines are different every time

* The hex numbers by the 'unknown' word change with each run of the script,
however in every instance they always follow the same pattern.  HexA, HexB,
HexA, 19x HexB

* The problematic script is invoked from a parent script via system("perl
problem_script.pl")

* The errors always seem to occur about 20 minutes into the problem script.
It isn't exact, but so far the times have been 21 minutes, 20, 22, 21, 23.
This is roughly halfway through the 28 expect scripts that each thread
executes (see below for details).

* The scripts did not change during or since the Cygwin upgrade to 1.5.20-1.


-
How the script works
-

1) We have a parent script that orchestrates all the child test scripts.  It
iterates through all pos

Re: 1.5.20-1 perl 2328 sig_send: wait for sig_complete event failed

[Larry Hall (Cygwin)]

William Sheehan wrote:






-
Environment details
-

I have attached the cygcheck output per the problem reporting guidelines.


This has nothing to do with your problem (at least not obviously) but don't
you find having a UNC path in your PATH to be real slow?





-
Possible solution paths?
-

* I read in the guidelines that it is generally not advisable to mention
that these scripts worked with the previous versions of Cygwin.  One idea I
had was to try some older versions of Perl from the Cygwin setup and see if
the problem still occurs.  Should I go through with that idea?



I'd say that if you're willing to try variations on a theme, you're better
off trying the latest and greatest snapshot of the Cygwin DLL from
.  The only other version of Perl that's
available is from a year ago January so if you last updated 5 months ago,
your Perl hasn't changed in this last round.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (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: Perl failure

[Bruce Dobrin]

I ran just the core part of the script,  it forks off a number of
rsync's for every machine it is checking.  When the panic happens it
kills of the parent,  but the remaining children finish successfully.

 I then brought back up the previous server that I had used (win2k
machine with cyg1.5.5).  The script ran through successfully on the
older machine.  I had to make minor changes to my Perl script:

1: I use ping to check if the machines are alive,  the older ping
response needs to be parsed differently

2: I use rsync for version control,  Rsync (old and new)  will hang
about 5% of the time on the old cygwin and about 0.5% of the time on the
new, often to the point where cygwin's kill won't kill it.  In these
cases I also call /c/windows/system32/taskkill on XP,  but I need to
call windows kill on win2k.

3: All the data that is version controlled is kept on the new cyg 1.5.19
XP server,  so I had to change the data location from a local drive on
the newer machine to a network drive on the newer machine.  

So I'm at the point where the old server works with new code (  though
it is very slow and rsync is very unreliable on it)  and a new machine
which runs great until it craps out after 1.5 hours.

I hope the above helps

Thanks
Bruce D.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Yitzchak Scott-Thoennes
Sent: Thursday, July 13, 2006 8:53 AM
To: cygwin@cygwin.com
Subject: Re: Perl failure

On Wed, Jul 12, 2006 at 05:08:43PM -0700, Bruce Dobrin wrote:
> Hi,
> 
> I have a server that has been doing back end maintenance using perl on

> cygwin for 6 years now.  I recently upgraded from win2k and cyg1.5.9 
> to XP sp3 and cyg1.5.19 (to be fare,  I also cleaned up the perl code 
> a bit).  The script checks versioning and build info on about 600+ 
> windows systems.  Since the upgrade,  it gets thru about 500 of them (

> almost exactly 2 hours)  and then:
> 
> panic: MUTEX_LOCK (45) [util.c:2266] at 
> /c/dist_and_install_files/source/dist2/spUpdate2d.pl line 24, 
>  line 277.
> panic: MUTEX_LOCK (45) [op.c:354],  line 277.

This indicates EDEADLK being returned from posix_mutex_lock.
 
> It hits a slightly different time and position in the list each time, 
> but always after approximately 2 hours.  I found a few old mails 
> suggesting rebaseall,  which I ran to no effect.  The system pretty 
> much runs nothing but this. I've been running a version of this script

> since
> cyg1.3.9 and never had a problem like this one.
> 
> Any suggestions?

Can you revert one or more of the many things you changed, and see if it
makes a difference?

--
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: 1.5.20-1 perl 2328 sig_send: wait for sig_complete event failed

[William Sheehan]

Thank you for the snapshot advice; right now (well, into tomorrow and
possibly Monday) I will be doing a binary search of the installation
snapshots to try and track down the offending diff.  The latest snapshot
exhibits the same behavior.  So far I have narrowed the problem down to
between Feb 03 and May 25.

You were correct about the Perl version; downgrading it did not fix the
issue.  I did notice that downgrading the 'cygwin' package did fix the
issue, even when combined with the latest perl.  So it seems we're on the
right track.

I knew the UNC in the path would come up!  This machine is only automated
operations under normal circumstances.  Every binary required by the scripts
is either before the UNC path or executed with a modified PATH variable, and
since the scripts don't make typos, it hasn't been an issue.  As to why the
UNC path is still there, given that we don't use it...hmm, question of the
year :)

William Sheehan
Builds Engineer / Network Administrator
Open Interface North America

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Larry Hall (Cygwin)
Sent: Thursday, July 13, 2006 3:14 PM
To: cygwin@cygwin.com
Subject: Re: 1.5.20-1 perl 2328 sig_send: wait for sig_complete event failed


William Sheehan wrote:




> 
> -
> Environment details
> -
> 
> I have attached the cygcheck output per the problem reporting 
> guidelines.

This has nothing to do with your problem (at least not obviously) but don't
you find having a UNC path in your PATH to be real slow?



> 
> -
> Possible solution paths?
> -
> 
> * I read in the guidelines that it is generally not advisable to 
> mention that these scripts worked with the previous versions of 
> Cygwin.  One idea I had was to try some older versions of Perl from 
> the Cygwin setup and see if the problem still occurs.  Should I go 
> through with that idea?


I'd say that if you're willing to try variations on a theme, you're better
off trying the latest and greatest snapshot of the Cygwin DLL from
.  The only other version of Perl that's
available is from a year ago January so if you last updated 5 months ago,
your Perl hasn't changed in this last round.


-- 
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (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/




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

DLL loading problem with binutils-20060709-1

[Bill Metzenthen]

I have been developing a mixed python / C++ program which uses SWIG to
handle the interface.  This worked fine until I updated binutils to
20060709-1.  Then when the python script tried to load the DLL generated
with the help of SWIG, the following error message appeared:
Traceback (most recent call last):
  File "main.py", line 13, in ?
from py_extend import *
  File "/c/usr/projects/py_extend.py", line 5, in ?
import _py_extend
ImportError: Permission denied

All file permissions looked o.k.  Restoring binutils to 20050610-1 fixed
the problem.

Is the new binutils broken?  Is there a new ld option I should be using?
Or perhaps I was getting away with bad behaviour before and the new
binutils is punishing me?  I have been generating the DLL simply with "g++
-shared $(OBJECTS) -o _py_extend.dll".

Bill Metzenthen
Cochlear Limited
Level 1, 174 Victoria Parade
East Melbourne  Vic  3002
Australia
PH:  +61 3 8662 3101
FAX: +61 3 9663 8652

Web: http://www.cochlear.com


==

"The information contained in this e-mail message may be confidential 
information, and may also be privileged. If you are not the intended recipient, 
any use, interference with, disclosure or copying of this material is 
unauthorised and prohibited.  If you have received this message in error, 
please notify us by return email and delete the original message."

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

Consol mode question

[Benn Fine]

Warning - old time unix user, unsure windows user

newbie question: how do I use cygwin from a dos
window, as seen in the example below from the
documentation.

Console Mode Applications
Use gcc to compile, just like under UNIX. Refer to the
GCC User's Guide for information on standard usage and
options. Here's a simple example:

Example 4.1. Building Hello World with GCC

C:\> gcc hello.c -o hello.exe
C:\> hello.exe
Hello, World

C:\>

. 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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/