Re: Problems with gitk after cygwin update

[Corinna Vinschen]

On Sep 19 23:04, Michael Lutz wrote:
> Hello,
> 
> I just updated my Cygwin installation with the newest packages, especially
> cygwin base from 1.7.5 to 1.7.7 and git from 1.7.1 to 1.7.2.3.
> 
> I'm now having problems when I launch gitk in the background from a xterm,
> i.e. "gitk &". First of all, if I press any key after I switch back to the
> xterm, it just closes. On the prompt "logout" is visible for just a moment
> before it closes.
> 
> Secondly, I got the following error log when clicking around in gitk to
> view some commits. I never had such problems before I updated.
> 
> Michael Lutz
> 
> --- snip 1 
> $ cygcheck -c cygwin git gitk
> Cygwin Package Information
> Package  VersionStatus
> cygwin   1.7.7-1OK
> git  1.7.2.3-1  OK
> gitk 1.7.2.3-1  OK
> 
> Windows 7 Pro x64 with all updates.
> 
> --- snip 2 
> 
>   0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't
> initialize fd 0 for /dev/tty1
> Stack trace:
> Frame Function  Args
> 002838C8  6102749B  (002838C8, , , )
> 00283BB8  6102749B  (61177B80, 8000, , 61179977)
> 00284BE8  61004AFB  (611A1670, , 6123AAC4, 0001)
> End of stack trace
>   0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't
> initialize fd 0 for /dev/tty1

I can't reproduce the stack dumps, but I can reproduce the premature
exit of the parent shell.  This is a problem I'm still mulling over:
http://cygwin.com/ml/cygwin/2010-09/msg00237.html
Your scenario is equivalent since gitk uses the tk shell wish, which
starts its child processes like a native Windows application using the
CreateProcess call, rather than Cygwin's fork/exec.  This in turn leads
to a collision in the terminal foreground process group handling
between the child process started by wish, and the parent bash.
I have a simple solution for this problem, which is to revert the code
in Cygwin to the 1.7.5 state.  However, this isn't a satisfying solution,
because this results in another problem:

  Microsoft Windows [Version 6.1.7600]
  Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

  C:\cygwin\bin>set CYGWIN=tty

  C:\cygwin\bin>bash --login

  cori...@vmbert7 ~
  $ cmd
  Microsoft Windows [Version 6.1.7600]
  Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

  C:\cygwin\home\corinna>bash --login<== HANGS taking 100% CPU!!!

I'd rather find a fix for both problems...


Corinna

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

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

Re: where was mention of what creates NUL files?

[Oleksandr Gavenko]

On 17.09.2010 20:12, Daniel Barclay wrote:

Does anyone recall a mention of what in CygWin (or possibly Emacs) creates
files with a simple name of "NUL"?


I also use native Emacs and after some operation I got file with name NUL.

I have a lot NUL files in many dirs, which can be removed only from Cygwin:

  $ rm NUL

I don't fully  debug but think this come from 'null-device' variable
(which has 'NUL' value by default).

To friend native GNU Emacs with Cygwin (and stop creating NUL) I use:

(when (eq system-type 'windows-nt)
  (setq shell-file-name "bash")
  ;; Workaround for Cygwin shell, when set 'CYGWIN=noglob'. By default 
'shell-quote-argument'

  ;; quoted by double '\' chars this cause failure.
  (defun shell-quote-argument (argument)
(concat "'" argument "'")
)
  ;; Workaround for Cygwin when 'shell-file-name' is 'bash'.
  (setq null-device "/dev/null")
  )

--
Happy hacking!


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

Re: ssh from linux to cygwin + CUI + Ctrl-C

[Ilia K.]

On Fri, Sep 17, 2010 at 7:58 AM, Andrew DeFaria  wrote:
>  On 09/16/2010 12:05 PM, Ilia K. wrote:
>>
>> Have you tried to ssh to cygwin, then run cmd.exe (to get a "dos
>> prompt") and then press Ctrl-C?
>
> Good lord man! Why would I want to do that?!?
>>
>> In my case this terminates cmd.exe and
>> returns to bash, but this behavior is wrong (try to press Ctrl-C in
>> cmd.exe which is run directly from the desktop, not from ssh session).
>
> Stop using cmd.

cmd is just an example of "native CUI" windows program. Right now I
actually need to run cdb, which is quite different app.

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

Re: simplifying rebaseall

[Al]

> I'd beg to differ; I'd suggest it is, as suggested by the OP,
> actually quite a common use. You only have to look at the use of
> say perl and you will have users quite regularly compiling their
> own DLL's as they install modules via CPAN, and this is quite painful
> due to all the issues it can present with rebase.
>
> While I love cygwin, I must say that its supporting community can
> be very dismissive of its users to the point of alienating potential
> contributors. I myself has have experienced this on several occasions
> and have ended up finding myself not raising issues that affect us
> daily for fear of being shot down for no more reason that someone
> doesn't "think" its import to fix or should "work" that way anyway
> or even doesn't like the way you structured you post.
>
> To reiterate I still think that developers deserve much respect
> and thanks for all the effort they put in, but a little more open
> mindedness and approachability like that which can be found in other
> open source communities such as SFU and FreeBSD wouldn't go a miss
> sometimes ;-)
>
>   Regards
>   Steve
>

thanks

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

Re: [ANNOUNCEMENT] Testing: mintty-0.9b1-1

[Oleksandr Gavenko]

On 18.09.2010 13:35, Andy Koppe wrote:

CHANGES
Colours:
- Added ability to set the 16 ANSI colours in the config file (or on
the command line via the -o option), like so: 'Blue=0,0,255' or
'BoldGreen=128,255,128'. The manual has all the colour names.

This is very useful.

Thanks.


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

Re: ssh from linux to cygwin + CUI + Ctrl-C

[Ilia K.]

It looks like my reply got lost in mailer's spam filters, reposting.

On Wed, Sep 15, 2010 at 5:36 PM, Christopher Faylor wrote:
...
> Cygwin summarily halts a pure-Windows process on receiving a CTRL-C.
> There is no way around that other than to relink the program to use
> Cygwin.

Do you state that there is absolutely no way to make it work as I need?
This would be very pity...

Do you know what's the difference between running bash from sshd and
from the desktop? In the later case, Ctrl-C works as expected! To me
it looks like cygwin knows how to pass Ctrl-C to native apps, but sshd
somehow interferes with it.

Regards,
Ilia.

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

Re: Problems with gitk after cygwin update

[Michael Lutz]

Hello,
thanks for looking into this.

Am 20.09.2010 10:55 schrieb Corinna Vinschen:
> I can't reproduce the stack dumps, but I can reproduce the premature
> exit of the parent shell.  This is a problem I'm still mulling over:
> http://cygwin.com/ml/cygwin/2010-09/msg00237.html

I don't always get the stack dump either and I couldn't figure out a
pattern for when it happens, so I'm not surprised. I can always open up a
second xterm so this bug isn't that critical.

There is another problem with git that I occasionally saw with older
cygwin version as well, but feels to have become much more common lately.
It happens when using "git gui", which incidentally is a tk wish app as
well. It's harder to reproduce, but the recipe below should do the trick.

As a preparation in some temp dir:
$ git init .
$ echo -e "a\nb" > file.txt
$ git add file.txt
$ git commit -m "Commit"
$ echo -e "a\na\nc\nd" > file.txt

Now start citool:
$ git gui citool

The big pane on the right has some red and green line, click on one of
these lines with a right click and select "Stage this line". If you're
lucky, this will hang git gui because it seems to wait for the output of a
git command it spawned. The git command is hanging in process startup
though, the stack trace below made with Process Explorer of the hanging
command looks like it is waiting on some mutex.

If it actually works the first try, click on the file icon in the lower
left pane to unstage the line again and repeat until the hang occurs. It
happens quite often that it hangs the first time for me, but sometimes it
only hangs after several minutes of work done with git gui.

Michael Lutz

--- snip 1 ---
Stack trace with Process Monitor
Command "C:\cygwin\lib\git-core\git-rev-parse.exe --verify HEAD"

ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PsIsSystemProcess+0x94
ntoskrnl.exe!KeStackAttachProcess+0x11c1
ntoskrnl.exe!ObReferenceObjectByPointerWithTag+0x233
ntoskrnl.exe!PsLookupProcessThreadByCid+0x56f
ntoskrnl.exe!KeTestAlertThread+0xa79
ntoskrnl.exe!KeTestAlertThread+0x9fb
ntdll.dll!RtlUserThreadStart


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

Re: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud

[Ernest Mueller]

Hey, great find, I'm glad to know that this wasn't all "me being crazy."
I'm impressed this went from problem ID to a new test kernel version in 2
months flat.  I've pinged Amazon to see if they can get on the track of
this too; I suspect they aren't exactly uptaking kernel changes quickly but
we'll find out.

(Sorry this is a bit delayed, I don't read the list regularly, I come back
and search every month to see if anyone's found the problem yet - looks
like I hit the jackpot this time!)

Ernest

> I'm not into Cygwin development enough to know what a BLODA is, but you
> may like to know the bug is in the Xen hypervisor used by Amazon.  I
> don't know exactly what releases or Xen are affected, but for sure all
> RHEL5 (and CentOS 5) hypervisors are.
>
> The reason why you see it only on 64-bit Windows, is that the bug is
> about Xen mishandling the SWAPGS instruction which, well, is only
> present in 64-bit processors and in 64-bit mode.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=613187
>
> Paolo
>
> ps: KVM was also affected until last February.  I haven't checked if
> RHEL/CentOS KVM has the bug, but I'll ask fellow developers around about
it.
__
UN-altered REPRODUCTION and DISSEMINATION of
this IMPORTANT information is ENCOURAGED.






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

Re: awk gsub problem

[Eric Blake]

On 09/19/2010 02:33 PM, Lee wrote:

If LANG is "en_US" or "en_US.utf8", then the regular expression "[a-z]"
does *not* correspond anymore to the ASCII codes.  Rather it corresponds
to something like "[aAbBcCdD...zZ]", independent of the actual character
encoding ISO-8859-1 or UTF-8.


In glibc, [a-z] gets translated according to locale collation order.  If 
A collates before a, then it maps to [aBbCc..Zz], if A collates after a, 
then it maps to [aAbB...yYz] (notice that in either case, one of the two 
capital letters is omitted, so it is NOT the same as all 26 letters in 
both cases).


This has been a MUCH complained-about feature of glibc, which has in 
turn been copied by bash, awk, grep, etc.


Note that POSIX explicitly states that [a-z] has unspecified results in 
any locale except C.  So the glibc behavior is permitted, but so is the 
traditional behavior of just the 26 lowercase letters.


If you can convince the glibc folks that [a-z] should have the 
traditional behavior, more power to you.


http://lists.gnu.org/archive/html/bug-grep/2010-09/msg00030.html

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: Unacceptable behavior -- slowing down script execution

[Eric Blake]

On 09/18/2010 05:35 AM, SJ Wright wrote:

Is there any reason, when bash itself nowadays has pretty good
tab-completion, why bash-completion is still available in setup.exe or
elsewhere in the Luniverse?


Yes.  Builtin bash completion ONLY targets command names (in the first 
shell word) and file names (in subsequent shell words). The 
bash-completion package adds context-sensitive tab completion (ssh  
completes on known machine names, chown  completes on known user 
names, git branch  completes on branch names in the current 
repository, etc.).  If you want the additional context sensitivity 
(which _I_ do), then bash-completion is a must.  If you don't mind 
losing out on the extra context sensitivity and want bash to use less 
resources, then avoid bash-completion.  It's up to you.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
volunteer cygwin bash-completion maintainer

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

Re: Unacceptable behavior -- slowing down script execution

[SJ Wright]

mike marchywka wrote:

On 9/17/10, SJ Wright  wrote:
  

4. Is it normal for any script to run CPU usage up to 100%?



Unless it is blocking for something like IO including VM swaps, why not?


  

Regarding #4:
I have a script that I ran in GNOME Terminal less than an hour ago. I
"time"d it -- the return was 20.6 seconds on the first line (real?). I
ran the same script fifteen minutes later, evaluating identical files of
the same type, length (5.37kb and 345b ASCII text) and time stamp, and
after 7 minutes it was barely one-eighth complete. That's when I checked
Task Manager and found my CPU usage was at 100% and three bash.exe's
were running simultaneously. Admittedly the script calls on several



This sounds like a threading problem if I had to guess but it could
be anything that changed between runs- certainly timing will make
these things come and go but having no idea what you mean by identical
instead of  "the same" there are a lot of things that could have changed etc.
What did it seem to be trying to do? Often in cases like this
the alarming situation is where your cpu usage drops to low values
and your disk light gets stuck on as you have depleted memory.

I guess I'm also not sure what you think a usual or good number
of processes should be etc. A number of anecdotes have been
reported about slower performance on 64 bit or multi core machines
than  more primitive older cmoputers and it is easy to
speculate on reasons why that could happen
but hard to make a clear diagnosis without an explicit test case.

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


  
They were the same files, in terms of number of lines, bytes per line, 
and so forth. Likely the only differences were to be found in their 
timestamps.
This one script seems, now that I've got rid of bash-completion (thanks 
again Cyrille), to be the only one that will push CPU usage to 100% and 
keep it there for the duration of its execution.


Call me strange, but I like my Task Manager to show me no more than 51 
processes at a time. I also like my scripts to call up one and only one 
additional instance of the shell they're written to be executed in than 
I'm running before I start one.


I agree it's likely a threading problem, but I think it's more likely 
how I have the script written.


A breakdown of the calls to non-internal (not BASH built-ins, so far as 
I can judge) would look like this:


 -- 8 to Exiv2 v.0.20 by Andreas Huggel.

Likely there are more; I may be wrong. I don't normally keep track of 
which command came from where or calls on what class of "ps"- able 
process. Perhaps, as this has involved and included more than two shells 
running simultaneously (by visual evidence in Task Manager and nothing 
else), it is, instead, a matter of a too-high demand *on* the internals. 
Or I've got another software package, either Cygwin-adapted or just a 
lucky compile on my part, that's kicking in and making  itself known 
when I launch this one particular script.


I can post the script to the list as text if anyone thinks it's worth 
pursuing this line of logic.


Thanks for the replies and the help thus far. Looking forward to the 
same continuing.


Steve Wright

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

Re: ssh from linux to cygwin + CUI + Ctrl-C

[Larry Hall (Cygwin)]

On 9/20/2010 6:22 AM, Ilia K. wrote:

It looks like my reply got lost in mailer's spam filters, reposting.

On Wed, Sep 15, 2010 at 5:36 PM, Christopher Faylor wrote:
...

Cygwin summarily halts a pure-Windows process on receiving a CTRL-C.
There is no way around that other than to relink the program to use
Cygwin.


Do you state that there is absolutely no way to make it work as I need?
This would be very pity...

Do you know what's the difference between running bash from sshd and
from the desktop? In the later case, Ctrl-C works as expected! To me
it looks like cygwin knows how to pass Ctrl-C to native apps, but sshd
somehow interferes with it.


See  and look for the
'tty' setting.  If you set 'tty' before starting 'bash', you'll see the same
issue even using a plain console (cmd.exe). I'm assuming that's
what you mean when you say "from the desktop" above.  Actual terminals,
rxvt, mintty, etc., will have the same behavior you saw with 'sshd'.
Currently, there is no way to support ptys and make Windows understand them
as something other than a pipe.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

Re: fvwm ignores clickToFocus for function keys

[Charles Smith]

> a) Are you running fvwm under a rootless X11?

No, but I will try that at work tomorrow and report back

> b) are your configs the same?

The same as what?  Sorry, I don't understand the question.




  

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

Problem with mmap in latest snapshot

[Heath Kehoe]

 My application uses mmap on a 16MB file. On released 1.7.7, there's no 
problem. But with the 20100919 snapshot, it crashes when it tries to 
access the mmap space past the first 32KB or so. Attached is a simple 
test program that illustrates the problem.


* With 1.7.7 *

$ uname -a
CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin

$ ./a
creating mmap-test-file
Writing zeros
mmap-ing
writing ones to mmap region
done!

$ ls -l mmap*
-rw-r--r--+ 1 hkehoe Domain Users 16777216 2010-09-20 14:51 mmap-test-file

$ od -tc mmap-test-file
000 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001
*
1

* With snapshot *

$ uname -a
CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.8s(0.231/5/3) 20100919 16:19:37 i686 Cygwin

$ ./a
creating mmap-test-file
Writing zeros
mmap-ing
writing ones to mmap region
Segmentation fault (core dumped)

$ od -tc mmap-test-file
000 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001
*
010  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
1




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

#define MMAP_FILE "mmap-test-file"
#define MMAP_SIZE 16384*1024

main()
{
int fd;
char* maddr;

printf("creating " MMAP_FILE "\n");
fd = open(MMAP_FILE, O_CREAT|O_TRUNC|O_RDWR, 0666);
if(fd < 0)
{
perror("Could not open " MMAP_FILE);
exit(1);
}

printf("Writing zeros\n");
{
int n = MMAP_SIZE;
char buf[1024];
memset(buf, 0, 1024);
while(n > 0)
{
write(fd, buf, 1024);
n -= 1024;
}
}

printf("mmap-ing\n");
maddr = mmap(NULL, MMAP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if(maddr == NULL || maddr == MAP_FAILED)
{
perror("mmap");
exit(1);
}

printf("writing ones to mmap region\n");
{
int n;
for(n = 0; n < MMAP_SIZE; n++)  
maddr[n] = 1;
}

printf("done!\n");
}


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

Re: Problem with mmap in latest snapshot

[Heath Kehoe]

 On 9/20/2010 3:00 PM, Heath Kehoe wrote:

   My application uses mmap on a 16MB file. On released 1.7.7, there's no
problem. But with the 20100919 snapshot, it crashes when it tries to
access the mmap space past the first 32KB or so. Attached is a simple
test program that illustrates the problem.



The test program also crashes on 20100917, but it works with 20100912.

-h

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


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

missing pthread.h in building 64-bit aaplications

[ke...@ca]

Hello All,

Goal: Building 64-bit application on Cygwin
OS: 64-bit Windows 7

I used "x86_64-w64-mingw32-gcc " to build the application, but failed.
The output tells missing pthread.h. pthread.h is included in one of my
source files.

I located the file, one in C:\cygwin\usr\include, the other
C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include.

I tried using -I to tell gcc to include pthread.h, but failed. why? 
-- 
View this message in context: 
http://old.nabble.com/missing-pthread.h-in-building-64-bit-aaplications-tp29764972p29764972.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: missing pthread.h in building 64-bit aaplications

[Christopher Faylor]

On Mon, Sep 20, 2010 at 05:01:52PM -0700, ke...@ca wrote:
>
>Hello All,
>
>Goal: Building 64-bit application on Cygwin
>OS: 64-bit Windows 7
>
>I used "x86_64-w64-mingw32-gcc " to build the application, but failed.
>The output tells missing pthread.h. pthread.h is included in one of my
>source files.
>
>I located the file, one in C:\cygwin\usr\include, the other
>C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include.
>
>I tried using -I to tell gcc to include pthread.h, but failed. why? 

This is a MinGW compiler.  It doesn't support pthread.  Any threading
support would be with standard Windows calls.

cgf

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

Re: missing pthread.h in building 64-bit aaplications

[Charles Wilson]

On 9/20/2010 10:18 PM, Christopher Faylor wrote:
> On Mon, Sep 20, 2010 at 05:01:52PM -0700, ke...@ca wrote:
>> I used "x86_64-w64-mingw32-gcc " to build the application, but failed.
>> The output tells missing pthread.h. pthread.h is included in one of my
>> source files.
>>
>> I located the file, one in C:\cygwin\usr\include, the other
>> C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include.
>>
>> I tried using -I to tell gcc to include pthread.h, but failed. why? 
> 
> This is a MinGW compiler.  It doesn't support pthread.  Any threading
> support would be with standard Windows calls.

I don't think that's accurate.  The x86_64-mingw64 cross compiler
package set includes a win32-pthreads package, including pthread.h.
It's necessary for gcc's OMP support via libgomp.

That's why the OP was able to find one copy of pthread.h in
C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include.  The real
question is why the (cross)compiler couldn't locate it; given the whole
/mingw prefix and sysroot support, it really should be able to.

--
Chuck

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

Re: missing pthread.h in building 64-bit aaplications

[Yaakov (Cygwin/X)]

On Mon, 2010-09-20 at 17:01 -0700, ke...@ca wrote:
> I used "x86_64-w64-mingw32-gcc " to build the application, but failed.
> The output tells missing pthread.h. pthread.h is included in one of my
> source files.
> 
> I located the file, one in C:\cygwin\usr\include, the other
> C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include.
> 
> I tried using -I to tell gcc to include pthread.h, but failed. why? 

Keep in mind that the new mingw* compilers are Cygwin-hosted
cross-compilers: they use standard *NIX paths.  In any case, if
mingw64-x86_64-pthreads is installed, then you don't need an -I flag at
all; pthread.h should already be in the default search path.


Yaakov



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

Re: missing pthread.h in building 64-bit aaplications

[Christopher Faylor]

On Mon, Sep 20, 2010 at 10:38:48PM -0400, Charles Wilson wrote:
>On 9/20/2010 10:18 PM, Christopher Faylor wrote:
>> On Mon, Sep 20, 2010 at 05:01:52PM -0700, ke...@ca wrote:
>>> I used "x86_64-w64-mingw32-gcc " to build the application, but failed.
>>> The output tells missing pthread.h. pthread.h is included in one of my
>>> source files.
>>>
>>> I located the file, one in C:\cygwin\usr\include, the other
>>> C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include.
>>>
>>> I tried using -I to tell gcc to include pthread.h, but failed. why? 
>> 
>> This is a MinGW compiler.  It doesn't support pthread.  Any threading
>> support would be with standard Windows calls.
>
>I don't think that's accurate.  The x86_64-mingw64 cross compiler
>package set includes a win32-pthreads package, including pthread.h.
>It's necessary for gcc's OMP support via libgomp.

Yeah, duh.  I should have picked up on that from the report.

Sorry for the noise.

cgf

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