Re: Emacs can't start-process more than 30~40 processes

[Haojun Bao]

Christopher Faylor  writes:

> On Tue, Jul 28, 2009 at 10:52:44AM +0800, Haojun Bao wrote:
>>I have debugged it again, and I think I have more clue. I have read the
>>how-cygheap-works.txt, and this might be a known problem.
>>
>>It's because the cygheap space has been used up. With Procexp, I can see
>>cygwin1.dll is based 0x6100, with size 0x30 (3M). When segfault
>>is about to happen, cygheap_max is 0x6164e924, and the _csbrk is called
>>with a increase of 
>>(gdb) p sbs
>>$16 = 65544
>>This will increase cyghead to 0x6165e92c, but from Proxexp I can see
>>cygncurses-9.dll is based at 0x6165.
>>
>>Besides, this code snippet from pipe.cc fhandler_pipe::create didn't
>>check for NULL pointer, and directly caused the segfault.
>>
>>  fhs[0] = (fhandler_pipe *) build_fh_dev (*piper_dev);
>>  fhs[1] = (fhandler_pipe *) build_fh_dev (*pipew_dev);
>>
>>//bhj: we should check NULL here.
>
> Not necessarily.  We don't expect these functions to return NULL.  It
> would be interesting to know how many fds are open at this point.  If it
> is a large number then maybe we have to start enforcing an fd max.  If
> it is a "small" number then something is wrong and we're allocating too
> much of the cygheap.  The cygheap was always supposed to be relatively
> small.  Maybe we're abusing it too much in 1.7.

There are quite some fds. In start-process, emacs will allocate 1 PTY
and 1 pipe for each process it starts.

Each fhandler_base is about 32K, but the _csbrk must allocate 65544
bytes for it.

--
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: Invalid csih method in ssh-user-config scripts

[Corinna Vinschen]

On Jul 28 23:41, Steven Hartland wrote:
> In the latest version of ssh-user-config from 1.7 it uses the method
> csih_error_multiline which doesn't exist, I assume this should be
> csih_error_multi from:
> /usr/share/csih/cygwin-service-installation-helper.sh

Thanks for the report.  I uploaded a new openssh package with the
fixed script.


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: mingw headers and libraries missing

[Georg Troska]

Wow,

sounds I have all the experts sitting together in this list. Maybe you  
can help me once more:


First a brief plan:
I'm working for the ATLAS-Collaborationand we need  for  
detectordevelopment a programinterface.
We have one really big and really old programm written in LabWindows C  
Code (of course in Windows) this is really a mess.
And we have a big new program which is almost platform-independet (http://projects.hepforge.org/eudaq/ 
).


These programs shound communicate with each other. As the eudaq-code  
is running very well on cygwin I thought it would be easy to write a  
dll for accessing it from windows. The LabWindow-thing can handle this  
- I tried this out.


So I changed the source-code a bit so that eudaq-software compiles  
with -mno-cygwin. In deed I get it compilable. But then the code is  
not running. For me two major problems have focussed out: I have a  
dependency on sys/selector.h and a dependency on pthread.h I think I  
can link against this external pthread-libraries (http://sourceware.org/pthreads-win32/ 
). And I found a switch inside the code for linking against  
winsock(2).h This switch is for beeing compatible with Visual C++,  
which actually is not working.


I'm not really sure if I can use the windows-like winsock environment  
in cygwin. Is it really compatible? What does this stuff with posix  
and so on mean in detail?


What do you think? Is it easier to get this stuff running in cygwin or  
to make it possible in Visual C++? I would definetly prefer the first  
one.


How far is the development of the windows cross-compiler really?




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

MVFS on cygwin: Thanks, and plug for ClearCase::Wrapper::MGi

[Marc Girod]

Thanks for the recent fixes to make cygwin support mvfs for handling the
emacs symlink locks!

I keep updating my CPAN modules to run ClearCase from cygwin.
With the recent ClearCase::Argv 1.46, and ClearCase::Wrapper::MGi 0.11,
I get the following kind of transcripts:

ClearCase-Wrapper-MGi> mount //view/emagiro_cw /view/emagiro_cw
mount: warning - /view/emagiro_cw does not exist.
mount: defaulting to 'notexec' mount option for speed since native path
  references a remote share.  Use '-f' option to override.
ClearCase-Wrapper-MGi> cd /view/emagiro_cw/atcctest/foo
foo> ct ls -d .
.@@/main/mg/1Rule: .../mg/LATEST
foo> ct co -/dbg=1 -nc .
=> "des -fmt %m ."
=> "ls -d ."
=> "co -nc ."
Checked out "." from version "/main/mg/1".
foo> ct unco -/dbg=1 -rm .
=> "ls -s -d ."
=> "unco -rm ."
Checkout cancelled for ".".


The wrapper has still some limitations.
>From a naive user's point of view, its inconsistent support for interactive
prompts
from cleartool is probably the most annoying...

Marc
-- 
View this message in context: 
http://www.nabble.com/MVFS-on-cygwin%3A-Thanks%2C-and-plug-for-ClearCase%3A%3AWrapper%3A%3AMGi-tp24715103p24715103.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: How to install-libLTLIBRARIES dll to bin?

[Dave Korn]

Charles Wilson wrote:
> Dave Korn wrote:
> 
>>   Only libtool knows about the DLL.  Only the Makefile knows about the 
>> setting
>> of $bindir from configure.  Currently however the Makefile only passes the
>> path to the output in $libdir.  Therefore ISTM that the only correct solution
>> is to add a --bindir= option to libtool and modify automake or libtoolise to
>> ensure it gets passed by the makefiles when they invoke libtool.
> 
> Agreed.  This is still on my TODO list for the cygwin version of
> libtool, and (obviously) for eventual submission to upstream.  However,
> if somebody beats me to it, PTC.

  Something like this?  Untested as yet, I'm going to put it through a gcc
bootstrap cycle.  Should I be worried about stripping any final slash off the
-bindir option to avoid inadvertent doubling-up when I append "/bin/...", do you
reckon?

cheers,
  DaveK


diff --git a/Makefile.am b/Makefile.am
index a18955e..129b890 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -494,7 +494,8 @@ TESTSUITE_AT	= tests/testsuite.at \
 		  tests/configure-iface.at \
 		  tests/stresstest.at \
 		  tests/cmdline_wrap.at \
-		  tests/darwin.at
+		  tests/darwin.at \
+		  tests/win32.at
 
 EXTRA_DIST += $(srcdir)/$(TESTSUITE) $(TESTSUITE_AT) $(srcdir)/tests/package.m4
 
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
old mode 100644
new mode 100755
index ebd3909..a1889d3
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially:
 
   -all-static   do not do any dynamic linking at all
   -avoid-versiondo not add a version suffix if possible
+  -bindir BINDIRspecify path to $prefix/bin (needed only when installing
+a Windows DLL)
   -dlopen FILE  \`-dlpreopen' FILE if it cannot be dlopened at runtime
   -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
   -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -3659,6 +3661,7 @@ func_mode_link ()
 new_inherited_linker_flags=
 
 avoid_version=no
+bindir=
 dlfiles=
 dlprefiles=
 dlself=no
@@ -3751,6 +3754,11 @@ func_mode_link ()
 	esac
 
 	case $prev in
+	bindir)
+	  bindir="$arg"
+	  prev=
+	  continue
+	  ;;
 	dlfiles|dlprefiles)
 	  if test "$preload" = no; then
 	# Add the symbol object into the linking commands.
@@ -4012,6 +4020,11 @@ func_mode_link ()
 	continue
 	;;
 
+  -bindir)
+	prev=bindir
+	continue
+	;;
+
   -dlopen)
 	prev=dlfiles
 	continue
@@ -7706,7 +7719,13 @@ EOF
 	  # place dlname in correct position for cygwin
 	  tdlname=$dlname
 	  case $host,$output,$installed,$module,$dlname in
-	*cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
+	*cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll)
+	  tdlname=../bin/$dlname
+	  if test "x$bindir" != "x" ;
+	  then
+		tdlname=$bindir/$dlname
+	  fi
+	  ;;
 	  esac
 	  $ECHO > $output "\
 # $outputname - a libtool library file

--
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: How to install-libLTLIBRARIES dll to bin?

[Peter Rosin]

Den 2009-07-29 11:46 skrev Dave Korn:

Charles Wilson wrote:

Dave Korn wrote:


  Only libtool knows about the DLL.  Only the Makefile knows about the setting
of $bindir from configure.  Currently however the Makefile only passes the
path to the output in $libdir.  Therefore ISTM that the only correct solution
is to add a --bindir= option to libtool and modify automake or libtoolise to
ensure it gets passed by the makefiles when they invoke libtool.

Agreed.  This is still on my TODO list for the cygwin version of
libtool, and (obviously) for eventual submission to upstream.  However,
if somebody beats me to it, PTC.


  Something like this?  Untested as yet, I'm going to put it through a gcc
bootstrap cycle.  Should I be worried about stripping any final slash off the
-bindir option to avoid inadvertent doubling-up when I append "/bin/...", do you
reckon?


I don't think it's that easy, the dlname in the .la file is relative
to the position of the .la file itself. It's simply not intended to
to be an absolute path.

And you forgot the file tests/win32.at in the patch...

Cheers,
Peter

--
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: How to install-libLTLIBRARIES dll to bin?

[Dave Korn]

Peter Rosin wrote:
> I don't think it's that easy, the dlname in the .la file is relative
> to the position of the .la file itself. It's simply not intended to
> to be an absolute path.

  Argh.  Tell you what, let's change it from -bindir to -relative-bindir and
just say that you have to pass in "../../../../bin/" or whatever you want.

> And you forgot the file tests/win32.at in the patch...

  Yeh, haven't got beyond a skeleton for that yet, this is WIP :)

cheers,
  DaveK


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

[ANNOUNCEMENT] New package: cppcheck-1.34-1

[Chris Sutcliffe]

Version 1.34-1 of cppcheck has been uploaded.

cppcheck is a tool for static C/C++ code analysis.  It tries to detect
bugs that your C/C++ compiler don't see.
The goal is no false positives.

cppcheck is versatile. You can check non-standard code that includes
various compiler extensions, inline assembly code, etc.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

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

http://sourceware.org/lists.html#unsubscribe-simple

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

-- 
Chris Sutcliffe
http://emergedesktop.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: AWK from a batch file

[Mark J. Reed]

On Tue, Jul 28, 2009 at 12:42 PM, Matthew Swanson wrote:
> I am attempting to run AWK in a bash window through a Windows batch file.  I
> am using:
>
> echo awk -v FS=',' -v OFS=',' '^{ > awk.s
> echo    if ^($2 ~ /^^[0-9]*$/^)>> awk.s
> echo            print $0 ^>^> "good_file.txt">> awk.s
> echo    else>> awk.s
> echo            print $0 ^>^> "bad_file.txt">> awk.s
> echo ^}' input_file.txt>> awk.s

OK, so you are creating a bash script from CMD.  Invoking it outside
of Cygwin means the normal bash startup files are not run, so $PATH is
not set, so it can't find any commands.  Replace "awk" with "/bin/awk"
and you should be good, apart from the lack of execute permission.

The second problem is that CMD's "echo" appends carraige returns.
Add these commands to fix both that problem and the execute permission
one:

\cygwin\bin\d2u awk.s
\cygwin\bin\chmod +x awk.s

-- 
Mark J. Reed 

--
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: Python-devel on Windows XP build

[Jason Tishler]

Gwen,

On Wed, Jul 29, 2009 at 02:57:38AM -0400, Gwen Morse wrote:
> I'm trying to compile Tinyfuge with python extensions on my Windows XP
> box. I have the source which is reported by friends to compile
> properly on linux systems.
> 
> ./configure fails, checking the log I see this message:
> 
> configure:8153: result: no
> configure:8169: checking for strstr
> configure:8226: gcc -o conftest.exe -g -O2 -DTFPYTHON  
> -I/usr/include/python2.5   -Lpcre-2.08 conftest.c  -lssl -lcrypto 
> -lpython2.5 >&5
> conftest.c:68: warning: conflicting types for built-in function 'strstr'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: 
> cannot find -lpython2.5

The following will solve the above build problem:

LDFLAGS=-L/usr/lib/python2.5/config configure

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

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

Fresh install of Cygwin on Vista with no Home drectiory

[Aaron Gray]

Wheres home gone ?

I installed fresh Cygwin on Vista Enterprise, but I don't seem to have a 
home directory ?


Many thanks in advance,

Aaron


--
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: Python-devel on Windows XP build

[Dave Korn]

Jason Tishler wrote:
> Gwen,
> 
> On Wed, Jul 29, 2009 at 02:57:38AM -0400, Gwen Morse wrote:
>> I'm trying to compile Tinyfuge with python extensions on my Windows XP
>> box. I have the source which is reported by friends to compile
>> properly on linux systems.
>>
>> ./configure fails, checking the log I see this message:
>>
>> configure:8153: result: no
>> configure:8169: checking for strstr
>> configure:8226: gcc -o conftest.exe -g -O2 -DTFPYTHON  
>> -I/usr/include/python2.5   -Lpcre-2.08 conftest.c  -lssl -lcrypto 
>> -lpython2.5 >&5
>> conftest.c:68: warning: conflicting types for built-in function 'strstr'
>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: 
>> cannot find -lpython2.5
> 
> The following will solve the above build problem:
> 
> LDFLAGS=-L/usr/lib/python2.5/config configure
> 
> Jason
> 

  I believe you're meant to specify LDFLAGS after the 'configure' these days,
i.e. as an argument to configure, not a shell variable.

./configure LDFLAGS=-L/usr/lib/python2.5/config < other args ... >

cheers,
  DaveK


--
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: Fresh install of Cygwin on Vista with no Home drectiory

[Aaron Gray]

2009/7/29 Aaron Gray 
>
> Wheres home gone ?

Helps to run Bash !

Sorry for the noise,

Aaron

--
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: Python-devel on Windows XP build

[Jason Tishler]

Dave,

On Wed, Jul 29, 2009 at 04:27:20PM +0100, Dave Korn wrote:
> Jason Tishler wrote:
> > The following will solve the above build problem:
> > 
> > LDFLAGS=-L/usr/lib/python2.5/config configure
> > 
> > Jason
> > 
> 
> I believe you're meant to specify LDFLAGS after the 'configure' these
> days, i.e. as an argument to configure, not a shell variable.
> 
> ./configure LDFLAGS=-L/usr/lib/python2.5/config < other args ... >

I wasn't aware LDFLAGS, etc. is suppose to be specified after configure.
FWIW, I actually tried the command line above (i.e., LDFLAGS specified
before configure) and it seemed to work.

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

--
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: Python-devel on Windows XP build

[Dave Korn]

Jason Tishler wrote:
> Dave,
> 
> On Wed, Jul 29, 2009 at 04:27:20PM +0100, Dave Korn wrote:
>> Jason Tishler wrote:
>>> The following will solve the above build problem:
>>>
>>> LDFLAGS=-L/usr/lib/python2.5/config configure
>>>
>>> Jason
>>>
>> I believe you're meant to specify LDFLAGS after the 'configure' these
>> days, i.e. as an argument to configure, not a shell variable.
>>
>> ./configure LDFLAGS=-L/usr/lib/python2.5/config < other args ... >
> 
> I wasn't aware LDFLAGS, etc. is suppose to be specified after configure.
> FWIW, I actually tried the command line above (i.e., LDFLAGS specified
> before configure) and it seemed to work.

  It does, at least most of the time, and it did used to be the standard way of
doing things, but it's deprecated now in favour of:

> $ /gnu/gcc/gcc/configure --help
> `configure' configures this package to adapt to many kinds of systems.
> 
> Usage: /gnu/gcc/gcc/configure [OPTION]... [VAR=VALUE]...
> 
> To assign environment variables (e.g., CC, CFLAGS...), specify them as
> VAR=VALUE.  See below for descriptions of some of the useful variables.

cheers,
  DaveK

--
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: bash pipeline exit code - possible race condition?

[Larry Hall (Cygwin)]

On 07/29/2009 01:16 AM, David Antliff wrote:

I've noticed a strange problem with bash pipelines in Cygwin that
might indicate some sort of race condition. I cannot reproduce the
problem on a Linux system, but it seems easy to reproduce in Cygwin.





I am running Cygwin on Windows XP (service pack 3).

$ uname -srv
CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34


Want to try the test again with the upcoming Cygwin 1.7 release?
  1.5.x is will be replaced by it very
shortly so unless the problem is still visible in 1.7, it's not likely
to spark much investigation.  Just FYI.

--
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: bash pipeline exit code - possible race condition?

[Dave Korn]

Larry Hall (Cygwin) wrote:
> On 07/29/2009 01:16 AM, David Antliff wrote:
>> I've noticed a strange problem with bash pipelines in Cygwin that
>> might indicate some sort of race condition. I cannot reproduce the
>> problem on a Linux system, but it seems easy to reproduce in Cygwin.
> 
> 
> 
>> I am running Cygwin on Windows XP (service pack 3).
>>
>> $ uname -srv
>> CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34
> 
> Want to try the test again with the upcoming Cygwin 1.7 release?
>   1.5.x is will be replaced by it very
> shortly so unless the problem is still visible in 1.7, it's not likely
> to spark much investigation.  Just FYI.

  It reproduces for me under 1.7, but I haven't had time to look closer yet.

  Thanks for the nice simple testcase, David!

cheers,
  DaveK


--
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: strange behavior with threads...

[jean-luc malet]

On Fri, Jul 24, 2009 at 8:43 PM, benadam777 wrote:
>
>
>
> jean-luc malet wrote:
>>
>> I have a X server connection issue
>>
>> freeglut (./tests/GENERATED/GlutWindowTest): Unable to create direct
>> context rendering for window ' '
>> This may hurt performance.
>> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
>> ":0.0"
>>       after 34 requests (32 known processed) with 5 events remaining.
>>
>>
>
> I receive the same error when running ubuntu in a virtual environment and
> everything I have found regarding that issue points to either improper
> configuration of xorg.conf for multiple video cards or video cards that
> don't support OpenGL.
> --

I just tried with ubuntu in a virtual environment and everything run
fine, seems to come from cygwin/X
Best Regards,
JLM


-- 
KISS! (Keep It Simple, Stupid!)
(garde le simple, imbécile!)
"mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses
simples et qui marchent, espèce d'imbécile!"
-
"Si vous pensez que vous êtes trop petit pour changer quoique ce soit,
essayez donc de dormir avec un moustique dans votre chambre." Betty
Reese
http://www.grainesdechangement.com/citations.htm

--
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: mingw headers and libraries missing

[Georg Troska]

Ok,
thank you all for reading this stuff

I'm able to run the code now with visual c++. I had never thought I  
would use it ;-)


actually it took me 3 hours to run a hello world and anther 6 to run  
the code


however thanks a lot. and please let me now when the cross-comipler is  
working


Georg
Am 29.07.2009 um 10:53 schrieb Georg Troska:


Wow,

sounds I have all the experts sitting together in this list. Maybe  
you can help me once more:


First a brief plan:
I'm working for the ATLAS-Collaborationand we need  for  
detectordevelopment a programinterface.
We have one really big and really old programm written in LabWindows  
C Code (of course in Windows) this is really a mess.
And we have a big new program which is almost platform-independet (http://projects.hepforge.org/eudaq/ 
).


These programs shound communicate with each other. As the eudaq-code  
is running very well on cygwin I thought it would be easy to write a  
dll for accessing it from windows. The LabWindow-thing can handle  
this - I tried this out.


So I changed the source-code a bit so that eudaq-software compiles  
with -mno-cygwin. In deed I get it compilable. But then the code is  
not running. For me two major problems have focussed out: I have a  
dependency on sys/selector.h and a dependency on pthread.h I think I  
can link against this external pthread-libraries (http://sourceware.org/pthreads-win32/ 
). And I found a switch inside the code for linking against  
winsock(2).h This switch is for beeing compatible with Visual C++,  
which actually is not working.


I'm not really sure if I can use the windows-like winsock  
environment in cygwin. Is it really compatible? What does this stuff  
with posix and so on mean in detail?


What do you think? Is it easier to get this stuff running in cygwin  
or to make it possible in Visual C++? I would definetly prefer the  
first one.


How far is the development of the windows cross-compiler really?






--
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: Emacs can't start-process more than 30~40 processes

[Christopher Faylor]

On Wed, Jul 29, 2009 at 03:32:28PM +0800, Haojun Bao wrote:
>Christopher Faylor  writes:
>
>> On Tue, Jul 28, 2009 at 10:52:44AM +0800, Haojun Bao wrote:
>>>I have debugged it again, and I think I have more clue. I have read the
>>>how-cygheap-works.txt, and this might be a known problem.
>>>
>>>It's because the cygheap space has been used up. With Procexp, I can see
>>>cygwin1.dll is based 0x6100, with size 0x30 (3M). When segfault
>>>is about to happen, cygheap_max is 0x6164e924, and the _csbrk is called
>>>with a increase of 
>>>(gdb) p sbs
>>>$16 = 65544
>>>This will increase cyghead to 0x6165e92c, but from Proxexp I can see
>>>cygncurses-9.dll is based at 0x6165.
>>>
>>>Besides, this code snippet from pipe.cc fhandler_pipe::create didn't
>>>check for NULL pointer, and directly caused the segfault.
>>>
>>>  fhs[0] = (fhandler_pipe *) build_fh_dev (*piper_dev);
>>>  fhs[1] = (fhandler_pipe *) build_fh_dev (*pipew_dev);
>>>
>>>//bhj: we should check NULL here.
>>
>> Not necessarily.  We don't expect these functions to return NULL.  It
>> would be interesting to know how many fds are open at this point.  If it
>> is a large number then maybe we have to start enforcing an fd max.  If
>> it is a "small" number then something is wrong and we're allocating too
>> much of the cygheap.  The cygheap was always supposed to be relatively
>> small.  Maybe we're abusing it too much in 1.7.
>
>There are quite some fds. In start-process, emacs will allocate 1 PTY
>and 1 pipe for each process it starts.

Yes, I assumed that there were a bunch of fds but I was looking for an
exact number rather than "quite some".  I can't give exact details about
how to find the number now but I thought that since you were looking at
the code it wouldn't be too hard to figure this value out.

Anyway, Corinna has a stopgap fix for this which will probably show up
in a 1.7.0-* release sometime soon.

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: bash pipeline exit code - possible race condition?

[Christopher Faylor]

On Wed, Jul 29, 2009 at 05:16:24PM +1200, David Antliff wrote:
>I've noticed a strange problem with bash pipelines in Cygwin that
>might indicate some sort of race condition. I cannot reproduce the
>problem on a Linux system, but it seems easy to reproduce in Cygwin.
>
>I'm running the following command in a bash script that builds some software:
>
>/usr/bin/make --version | head -1
>
>I then test the exit code ($?) against zero and abort if it's non-zero.
>
>Before this executes I have set:
>set -o pipefail
>
>This is to ensure that if any command in a pipeline fails, the entire
>command will return a failed error code. I.e. if make returns
>non-zero, then $? will be non-zero. Without "pipefail", $? is set to
>the exit code of the last process in the pipeline (head), regardless
>of the error code of preceding programs (make).
>
>I am doing this because I want the script to log the version of Make
>that it is using, as well as verify that the make binary is present.
>Most of the time this works fine, $? is zero, and the script continues
>happily.
>
>However occasionally $? comes back as the value "141". I think that
>this value is coming from make because if I turn pipefail off, the
>error code is always zero and never 141, and there's nothing else in
>the pipeline. QED.
>
>This is very curious (and causes my script to break occasionally) so I
>wrote a little script to test this out:
>
>#!/bin/bash
>set -o pipefail
>err_count=0
>count=0
>while : ; do
>count=$((count + 1))
>/usr/bin/make --version | head -1 > /dev/null
>EC=$?
>if (( EC != 0 )) ; then
>err_count=$((err_count+1))
>echo "$count : $EC  ($err_count)"
>fi
>done

This doesn't appear to be a cygwin problem.  I get occasional errors
on linux as well.

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: Emacs can't start-process more than 30~40 processes

[Haojun Bao]

Christopher Faylor  writes:

> On Wed, Jul 29, 2009 at 03:32:28PM +0800, Haojun Bao wrote:
>>>
>>> Not necessarily.  We don't expect these functions to return NULL.  It
>>> would be interesting to know how many fds are open at this point.  If it
>>> is a large number then maybe we have to start enforcing an fd max.  If
>>> it is a "small" number then something is wrong and we're allocating too
>>> much of the cygheap.  The cygheap was always supposed to be relatively
>>> small.  Maybe we're abusing it too much in 1.7.
>>
>>There are quite some fds. In start-process, emacs will allocate 1 PTY
>>and 1 pipe for each process it starts.
>
> Yes, I assumed that there were a bunch of fds but I was looking for an
> exact number rather than "quite some".  I can't give exact details about
> how to find the number now but I thought that since you were looking at
> the code it wouldn't be too hard to figure this value out.
>

Sorry. There are a total of 40 fds in one test run from
/proc/PID/fd. Seems the PTYs and pipes are allocated and released soon,
what remains are /dev/ptmx fds.

$'ls' -l /proc/5668/fd 
total 0
lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 -> /dev/tty2
lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 1 -> /dev/tty2
lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 2 -> /dev/tty2
lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 37 -> /dev/tty36
lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 38 -> pipe:[2180]|
lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 39 -> pipe:[2232]|
...
#bhj: fd 3-36 are all opened -> /dev/ptmx
...


--
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: bash pipeline exit code - possible race condition?

[David Antliff]

On Thu, Jul 30, 2009 at 11:31, Christopher
Faylor wrote:
> On Wed, Jul 29, 2009 at 05:16:24PM +1200, David Antliff wrote:
>>I've noticed a strange problem with bash pipelines in Cygwin that
>>might indicate some sort of race condition. I cannot reproduce the
>>problem on a Linux system, but it seems easy to reproduce in Cygwin.
>
> This doesn't appear to be a cygwin problem.  I get occasional errors
> on linux as well.

I tried to reproduce on Linux but without success - did you simply run
my script or perhaps something else? Do you see error "141" as well?

If that is the case, then I might take this to... the bash people? the
make people? Hmmm

-- David.

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