Re: [ANNOUNCEMENT] Updated: gnuplot-4.2.4-1 - A command-line driven interactive function plotting utility.

[Jim Kleckner]

Jim Kleckner wrote:

Dr. Volker Zell wrote:

Hi

A new version of 'gnuplot' has been uploaded to a server near you.
  


[snip]

Would you mind to consider including the patch documented here:
http://article.gmane.org/gmane.os.cygwin.applications/17023
and here:
http://cygwin.com/ml/cygwin-apps/2008-06/msg00102.html

Is that list the correct place to submit those kind of patches?

My recent upgrade caused me to rediscover this performance patch.
I didn't re-measure the effects, but it seems like much more than 2X 
speedup now.


Attached is a combined patch file.
--- origsrc/gnuplot-4.2.4/src/plot.c2007-06-07 09:26:32.0 -0700
+++ src/gnuplot-4.2.4/src/plot.c2009-03-25 15:44:20.237288000 -0700
@@ -433,8 +433,15 @@
  * Failing this, I propose we just make the call and
  * ignore the return : its probably not a big deal
  */
+#ifdef __CYGWIN__
+if (isatty(fileno(stdin))) {
+if (setvbuf(stdout, (char *) NULL, _IOLBF, (size_t) 1024) != 0)
+(void) fputs("Could not linebuffer stdout\n", stderr);
+}
+#else
 if (setvbuf(stdout, (char *) NULL, _IOLBF, (size_t) 1024) != 0)
(void) fputs("Could not linebuffer stdout\n", stderr);
+#endif
 
 #ifdef X11
 /* This call used to be in x11.trm, with the following comment:
@@ -448,8 +455,14 @@
  * Do any non-X platforms suffer from the same problem?
  * EAM - Jan 2004.
  */
+#ifdef __CYGWIN__
+if (isatty(fileno(stdin))) {
+setvbuf(stdin, (char *) NULL, _IONBF, 0);
+}
+#else
 setvbuf(stdin, (char *) NULL, _IONBF, 0);
 #endif
+#endif
 
 #endif
 
--- origsrc/gnuplot-4.2.4/src/readline.c2008-08-09 17:50:29.0 
-0700
+++ src/gnuplot-4.2.4/src/readline.c2009-03-25 15:45:28.775841600 -0700
@@ -1020,7 +1020,13 @@
 #   endif  /* TERMIOS */
 #  endif   /* not SGTTY */
 # else /* OSK */
+#ifdef __CYGWIN__
+if (isatty(fileno(stdin))) {
+setbuf(stdin, (char *) 0); /* Make stdin and stdout unbuffered */
+}
+#else
setbuf(stdin, (char *) 0);  /* Make stdin and stdout unbuffered */
+#endif
setbuf(stderr, (char *) 0);
_gs_opt(STDIN, &new_settings);
 # endif/* OSK */
--- origsrc/gnuplot-4.2.4/src/variable.c2006-06-26 19:36:30.0 
-0700
+++ src/gnuplot-4.2.4/src/variable.c2009-03-25 15:33:20.198198400 -0700
@@ -262,6 +262,11 @@
 { "$`kpsexpand '$TEXMFMAIN'`/fonts/type1!" },
 { "$`kpsexpand '$TEXMFDIST'`/fonts/type1!" },
 #endif
+#ifdef __CYGWIN__
+/* teTeX in the cygwin distribution */
+{ "/usr/local/share/texmf/fonts/type1!" },
+{ "/usr/share/texmf/fonts/type1!" },
+#endif
 /* Linux paths */
 { "/usr/X11R6/lib/X11/fonts/Type1" },
 { "/usr/X11R6/lib/X11/fonts/truetype" },
@@ -270,6 +275,11 @@
 /* Ghostscript */
 { "/usr/share/ghostscript/fonts" },
 { "/usr/local/share/ghostscript/fonts" },
+#ifdef __CYGWIN__
+/* Misc. fonts */
+{ "/usr/local/share/fonts!" },
+{ "/usr/share/fonts!" },
+#endif
 { NULL }
 };
 #endif

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

Re: [ANNOUNCEMENT] Updated: gnuplot-4.2.4-1 - A command-line driven interactive function plotting utility.

[Jim Kleckner]

Dr. Volker Zell wrote:

Hi

A new version of 'gnuplot' has been uploaded to a server near you.
  


[snip]

Would you mind to consider including the patch documented here:
http://article.gmane.org/gmane.os.cygwin.applications/17023
and here:
http://cygwin.com/ml/cygwin-apps/2008-06/msg00102.html

Is that list the correct place to submit those kind of patches?

My recent upgrade caused me to rediscover this performance patch.
I didn't re-measure the effects, but it seems like much more than 2X 
speedup now.


Thanks.

--
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: File permissions not rx for group in /bin

[Jim Kleckner]

Corinna Vinschen wrote:

On Aug 17 23:07, Jim Kleckner wrote:
  

Larry Hall (Cygwin) wrote:


Jim Kleckner wrote:
  

I've read through the various permission documents
to find the explanation and tried Google without
figuring this one out.  Hopefully it is very simple.

I have an old cygwin install that I was upgrading
to the latest 1.5.  I find that the files in /bin
are mode 700 rather than 750 on my other installations.
The setup.exe is set to "All Users" although perhaps
some time in the dark past it might not have been.

This means that users other than the one installing
cygwin can't use it.  Is there some magic to make that
work properly?


Did you try "chmod 750 /bin"?
  

Uh, yeah.

chmod 750 /bin/* works at that moment, but any subsequent
installs/reinstalls cause reversion to 700.  So it is like swimming 
upstream.



Larry asked "Did you try "chmod 750 /bin"?"

Larry did not ask "Did you try "chmod 750 /bin/*"?
  


I have tried that and /bin does remain 750 but the /bin/* reverts to 700
on a reinstall.  (Presumably because /bin doesn't get removed whereas
/bin/* do).

Eventually it gets tiring.  getfacl.exe doesn't reveal anything 
particularly

enlightening.

It must be some weird inheritance of permissions thing in
Windows that doesn't exist on POSIX.  Quite a mystery though.



Setup doesn't know (yet) of real POSIX permissions.  It only uses the
Windows inheritance rules for permissions.  If you want POSIX
permissions automatically you have to make sure the parent dir has the
right set of permissions in its ACL.  I'm planning to add real
POSIX permission handling to setup for Cygwin 1.7, but it might not
be implemented soon.
  


NTFS has some truly complicated inheritance rules that
can muck things up.  I suspect that is what is happening
but their tools don't make it easy to see what is going on.



--
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: File permissions not rx for group in /bin

[Jim Kleckner]

Larry Hall (Cygwin) wrote:

Jim Kleckner wrote:

I've read through the various permission documents
to find the explanation and tried Google without
figuring this one out.  Hopefully it is very simple.

I have an old cygwin install that I was upgrading
to the latest 1.5.  I find that the files in /bin
are mode 700 rather than 750 on my other installations.
The setup.exe is set to "All Users" although perhaps
some time in the dark past it might not have been.

This means that users other than the one installing
cygwin can't use it.  Is there some magic to make that
work properly?


Did you try "chmod 750 /bin"?

Uh, yeah.

chmod 750 /bin/* works at that moment, but any subsequent
installs/reinstalls cause reversion to 700.  So it is like swimming 
upstream.

Eventually it gets tiring.  getfacl.exe doesn't reveal anything particularly
enlightening.

It must be some weird inheritance of permissions thing in
Windows that doesn't exist on POSIX.  Quite a mystery though.




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

File permissions not rx for group in /bin

[Jim Kleckner]

I've read through the various permission documents
to find the explanation and tried Google without
figuring this one out.  Hopefully it is very simple.

I have an old cygwin install that I was upgrading
to the latest 1.5.  I find that the files in /bin
are mode 700 rather than 750 on my other installations.
The setup.exe is set to "All Users" although perhaps
some time in the dark past it might not have been.

This means that users other than the one installing
cygwin can't use it.  Is there some magic to make that
work properly?

e.g. On the "bad" install you see permissions like this:
 -rwx--+ 1 jim Users 471040 May  3 06:26 /bin/bash.exe
and on the "good" install you see permissions like this:
 -rwxr-x---+ 1 jim Users 471040 May  3 06:26 /bin/bash.exe

My umask is 0022 on both.

cygcheck output is attached.

Thanks - Jim

Cygwin Configuration Diagnostics
Current System Time: Sun Aug 17 10:41:42 2008

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   c:\Jim\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\QuickTime\QTSystem\
c:\Program Files\vim\vim63
C:\cygwin\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1005(jim)  GID: 513(None)
513(None)   544(Administrators) 545(Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1005(jim)  GID: 513(None)
513(None)   544(Administrators) 545(Users)

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

PWD = '//mask2/jim/tmp'
HOME = '/cygdrive/c/Jim'

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

c:  hd  NTFS 57215Mb  50% CP CS UN PA FC 
e:  cd N/AN/A

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

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\cygwin\bin\find.exe
Not Found: gcc
Not Found: gdb
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Not Found: make
Found: C:\cygwin\bin\mv.exe
Not Found: patch
Found: C:\cygwin\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\ssh.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Found: c:\Program Files\vim\vim63\vim.exe
Found: C:\cygwin\bin\vim.exe

  103k 2007/09/16 C:\cygwin\bin\cygapr-1-0.dll
   70k 2007/09/16 C:\cygwin\bin\cygaprutil-1-0.dll
   61k 2008/04/01 C:\cygwin\bin\cygbz2-1.dll
7k 2006/10/22 C:\cygwin\bin\cygcharset-1.dll
  560k 2008/06/21 C:\cygwin\bin\cygclamav-4.dll
   42k 2008/06/21 C:\cygwin\bin\cygclamunrar-4.dll
8k 2008/06/21 C:\cygwin\bin\cygclamunrar_iface-4.dll
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll
  846k 2004/12/11 C:\cygwin\bin\cygcrypto-0.9.7.dll
 1057k 2008/06/09 C:\cygwin\bin\cygcrypto-0.9.8.dll
  194k 2007/06/30 C:\cygwin\bin\cygcurl-3.dll
  221k 2007/06/30 C:\cygwin\bin\cygcurl-4.dll
   22k 2004/02/10 C:\cygwin\bin\cygcygipc-2.dll
  703k 2007/12/17 C:\cygwin\bin\cygdb-4.2.dll
  943k 2007/12/17 C:\cygwin\bin\cygdb-4.5.dll
 1036k 2007/12/17 C:\cygwin\bin\cygdb_cxx-4.2.dll
 1296k 2007/12/17 C:\cygwin\bin\cygdb_cxx-4.5.dll
  118k 2007/04/06 C:\cygwin\bin\cygexpat-0.dll
  118k 2008/05/09 C:\cygwin\bin\cygexpat-1.dll
  161k 2007/03/28 C:\cygwin\bin\cygfontconfig-1.dll
   40k 2006/11/15 C:\cygwin\bin\cygform-8.dll
   45k 2001/04/25 C:\cygwin\bin\cygform5.dll
   35k 2002/01/09 C:\cygwin\bin\cygform6.dll
   48k 2003/08/09 C:\cygwin\bin\cygform7.dll
  462k 2007/05/31 C:\cygwin\bin\cygfreetype-6.dll
   28k 2003/07/20 C:\cygwin\bin\cyggdbm-3.dll
   

Re: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Thanks for running this.

René Berber wrote:

Jim Kleckner wrote:
[snip]
Would someone mind trying the following to see if you get the same 
behavior?

cd /usr/lib/python2.5/test
python testall.py
Observe that it hangs at "creating task 1".


Yes.  After a while of being idle threads go down from 11 to 9, but 
nothing else happens.



And (using bash):
cd /usr/lib/python2.5/test
python testall.py >& testall.out
and observe that test_wait4 fails.


Yes.  Testing finished, on the log I see a couple of tracebacks:

test_wait (test.test_wait4.Wait4Test) ... Traceback (most recent call 
last):

ERROR: test_wait (test.test_wait4.Wait4Test)
test test_wait4 failed -- Traceback (most recent call last):


I reinstalled cygwin to make sure I have 1.5.25-7.
I downloaded the source for Python and rebuilt it to see
if that would help.  Not surprisingly, it didn't.

It appears that Jason Tishler knows about these issues based on
the CYGWIN-PATCHES/README file:

As of Cygwin Python 2.4.3-1, the port has pthread-related issues that
cause some threading features to fail (at least occassionally).  AFAICT,
this is due to a change in the Cygwin DLL some time after 1.5.18.  See
the test section for more details.


[snip]


Under XP Pro SP2, Cygwin 1.5.24-2, ntsec, and NTFS, Cygwin Python passes
most normal (i.e., non "-u" option) tests.  Unfortunately, some of the
threading-related tests can cause the regression test to abort without
any error messages.  If one excludes these tests, then the regression
test will run to completion.  Additionally, if these tests are run
individually, then they will pass.


What is the best way to proceed with this?

It appears to have been a change since 1.5.18 if Jason's guess
is correct.

I can build a debug version of Python if that is useful.
I can build a debug version of cygwin if that is useful although
previous list comments suggest that it requires some deep
knowledge to do/use properly.

Brian mentioned in cygwin-patches list single-stepping python
using gdb to locate the previous pthread bug arising from
inconsistent headers.  How difficult is it do set that up?
What are the prerequisites?

As an off-topic side note, it sure would be nice to be
able to use valgrind just once on cygwin!

Thanks - Jim


--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

Dave Korn wrote:

On 26 January 2008 02:27, Jim Kleckner wrote:

 

...

  The two testcases I found in those threads (attached) both WJFFM under
cygwin 1.5.25-7 but fail under 1.5.23-2.  If you can reproduce that 
and your

program still fails, it's probably a different issue.
  


Thanks for giving that a try, Dave.

I restored 1.5.25-7 and confirmed that test_wait4 succeeds standalone.
Note that the test_wait4 test fails when run with:
   python testall.py >& testall.out
Note that it does make a difference if output is redirected.
If you type:
   python testall.py
then it hangs at the point of testing threads:
   *** Changing thread stack size ***
   caught expected ValueError setting stack_size(4096)
   successfully set stack_size(262144)
   successfully set stack_size(1048576)
   successfully set stack_size(0)
   trying stack_size = 262144
   creating task 1

Note the message from the test output that "verbose mode"
can influence the results:
 CAUTION:  stdout isn't compared in verbose mode:
 a test that passes in verbose mode may fail without it.

I would be curious if you also can reproduce this behavior.


Would someone mind trying the following to see if you get the same behavior?
cd /usr/lib/python2.5/test
python testall.py
Observe that it hangs at "creating task 1".

And (using bash):
cd /usr/lib/python2.5/test
python testall.py >& testall.out
and observe that test_wait4 fails.

...

Thanks - Jim

--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Dave Korn wrote:

On 26 January 2008 02:27, Jim Kleckner wrote:

  

Thanks for providing a testcase.  Should be fixed in CVS:
<http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html>
  

I have a python application that works fine
on Linux and Mac but fails with Cygwin.

I tried using snapshot:
 cygwin-inst-20080122.tar.bz2
but it still fails.  (In addition, stdout appears to not get flushed in
that snapshot).



  That's presumably a snapshot of 1.7.0, which is pretty work-in-progressy at
the moment?

  

Yes, but I thought I would pre-empt the "did you try a snapshot" question ;)

Is it the case that the patch to the header
file requires the recompilation of applications
and libraries that use threading to make them work?

See these messages for context:
 http://cygwin.com/ml/cygwin/2007-09/msg00120.html
 http://cygwin.com/ml/cygwin/2006-12/msg00451.html
 http://cygwin.com/ml/cygwin/2006-05/msg00125.html



  The two testcases I found in those threads (attached) both WJFFM under
cygwin 1.5.25-7 but fail under 1.5.23-2.  If you can reproduce that and your
program still fails, it's probably a different issue.
  


Thanks for giving that a try, Dave.

I restored 1.5.25-7 and confirmed that test_wait4 succeeds standalone.
Note that the test_wait4 test fails when run with:
   python testall.py >& testall.out
Note that it does make a difference if output is redirected.
If you type:
   python testall.py
then it hangs at the point of testing threads:
   *** Changing thread stack size ***
   caught expected ValueError setting stack_size(4096)
   successfully set stack_size(262144)
   successfully set stack_size(1048576)
   successfully set stack_size(0)
   trying stack_size = 262144
   creating task 1

Note the message from the test output that "verbose mode"
can influence the results:
 CAUTION:  stdout isn't compared in verbose mode:
 a test that passes in verbose mode may fail without it.

I would be curious if you also can reproduce this behavior.


The reason that threading is implicated is that the code
just exits mysteriously when several Lock objects are created.
In this code snippet below, commenting out the third lock creation
allows it to run further (but fail later).  In fact, commenting out any
one of the three lock object initializers will allow it to go further.
On the third lock creation it just returns to the shell prompt.

   self.m_queue = Queue.Queue()
   # State variables:
   self.m_listening = 0
   self.m_random= 0
   self.m_guiLock   = threading.Lock()
   if self.m_debug > 0: print "Listener: thread gui lock:", 
self.m_guiLock

   self.m_startLock = threading.Lock()
   if self.m_debug > 0: print "Listener: thread start lock:", 
self.m_startLock

   # Commenting out this line allows the execution to go further:
   self.m_randLock  = threading.Lock()
  #self.m_randLock  = None
   if self.m_debug > 0: print "Listener: thread rand lock:", 
self.m_randLock


The obvious ex-vivo test of creating some Queues and Locks succeeds.
I also tried just adding some threading.Lock() creations to "foo2.py"
but that wasn't enough to cause the problem.

This is particularly hard to debug because it doesn't give error messages
or things to manipulate.  It just "goes away".

I can try some single-stepping in GDB if someone has a recipe to follow.
Suggestions?

For now, I just don't run the application on Cygwin...


--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Brian Dessent wrote:

Jim Kleckner wrote:

Running it with idle does give the exception dialog.

I can't seem to grab hold of anything to get a traceback.
Suggestions?



Thanks for providing a testcase.  Should be fixed in CVS:
<http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html>


I have a python application that works fine
on Linux and Mac but fails with Cygwin.

I tried using snapshot:
cygwin-inst-20080122.tar.bz2
but it still fails.  (In addition, stdout appears to not get flushed in
that snapshot).

Is it the case that the patch to the header
file requires the recompilation of applications
and libraries that use threading to make them work?

See these messages for context:
http://cygwin.com/ml/cygwin/2007-09/msg00120.html
http://cygwin.com/ml/cygwin/2006-12/msg00451.html
http://cygwin.com/ml/cygwin/2006-05/msg00125.html

Thanks - Jim

Note that there was a suspicious python test failure
for test_wait4 with os.getpid() failing, but this may
be unrelated.

=== /usr/lib/python2.5/test/testall.py partial output:

test_wait4
Unhandled exception in thread started by >

test_wait (test.test_wait4.Wait4Test) ... Traceback (most recent call last):
 File "./fork_wait.py", line 30, in f
   self.alive[id] = os.getpid()
AttributeError: 'NoneType' object has no attribute 'getpid'
Unhandled exception in thread started by >

Traceback (most recent call last):
 File "./fork_wait.py", line 30, in f
   self.alive[id] = os.getpid()
AttributeError: 'NoneType' object has no attribute 'getpid'
Unhandled exception in thread started by >

Traceback (most recent call last):
 File "./fork_wait.py", line 30, in f
   self.alive[id] = os.getpid()
AttributeError: 'NoneType' object has no attribute 'getpid'
Unhandled exception in thread started by >

Traceback (most recent call last):
 File "./fork_wait.py", line 30, in f
   self.alive[id] = os.getpid()
AttributeError: 'NoneType' object has no attribute 'getpid'
FAIL

==
FAIL: test_wait (test.test_wait4.Wait4Test)
--
Traceback (most recent call last):
 File "/tmp/python.6884/usr/lib/python2.5/test/fork_wait.py", line 75, 
in test_wait

   self.wait_impl(cpid)
 File "/tmp/python.6884/usr/lib/python2.5/test/test_wait4.py", line 29, 
in wait_impl
   self.assertEqual(status, 0, "cause = %d, exit = %d" % (status&0xff, 
status>>8))

AssertionError: cause = 6, exit = 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/

Re: screen reattach not working under ssh?

[Jim Kleckner]

Damjan Lango wrote:

I'm still having problems with reattaching screen under ssh sessions.
Does it work to anybody at all? ssh + screen + vista anyone?
sigh :(


I have had some success using vista 64 bit.  Not frequently used, though.

Jim

--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

Jim Kleckner wrote:

I tried running
/lib/python2.5/test/test_thread.py
and it hangs at the line below:

*** Changing thread stack size ***
caught expected ValueError setting stack_size(4096)
successfully set stack_size(262144)
successfully set stack_size(1048576)
successfully set stack_size(0)
trying stack_size = 262144
creating task 1


Hm.  Redirecting output from test_thread.py lets it complete.
python test_thread.py >& /tmp/t
python testall.py redirected completes but hangs in same spot
if not redirected.

This is all using today's snapshot.


And of course using strace causes it to run to completion
even when not redirected.

--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

Jim Kleckner wrote:

I tried running
/lib/python2.5/test/test_thread.py
and it hangs at the line below:

*** Changing thread stack size ***
caught expected ValueError setting stack_size(4096)
successfully set stack_size(262144)
successfully set stack_size(1048576)
successfully set stack_size(0)
trying stack_size = 262144
creating task 1


Hm.  Redirecting output from test_thread.py lets it complete.
python test_thread.py >& /tmp/t
python testall.py redirected completes but hangs in same spot
if not redirected.

This is all using today's snapshot.


And of course using strace causes it to run to completion.

--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

Jim Kleckner wrote:

I tried running
/lib/python2.5/test/test_thread.py
and it hangs at the line below:

*** Changing thread stack size ***
caught expected ValueError setting stack_size(4096)
successfully set stack_size(262144)
successfully set stack_size(1048576)
successfully set stack_size(0)
trying stack_size = 262144
creating task 1


Hm.  Redirecting output from test_thread.py lets it complete.
python test_thread.py >& /tmp/t
python testall.py redirected completes but hangs in same spot
if not redirected.

This is all using today's snapshot.


Brian, you mentioned that you detected the other problem
with single-stepping in GDB.  Would you be able to
publish the setup steps to enable me/others to find
this sort of problem?

It seems likely that the problem is in cygwin since the
test passes with redirection and works in the stock
Python25 distro.  Potentially similar to the other thread
issue you found?

Thanks - Jim

--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

I tried running
/lib/python2.5/test/test_thread.py
and it hangs at the line below:

*** Changing thread stack size ***
caught expected ValueError setting stack_size(4096)
successfully set stack_size(262144)
successfully set stack_size(1048576)
successfully set stack_size(0)
trying stack_size = 262144
creating task 1


Hm.  Redirecting output from test_thread.py lets it complete.
python test_thread.py >& /tmp/t
python testall.py redirected completes but hangs in same spot
if not redirected.

This is all using today's snapshot.



--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

 Brian Dessent wrote:

Jim Kleckner wrote:
 

Running it with idle does give the exception dialog.

I can't seem to grab hold of anything to get a traceback.
Suggestions?



Thanks for providing a testcase.  Should be fixed in CVS:
<http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html>
  


Before I further debug my other code that stopped working,
is it possible that more than just cygwin1.dll is affected by this
include file inconsistency and need to be recompiled?
In order to track down why it doesn't work, it might be
useful to have that patch in a 1.5.24-based dll snapshot
to isolate whether the remaining issues are introduced post
1.5.24 or not.  I suspect that isn't too convenient though.


I tried the running
/lib/python2.5/test/test_thread.py
and it hangs at the line below:

*** Changing thread stack size ***
caught expected ValueError setting stack_size(4096)
successfully set stack_size(262144)
successfully set stack_size(1048576)
successfully set stack_size(0)
trying stack_size = 262144
creating task 1


--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

 Brian Dessent wrote:

Jim Kleckner wrote:
  

Running it with idle does give the exception dialog.

I can't seem to grab hold of anything to get a traceback.
Suggestions?



Thanks for providing a testcase.  Should be fixed in CVS:
<http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html>
  


Before I further debug my other code that stopped working,
is it possible that more than just cygwin1.dll is affected by this
include file inconsistency and need to be recompiled?
In order to track down why it doesn't work, it might be
useful to have that patch in a 1.5.24-based dll snapshot
to isolate whether the remaining issues are introduced post
1.5.24 or not.  I suspect that isn't too convenient though.



--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Christopher Faylor wrote:

On Thu, Sep 06, 2007 at 12:01:25PM -0700, Brian Dessent wrote:
  

Jim Kleckner wrote:


Running it with idle does give the exception dialog.

I can't seem to grab hold of anything to get a traceback.
Suggestions?
  

Thanks for providing a testcase.  Should be fixed in CVS:
<http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html>



I'm generating a snapshot now, too.

Thanks very much for tracking this down Brian.  This is how free
software is supposed to work!
  


Yes, thanks!

I can confirm that the snapshot makes the test case run on my machine.

Jim

--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

Larry Hall (Cygwin) wrote:

Steve Holden wrote:

Igor Peshansky wrote:

On Wed, 5 Sep 2007, Steve Holden wrote:

Running the example on the above Python system I just see the 
command

prompt return with no program output whatsoever:

[EMAIL PROTECTED] ~/Projects/Python
$ /usr/bin/python test03.py

So it fails, but doesn't bring up the exception dialog.
That's right: nothing at all. But note I compiled this particular 
version

myself, so I guess it's possible I didn't enable threads.


What's the exit code?  The behavior sounds suspiciously like a 
missing DLL

case...


[EMAIL PROTECTED] ~/Projects/Python
$ /usr/bin/python test03.py

[EMAIL PROTECTED] ~/Projects/Python
$ echo $?
0

So, what does this tell us?



Everything is just perfect! ;-)

The value would be non-zero if it couldn't find a needed DLL.




I also get 0 exit code even though there is a dialog box with the
application error codes mentioned before.

[EMAIL PROTECTED] ~]$ python aspn-threading-tkinter.py
[EMAIL PROTECTED] ~]$ echo $?
0
[EMAIL PROTECTED] ~]$


Ok, so I downloaded the python source and built a debug version
with:
export EXTRA_CFLAGS="-DPy_DEBUG -DPy_REF_DEBUG -DPy_TRACE_REFS 
-DPYMALLOC_DEBUG -DCOUNT_ALLOCS"

./configure --with-pydebug --prefix=$Prefix --mandir='${prefix}/share/man'

Now I run the example and similar to Steve it just exits with no dialog box.
With some extra print statements, it seems to disappear at the line:
self.master.after(100, self.periodicCall)

Running this under gdb gives:

(gdb) run aspn-threading-tkinter.py
Starting program: /usr/bin/python.exe aspn-threading-tkinter.py
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/libpython2.5.dll

Program exited with code 0305.
(gdb)

Running it with idle does give the exception dialog.

I can't seem to grab hold of anything to get a traceback.
Suggestions?
# From http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965
"""
This recipe describes how to handle asynchronous I/O in an environment where
you are running Tkinter as the graphical user interface. Tkinter is safe
to use as long as all the graphics commands are handled in a single thread.
Since it is more efficient to make I/O channels to block and wait for something
to happen rather than poll at regular intervals, we want I/O to be handled
in separate threads. These can communicate in a threasafe way with the main,
GUI-oriented process through one or several queues. In this solution the GUI
still has to make a poll at a reasonable interval, to check if there is
something in the queue that needs processing. Other solutions are possible,
but they add a lot of complexity to the application.

Created by Jacob Hall?n, AB Strakt, Sweden. 2001-10-17
"""
import Tkinter
import time
import threading
import random
import Queue

class GuiPart:
def __init__(self, master, queue, endCommand):
self.queue = queue
# Set up the GUI
console = Tkinter.Button(master, text='Done', command=endCommand)
console.pack()
# Add more GUI stuff here

def processIncoming(self):
"""
Handle all the messages currently in the queue (if any).
"""
while self.queue.qsize():
try:
msg = self.queue.get(0)
# Check contents of message and do what it says
# As a test, we simply print it
print msg
except Queue.Empty:
pass
print "done processIncoming"

class ThreadedClient:
"""
Launch the main part of the GUI and the worker thread. periodicCall and
endApplication could reside in the GUI part, but putting them here
means that you have all the thread controls in a single place.
"""
def __init__(self, master):
"""
Start the GUI and the asynchronous threads. We are in the main
(original) thread of the application, which will later be used by
the GUI. We spawn a new thread for the worker.
"""
print "__init__"
self.master = master

# Create the queue
print "Queue"
self.queue = Queue.Queue()

# Set up the GUI part
print "GuiPart"
self.gui = GuiPart(master, self.queue, self.endApplication)

# Set up the thread to do asynchronous I/O
# More can be made if necessary
self.running = 1
print "running"
self.thread1 = threading.Thread(target=self.workerThread1)
self.thr

Re: Help needed with Big List of Dodgy Apps

[Jim Kleckner]

Dave Korn wrote:

  These sorts of problems (cpu usage pegged at 100%, or mysterious hangs or 
fork failures) are often caused by buggy versions of antivirus, antispyware, 
personal firewall, or other similar security or system-related software that 
hooks into every running process and - because it doesn't hook in completely 
transparently - affects the behaviour of the operating system calls that cygwin 
relies on to work.

  I'm adding code to cygcheck to detect whether any of the software that has 
been known at some time to cause these kinds of problems are installed on the 
target system being cygchecked.  The way it detects whether the software is 
there or not is by looking for keys in the registry, files and directories on 
disk, or running processes or loaded DLLs in memory, that would indicate that 
one of the problematic applications is installed.  But I can't do it all 
myself, because I don't have any access to most of the software that has been 
reported to cause problems in the past.
  


Do you think a "tester" for API sanity is possible?
i.e. make some known good calls and assert their return values or some such.
Is there a common way that the badly designed hooking dlls cause problems
or is each one quite different?




--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Larry Hall (Cygwin) wrote:

Steve Holden wrote:

Igor Peshansky wrote:

On Wed, 5 Sep 2007, Steve Holden wrote:

Running the example on the above Python system I just see the 
command

prompt return with no program output whatsoever:

[EMAIL PROTECTED] ~/Projects/Python
$ /usr/bin/python test03.py

So it fails, but doesn't bring up the exception dialog.
That's right: nothing at all. But note I compiled this particular 
version

myself, so I guess it's possible I didn't enable threads.


What's the exit code?  The behavior sounds suspiciously like a 
missing DLL

case...


[EMAIL PROTECTED] ~/Projects/Python
$ /usr/bin/python test03.py

[EMAIL PROTECTED] ~/Projects/Python
$ echo $?
0

So, what does this tell us?



Everything is just perfect! ;-)

The value would be non-zero if it couldn't find a needed DLL.




I also get 0 exit code even though there is a dialog box with the
application error codes mentioned before.

[EMAIL PROTECTED] ~]$ python aspn-threading-tkinter.py
[EMAIL PROTECTED] ~]$ echo $?
0
[EMAIL PROTECTED] ~]$


--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Steve Holden wrote:

Jim Kleckner wrote:

Jim Kleckner wrote:

I get an exception running a Python example that uses threads
that I downloaded from the net (ASPN):
  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965


Would some kind soul try the example and let me know that it
does/doesn't work for you?  Setting debug print around the
code suggests that the third Lock object created causes the
exception.

Thanks - Jim



Not sure this is going to help ...

$ /usr/bin/python
Python 2.5.1 (r251:54863, Aug 30 2007, 08:07:01)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

Running the example on the above Python system I just see the command 
prompt return with no program output whatsoever:


[EMAIL PROTECTED] ~/Projects/Python
$ /usr/bin/python test03.py


So it fails, but doesn't bring up the exception dialog.




[EMAIL PROTECTED] ~/Projects/Python
$

Under a standard Windows 2.5.1 it created a window then appeared to 
print random times until I clicked the "Done" button:


C:\Steve\Projects\Python>python test0
0.303836168441
0.98021967508
0.254334126577
...

Yep, that's what it should do.

Thanks for checking.

Jim

--
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: Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Jim Kleckner wrote:

I get an exception running a Python example that uses threads
that I downloaded from the net (ASPN):
  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965


Would some kind soul try the example and let me know that it
does/doesn't work for you?  Setting debug print around the
code suggests that the third Lock object created causes the
exception.

Thanks - Jim

--
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.24: sshd immediately disconnects upon receiving a connection

[Jim Kleckner]

Jeremy K. Truax wrote:

So as I said in the last message for this thread, I was able to get sshd
fully working by uninstalling the antivirus.

In case anyone else is using NOD32 for antivirus (www.eset.com), it has a
special service called IMON (Internet monitor) that seems to be pretty
picky on what kinds of sockets can be accepted and it didn't like something
about the way sshd was generating socket connections so it was blocking
them. I was able to reinstall the antivirus and simply add exclusions for
cygrunsrv.exe and sshd.exe in the IMON portion of NOD32.

Now the fun beginsthis was all on Windows XP SP2...everything worked.
Well the laptop was shipped with Vista and not all the drivers could be
found for XP so we were forced to switch the laptop back to Vista. We had
previously downgraded to XP thinking that might be part of the
problemwell we were partially right.

My current issue is that the Cygwin sshd service refuses to stay running
(similar to before) but manually starting up sshd (like in the past couple
messages) works correctly and I am able to connect.

Windows firewall and defender are shut off, NOD32 is fully uninstalled at
this point still. 


The event viewer shows an error log:

Log Name:  Application
Source:Application Error
Date:  9/5/2007 10:18:58 AM
Event ID:  1000
Task Category: (100)
Level: Error
Keywords:  Classic
User:  N/A
Computer:  AVILA
Description:
Faulting application cygrunsrv.exe, version 0.0.0.0, time stamp 0x449671dc,
faulting module cygwin1.dll, version 1005.24.0.0, time stamp 0x45c06855,
exception code 0xc005, fault offset 0x000de9a1, process id 0xcdc,
application start time 0x01c7efe0d7a0b98b.


Anyone else possibly run into problems running sshd as a service under
Vista? But it working fine when starting it up manually?
  


On that same machine, I tried removing cygwin and reinstalling
the base packages.  Although you can get a cygwin.bat to run,
each of the postinstall scripts gives an error when run.  So it
is not likely that it is a "clean" install.  Has anyone seen these
kinds of errors in /var/log/setup.log.full ?

I've tried a host of chmod 777 and chgrp Users and chgrp Administrators
attempts but always seem to get the bash.exe.stackdump in /

Could this be a result of using RDP and remote sessions?
Could it be that it is a dual core AMD?
I don't have direct access to the computer (2 hours by plane).

Thanks - Jim


===
2007/09/05 16:41:02 Starting cygwin install, version 2.573.2.2
...
2007/09/05 16:42:05 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/terminfo.sh
16 [unknown (0xC90)] bash 3692 _cygtls::handle_exceptions: 
Exception: STATUS_ACCESS_VIOLATION
227131 [unknown (0xC90)] bash 3692 open_stackdumpfile: Dumping stack 
trace to bash.exe.stackdump

2007/09/05 16:42:16 abnormal exit: exit code=35584
2007/09/05 16:42:16 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/00bash.sh
 6 [unknown (0xE18)] bash 3680 _cygtls::handle_exceptions: 
Exception: STATUS_ACCESS_VIOLATION
124434 [unknown (0xE18)] bash 3680 open_stackdumpfile: Dumping stack 
trace to bash.exe.stackdump

2007/09/05 16:42:22 abnormal exit: exit code=35584

2007/09/05 16:41:02 Starting cygwin install, version 2.573.2.2
...
2007/09/05 16:42:05 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/terminfo.sh
 16 [unknown (0xC90)] bash 3692 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
 227131 [unknown (0xC90)] bash 3692 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/09/05 16:42:16 abnormal exit: exit code=35584
2007/09/05 16:42:16 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/00bash.sh
  6 [unknown (0xE18)] bash 3680 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
 124434 [unknown (0xE18)] bash 3680 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/09/05 16:42:22 abnormal exit: exit code=35584
2007/09/05 16:42:22 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/passwd-grp.sh
  5 [unknown (0xD64)] bash 4084 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  20622 [unknown (0xD64)] bash 4084 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/09/05 16:42:32 abnormal exit: exit code=35584
2007/09/05 16:42:32 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/00ash.sh
  6 [unknown (0xAF4)] bash 2416 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  38473 [unknown (0xAF4)] bash 2416 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/09/05 16:42:39 abnormal exit: exit code=35584
2007/09/05 16:42:39 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/coreutils.sh
  5 [unknown (0xA00)] bash 3852 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  54338 [unknown (0xA00)] bash 3852 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/09/05 16:42:47 abnormal exit: exit code=35584
2007/09/05 16:42:47 running: C:\cygwin\bin\bash.exe 

Re: Full reinstall now fails with Vista STATUS_ACCESS_VIOLATION during postinstall

[Jim Kleckner]

Dave Korn wrote:

On 29 August 2007 01:05, Jim Kleckner wrote:
  
  It could be a NOD32 issue, to judge by the trouble it's been causing

elsewhere today:

http://cygwin.com/ml/cygwin/2007-08/msg00824.html
[and http://cygwin.com/ml/cygwin/2007-08/msg00800.html ]

  Looks like you'd need to try actually uninstalling it before you can be sure
whether it's the cause of the problem or not.
  


Yes indeed.  In fact it was the same computer :)

Hopefully, Jeremy will post the details on how he figured out how to
configure IMON / NOD32 to get it to play nice.

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

Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

I get an exception running a Python example that uses threads
that I downloaded from the net (ASPN):
  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965

This may just be another case of "threading doesn't work well".
I'm including the test case.

It fails with cygwin Python with a dialog that says:
  The instruction as "0x01" referenced memory at "0x".
  The memory could not be "written".

gdb doesn't seem to give any enlightenment.

Would someone mind giving this example a try and, if it works for you
on a current cygwin, post back to the list?  If so, I'll include
cygcheck output.

This is the version that is failing:

Cygwin current Python:
  Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
  [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin

Here are configurations that aspn.py does work:

Stock 2.4 Windows Python:
  Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] 
on win32


Stock 2.5 Windows Python:
  Microsoft Windows XP [Version 5.1.2600]
  Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit 
(Intel)] on win32


Ubuntu Dapper:
  Python 2.4.3 (#2, Oct  6 2006, 07:52:30)
  [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

Ubuntu Edgy:
  Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
  [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2

# From http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965
"""
This recipe describes how to handle asynchronous I/O in an environment where
you are running Tkinter as the graphical user interface. Tkinter is safe
to use as long as all the graphics commands are handled in a single thread.
Since it is more efficient to make I/O channels to block and wait for something
to happen rather than poll at regular intervals, we want I/O to be handled
in separate threads. These can communicate in a threasafe way with the main,
GUI-oriented process through one or several queues. In this solution the GUI
still has to make a poll at a reasonable interval, to check if there is
something in the queue that needs processing. Other solutions are possible,
but they add a lot of complexity to the application.

Created by Jacob Hall?n, AB Strakt, Sweden. 2001-10-17
"""
import Tkinter
import time
import threading
import random
import Queue

class GuiPart:
def __init__(self, master, queue, endCommand):
self.queue = queue
# Set up the GUI
console = Tkinter.Button(master, text='Done', command=endCommand)
console.pack()
# Add more GUI stuff here

def processIncoming(self):
"""
Handle all the messages currently in the queue (if any).
"""
while self.queue.qsize():
try:
msg = self.queue.get(0)
# Check contents of message and do what it says
# As a test, we simply print it
print msg
except Queue.Empty:
pass

class ThreadedClient:
"""
Launch the main part of the GUI and the worker thread. periodicCall and
endApplication could reside in the GUI part, but putting them here
means that you have all the thread controls in a single place.
"""
def __init__(self, master):
"""
Start the GUI and the asynchronous threads. We are in the main
(original) thread of the application, which will later be used by
the GUI. We spawn a new thread for the worker.
"""
self.master = master

# Create the queue
self.queue = Queue.Queue()

# Set up the GUI part
self.gui = GuiPart(master, self.queue, self.endApplication)

# Set up the thread to do asynchronous I/O
# More can be made if necessary
self.running = 1
self.thread1 = threading.Thread(target=self.workerThread1)
self.thread1.start()

# Start the periodic call in the GUI to check if the queue contains
# anything
self.periodicCall()

def periodicCall(self):
"""
Check every 100 ms if there is something new in the queue.
"""
self.gui.processIncoming()
if not self.running:
# This is the brutal stop of the system. You may want to do
# some cleanup before actually shutting it down.
import sys
sys.exit(1)
self.master.after(100, self.periodicCall)

def workerThread1(self):
"""
This is where we handle the asynchronous I/O. For example, it may be
a 'select()'.
One important thing to remember is that the thread has to yield
control.
"""
while self.running:
# To simulate asynchronous I/O, we create a random number at
# random intervals. Replace the following 2 lines with the real
# thing.
time.sleep(rand.random() * 0.3)
msg = rand.random()
self.queue.put(msg)

def endApplication(self):
self.runni

Re: Full reinstall now fails with Vista STATUS_ACCESS_VIOLATION during postinstall

[Jim Kleckner]

Jim Kleckner wrote:

In trying to figure out what was going on with Vista Business,
I removed all of cygwin and reinstalled, first as me with
administrator privileges and then with "run as administrator".
In all cases, the postinstall scripts all fail with lines like:


I've given up on Vista and told the owner of the computer to scrape it
and put Win XP onto it.

Here's hoping that helps...

Jim

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

Full reinstall now fails with Vista STATUS_ACCESS_VIOLATION during postinstall

[Jim Kleckner]

In trying to figure out what was going on with Vista Business,
I removed all of cygwin and reinstalled, first as me with
administrator privileges and then with "run as administrator".
In all cases, the postinstall scripts all fail with lines like:

  6 [unknown (0x890)] bash 3248 _cygtls::handle_exceptions: 
Exception: STATUS_ACCESS_VIOLATION
 301469 [unknown (0x890)] bash 3248 open_stackdumpfile: Dumping stack 
trace to bash.exe.stackdump

2007/08/28 16:31:16 abnormal exit: exit code=35584

I turned off NOD32 and Defender first.

It had worked for a little time and now I can't seem to resurrect it.
The cygcheck output is attached.

Is this a dual-core issue?


Thanks.

2007/08/28 16:31:07 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/terminfo.sh
  6 [unknown (0x890)] bash 3248 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
 301469 [unknown (0x890)] bash 3248 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:16 abnormal exit: exit code=35584
2007/08/28 16:31:16 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/update-info-dir.sh
  5 [unknown (0xE80)] bash 1444 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  13361 [unknown (0xE80)] bash 1444 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:23 abnormal exit: exit code=35584
2007/08/28 16:31:23 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/00bash.sh
 15 [unknown (0xDF4)] bash 4012 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  18023 [unknown (0xDF4)] bash 4012 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:29 abnormal exit: exit code=35584
2007/08/28 16:31:29 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/passwd-grp.sh
  6 [unknown (0xFB0)] bash 3372 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  17823 [unknown (0xFB0)] bash 3372 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:34 abnormal exit: exit code=35584
2007/08/28 16:31:34 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/00ash.sh
  6 [unknown (0xCE4)] bash 1236 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  29048 [unknown (0xCE4)] bash 1236 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:41 abnormal exit: exit code=35584
2007/08/28 16:31:41 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/coreutils.sh
  5 [unknown (0xB04)] bash 1444 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  17646 [unknown (0xB04)] bash 1444 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:47 abnormal exit: exit code=35584
2007/08/28 16:31:47 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/findutils.sh
  5 [unknown (0xDAC)] bash 3720 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  17297 [unknown (0xDAC)] bash 3720 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:52 abnormal exit: exit code=35584
2007/08/28 16:31:52 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/base-files-mketc.sh
  5 [unknown (0xE38)] bash 2648 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
   7602 [unknown (0xE38)] bash 2648 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:31:58 abnormal exit: exit code=35584
2007/08/28 16:31:58 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/base-files-profile.sh
  6 [unknown (0x6E0)] bash 3464 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  22355 [unknown (0x6E0)] bash 3464 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:32:04 abnormal exit: exit code=35584
2007/08/28 16:32:04 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/bzip2.sh
  6 [unknown (0xFFC)] bash 1288 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  20910 [unknown (0xFFC)] bash 1288 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:32:09 abnormal exit: exit code=35584
2007/08/28 16:32:09 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/man.sh
  5 [unknown (0x554)] bash 4044 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  16673 [unknown (0x554)] bash 4044 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:32:15 abnormal exit: exit code=35584
2007/08/28 16:32:15 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/cygwin-doc.sh
  5 [unknown (0xA58)] bash 3300 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  17462 [unknown (0xA58)] bash 3300 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
2007/08/28 16:32:21 abnormal exit: exit code=35584
2007/08/28 16:32:21 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/tar.sh
  5 [unknown (0x818)] bash 3692 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
  10518 [unknown (0x818)] bash 3692 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
20

Re: sshd and vista / business

[Jim Kleckner]

Jim Kleckner wrote:

I've had various luck with getting sshd working with Vista.
Today, it was working for a while and then after some patch
updates stopped.  Nothing seems to want to get it working again.


The event log says this:

  sshd: PID 2532: fatal: recv_rexec_state: ssh_msg_recv failed

Connections to port 22 do work, though.

--
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: sshd and vista / business

[Jim Kleckner]

Jim Kleckner wrote:

I've had various luck with getting sshd working with Vista.
Today, it was working for a while and then after some patch
updates stopped.  Nothing seems to want to get it working again.



The event log says this:

 sshd: PID 2532: fatal: recv_rexec_state: ssh_msg_recv failed

Connections to port 22 do work, though so it isn't a firewall issue
(which is turned off for this testing).



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

sshd and vista / business

[Jim Kleckner]

I've had various luck with getting sshd working with Vista.
Today, it was working for a while and then after some patch
updates stopped.  Nothing seems to want to get it working again.

I verified passwd and groups are identical to the output of mkpasswd
and mkgroup.  I verified that all directories are readable by
sshd_server (priv sep and) up to .ssh and that .ssh is not writeable.
I made sure that /var/empty is readable by sshd_server and not writeable 
by others.  Made sure that /var/log/sshd.log is writeable by sshd_server.


I confirmed in the registry that CYGWIN is set to "ntsec binmode tty".
I tried rebaseall and turning off every service that seemed optional.
I confirmed that there is no logitech web cam.

What have I missed?

Thanks - Jim


ssh -v -v -v localhost
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /home/jkleckner/.ssh/config
debug1: /home/jkleckner/.ssh/config line 1: Deprecated option 
"FallBackToRsh"

debug1: /home/jkleckner/.ssh/config line 3: Deprecated option "UseRsh"
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/jkleckner/.ssh/identity type 0
debug1: identity file /home/jkleckner/.ssh/id_rsa type -1
debug1: identity file /home/jkleckner/.ssh/id_dsa type -1
ssh_exchange_identification: read: Software caused connection abort


Cygwin Configuration Diagnostics
Current System Time: Mon Aug 27 22:19:58 2007

Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6000 

Running in Terminal Service session

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Windows\system32
c:\Windows
c:\Windows\System32\Wbem
c:\Program Files\ZipGenius 6\
C:\cygwin\lib\lapack

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'jkleckner'
PWD = '/etc'
HOME = '/home/jkleckner'
MAKE_MODE = 'unix'

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

c:  hd  NTFS144247Mb  56% CP CS UN PA FC 
d:  hd  NTFS  8377Mb  79% CP CS UN PA FC HP_RECOVERY
e:  cd N/AN/A

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

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
Not Found: crontab
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\patch.exe
Found: C:\cygwin\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\ssh.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Found: C:\cygwin\bin\vim.exe

  103k 2007/04/06 C:\cygwin\bin\cygapr-1-0.dll
   70k 2007/03/23 C:\cygwin\bin\cygaprutil-1-0.dll
   61k 2006/11/10 C:\cygwin\bin\cygbz2-1.dll
7k 2006/10/22 C:\cygwin\bin\cygcharset-1.dll
   23k 2006/05/08 C:\cygwin\bin\cygcheck-0.dll
  443k 2007/03/06 C:\cygwin\bin\cygclamav-2.dll
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll
 1059k 2007/03/29 C:\cygwin\bin\cygcrypto-0.9.8.dll
  194k 2006/06/12 C:\cygwin\bin\cygcurl-3.dll
   22k 2004/02/10 C:\cygwin\bin\cygcygipc-2.dll
  895k 2004/04/28 C:\cygwin\bin\cygdb-4.2.dll
  965k 2005/05/14 C:\cygwin\bin\cygdb-4.3.dll
 1156k 2004/04/28 C:\cygwin\bin\cygdb_cxx-4.2.dll
 1240k 2005/05/14 C:\cygwin\bin\cygdb_cxx-4.3.dll
  118k 2007/04/06 C:\cygwin\bin\cygexpat-0.dll
  161k 2007/03/28 C:\cygwin\bin\cygfontconfig-1.dll
   40k 2006/11/15 C:\cygwin\bin\cygform-8.dll
   45k 2001/04/25 C:\cygwin\bin\cygform5.dll
   35k 2002/01/09 C:\cygwin\bin\cygform6.dll
   48k 2003/08/09 C:\cygwin\bin\cygform7.dll
  375k 2005/09/06 C:\cygwin\bin\cygfreetype-6.dll
  225k 2007/04/04 C:\cygwin\bin\cyggd-2.dl

Approximate timetable for next cygwin version?

[Jim Kleckner]

Corinna Vinschen wrote:

You'll have to live with the behaviour in 1.5.24 then for some time.
There won't be any bug fixing to 1.5.24 anymore.  The next version will
be a major, major, MAJOR update with lots of changes, not only in socket
code.


Just curious when you think the new version will be ready for the masses 
to test?


--
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: Setup.exe Problems on Vista

[Jim Kleckner]

Brian Dessent wrote:

"Michael D. Adams" wrote:

he workaround for this problem that I have found is to set the
*Windows* path to include C:\cygwin\bin before running setup.exe.  So
for example this sequence works:

set PATH=C:\cygwin\bin;%PATH%
setup.exe

Then /bin/sh is actually created, the prompt is the usual Cygwin settings, etc.
Of course the proper solution would be to find and fix the root cause.
 Is this a known bug?  Is there any other info I can provide to help
find the root cause? (I'm suspicious that Vista might not allow the
program to set PATH.)



That would be pretty brain dead if Vista did not allow programs to
modify the PATH.  That would cause about a million failures in Cygwin
and various programs.
  


FYI, adding c:\cygwin\bin at the end of the windows global environment
PATH variable fixed an annoying issue that "cystart --explore ." wouldn't
work for me on Vista (64bit).

It was very minor but I suspect this symptom and workaround suggest 
something deeper.


Jim




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

Re: cygwin and svn on Windows Vista

[Jim Kleckner]

Benoit Miller wrote:

Corinna Vinschen wrote:

On Feb 21 00:54, Andy Wu wrote:

When I try to do a checkout or export from a svn repository, I get the
following error message:


svn checkout svn+ssh://[path]/[to]/[repository]

11 [main] svn 1472 child_copy: linked dll data write copy failed,
0x317000..0x3170B0, done 0, windows pid 3628, Win32 error 487
svn: Can't create tunnel: Resource temporarily unavailable

This seems to be happening only on Vista (darn Microsoft), and so
command line svn doesn't seem to be working in cygwin. I'm on the
latest cygwin 1.5.24-1 and the svn version is 1.4.2.

I know that Vista is actually not yet supported, 


Cygwin runs on Vista and it's supported.  Did you try rebasing?
See /usr/share/doc/Cygwin/rebase-2.4.3.README


Svn command-line (1.4.2 r22196) seems to work just fine for me in 
Cygwin on Vista.


In my case I /did/ rebaseall to 0x6500 when trying to solve an 
unrelated problem however (it was due to an old cygwin1.dll from a 
crap installer in \windows\system).


Does it happen only when doing a checkout or export from an ssh 
repository?




FYI, a rebaseall fixed this problem for me.

Jim

--
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: [ping] SWIG maintainer

[Jim Kleckner]

Yep.  The "const char *" declarations are missing with the current swig 
version so Python 2.5 doesn't work without modifications.


It would be great to update SWIG now that Python is.

Brian Hassink wrote:

A friendly ping to the SWIG package maintainer...

The current package is based on SWIG 1.3.29 from 03/06, and the latest
is 1.3.31 from 11/06.  There were a number of updates in 1.3.30 that may
justify rolling an updated package (in my case, I needed some new Lua
functionality).

Thanks,
Brian

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


  


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

Cygwin anti-spam techniques

[Jim Kleckner]

The presence of a little bit of spam on this list reminds
me how little normally gets through.

I know it might be considered a little OT, but do you have
a pointer to what techniques are used these days?

Thanks - Jim

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

cygwin.com DNS not resolving?

[Jim Kleckner]

I'm not seeing name resolution on cygwin.com from several different ISPs?

Anyone else see this or know what is going on?

--
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: Will cygwin produced *.exe run w/o cygwin installed?

[Jim Kleckner]

Gene Smith wrote:
I have built a cross compiler for arm under cygwin from gnu sources 
and cygwin's gcc. I now have a bunch of .exe's that run fine under 
cygwin. Is it possible to use these on a system without cygwin 
installed. Right now I don't have a system w/o cygwin so can't test.


See cygcheck which will list all of the dll files that your application 
depends on.


e.g.  cygcheck ./foo.exe

For full options, type cygcheck --help

--
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.21-1 DLL Loading Problem (binutils?)

[Jim Kleckner]

Martin wrote:

--- Rob Hatcherson <[EMAIL PROTECTED]> wrote:
...
I had a similar problem with dynamically loaded modules (extensions) in
TCL.  I traced my problem to the upgrade of binutils 20050610-1 to
binutils 20060709-1.  When I rolled it back, everthing was fine.

However, I'm still running 1.5.20-1.
  


Based on Martin's comment and a couple of other observations
that rolling back binutils might help, I did so and was able to get
numpy 0.98 to compile and somewhat work. 


Does binutils need to be rolled back in the release?

Separately, if I type
gdb python
run
it just hangs and I have to separately kill python. 
Is this reproducible by others or do I need to dig deeper?


Jim





--
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: keychain doesn't properly cache ssh key

[Jim Kleckner]

René Berber wrote:

Keychain seems to be missing the equivalent of "eval `ssh-agent -s`" (if using
bash).
  


I use this bash function to start keychain to work around that issue.

function kc() {
   #Keychain invocation
   keychain ~/.ssh/id_rsa
   if [ -e ~/.ssh-agent-`hostname` ] ; then
   source ~/.ssh-agent-`hostname`
   elif [ -e ~/.keychain/`hostname`-sh ] ; then
   source ~/.keychain/`hostname`-sh
   fi
}


--
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: Infinite loop in Numeric-24.2-1 for eigenvalues (Workaround)

[Jim Kleckner]

Jim Kleckner wrote:

This patch mentions:
# Optionally, you can run
#   python setup.py config  first. This fixes a bug in 
LinearAlgebra on Cygwin (and possibly

# other platforms).


but "python setup.py config" fails to compile with the message:
unable to execute _configtest.exe: No such file or directory


Somehow, the optimization compiler flags are getting set to -O3 which 
only seems to

be set for the emx compiler platform...


Note that this was a problem on my Linux box as well.

A workaround for this problem in setup.py is to run this simple script 
to create the

config.h file that is failing (probably due to the compile flags):


gcc -fno-strict-aliasing -DNDEBUG -g  -Wall -Wstrict-prototypes 
-IInclude -IPackages/FFT/Include -IPackages/RNG/Include 
-I/usr/include/python2.4 Src/config.c -o mkconfigh

./mkconfigh
mv config.h Src


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

Infinite loop in Numeric-24.2-1 for eigenvalues

[Jim Kleckner]

Yaakov S (Cygwin Ports) wrote:

The following package has been added to the Cygwin net release:

*** Numeric-24.2-1

Numerical Python provides a fast, compact, multidimensional array
language facility as a Python module.

This package requires python-2.4.x and is listed under the Python category.
  


I gave a try with Numeric and calling a simple eigenvector calculation 
and it never returns.


Here is a snip of the eigenvector test (note that the tests hang this way):
=
import Numeric
import LinearAlgebra

a = Numeric.array([[2,3], [4,5]])
print a
v = LinearAlgebra.eigenvalues(a)
print v
assert_eq(v, Numeric.array([3.5-math.sqrt(57)/2.,
   3.5+math.sqrt(57)/2.]))
==

Running it pounds sand uninterruptible by ctl-C until you use ctl-Z to 
suspend and "kill -9 %1" to kill it.


Googling returns some hints:
Here is a description of the problem and solution:
http://sourceforge.net/tracker/index.php?func=detail&aid=732520&group_id=1369&atid=301369

This patch mentions:
# Optionally, you can run
#   python setup.py config  first. This fixes a bug in LinearAlgebra 
on Cygwin (and possibly

# other platforms).


but "python setup.py config" fails to compile with the message:
unable to execute _configtest.exe: No such file or directory


Somehow, the optimization compiler flags are getting set to -O3 which 
only seems to

be set for the emx compiler platform...

I'm sending this while still in the midst of sorting things out in case 
someone knows what is up.



Jim

Cygwin Configuration Diagnostics
Current System Time: Wed Aug 09 06:26:50 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   c:\Jim\bin
c:\Jim\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\Microsoft Office\OFFICE11\Business Contact Manager\IM
c:\Program Files\Microsoft SQL Server\80\Tools\Binn\
c:\Program Files\Microsoft Office\OFFICE11\Business Contact Manager\
c:\Program Files\Common Files\Adaptec Shared\System
C:\cygwin\localbin
C:\cygwin\lib\lapack
c:\Program Files\vim\vim64
c:\Program Files\Java\jdk1.5.0_04\bin
c:\Program Files\vim\vim64
c:\Program Files\Java\jdk1.5.0_04\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1008(jim)   GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1004(Debugger Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1008(jim)   GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1004(Debugger Users)

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

USER = 'jim'
PWD = '/cygdrive/c/Jim/Consult/VMI/Programs'
HOME = '/cygdrive/c/Jim'
MAKE_MODE = 'unix'

HOMEPATH = '\Documents and Settings\jim'
MANPATH = 
'/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/X11R6/man:/usr/ssl/man:/usr/X11R6/man'
APPDATA = 'C:\Documents and Settings\jim\Application Data'
HOSTNAME = 'kleckner2'
GAIMHOME = 'c:\Jim'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 13 Stepping 6, GenuineIntel'
WINDIR = 'C:\WINDOWS'
TEXDOCVIEW_TXT = 'cygstart %s'
TEXDOCVIEW_DVI = 'cygstart %s'
CVSROOT = ':ext:www.kleckner.net:/home/CVS/repository'
WINDOWID = '6832824'
USERDOMAIN = 'KLECKNER2'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/jim/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
USERNAME = 'jim'
TEXDOCVIEW_PDF = 'cygstart %s'
PROCESSOR_LEVEL = '6'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
JAVA_HOME = '/cygdrive/c/Program Files/Java/jdk1.5.0_04'
EDITOR = 'vim.exe'
TEXDOCVIEW_HTML = 'cygstart %s'
USERPROFILE = 'C:\Documents and Settings\jim'
CLIENTNAME = 'Console'
PS1 = '[EMAIL PROTECTED] \W]\$ '
LOGONSERVER = '\\KLECKNER2'
PROCESSOR_ARCHITECTURE = 'x86'
MAGICK_HOME = 'c:/cygwin'
SHLVL = '2'
COLORFGBG = '0;default;15'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/cygdrive/c/DOCUME~1/jim/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
QLXL_DIR = 'C:\Documents and Settings\jim\Desktop\md\QuantLibXL'
VMI = 'c:/Jim/Consult/VMI'
PROCESSOR_REVISION = '0d06'
PRINTER = 'Adobe PDF'
CVS_RSH = 'ssh.exe'
PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig'
PGDATA = '/usr/local/postgresql/data'
TEXDOCVIEW_PS = 'cygstart %s'
PROGRAMFILES = 'C:\Program Files'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
DISPLAY = ':0'
NUMBER_OF_PROCESSORS = '1'
SESSIONNAME = 'Console'
COMPUTERNAME = 'KLECKNER2'
COLORTERM = 'rxvt-xpm'
_ = '/usr/bin/cygcheck'
OLDPWD = '/cygdrive/c/Jim'
POSIXLY_CORRECT = '1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygn

Re: Cygwin G++ bug? - Python Extension module #including dies before initialization

[Jim Kleckner]

Jim Kleckner wrote:

Brian Dessent wrote:

As you can see, this all is contingent upon a program like GDB using the
Windows debug API.  Without that, the entire issue is irrelevant, so I
can't see how this possibly would apply to Python.
  


Thanks for explaining how the Windows debug API is the one
actually catching the exception rather than GDB directly
changing how exceptions are caught.  This is useful.

I will be surprised if there doesn't turn out to be some
commonality between the pthread_mutex_init issue
and something Python is doing either directly or
via the use of dlopen().


Indeed, cgf is a magician and his patch in snapshot
*2006-05-27 appears to fix the signal handler issue
for Python.  As mentioned in his patch message,
this may fix the signal handler issues for many DLLs.

Many many thanks.

Jim
*

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

Re: Cygwin G++ bug? - Python Extension module #including dies before initialization

[Jim Kleckner]

Brian Dessent wrote:

As you can see, this all is contingent upon a program like GDB using the
Windows debug API.  Without that, the entire issue is irrelevant, so I
can't see how this possibly would apply to Python.
  


Thanks for explaining how the Windows debug API is the one
actually catching the exception rather than GDB directly
changing how exceptions are caught.  This is useful.

I will be surprised if there doesn't turn out to be some
commonality between the pthread_mutex_init issue
and something Python is doing either directly or
via the use of dlopen().

Thanks - Jim

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

Re: Cygwin G++ bug? - Python Extension module #including dies before initialization

[Jim Kleckner]

Jim Kleckner wrote:


Could someone provide a pointer to the GDB change?


The changelog is here: *http://tinyurl.com/rnhjw

win32_nat.c is listed here: **http://tinyurl.com/rnhjw

The key change diffs appear to be here:
**http://tinyurl.com/z5vze


*

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

Re: Cygwin G++ bug? - Python Extension module #including dies before initialization

[Jim Kleckner]

Max Bowsher wrote:

Hi,

I compiled a C++ Python Extension, and found that it caused the Python
interpreter process to silently die (with a *zero* exitcode!) when it
attempted to load the extension module.

I traced the problem to the line:
  static ios_base::Init __ioinit;
in .

It seems that when the module is dlopen()-ed, something involved in this
static initializer terminates the process.

[snip]


Thanks for the simple test case!  I was just preparing
to try to do this today.

This appears related to the signal handling problem that GDB experiences
and documented at length.  One starting point for this discussion is the
thread here:
http://www.cygwin.com/ml/cygwin/2006-05/msg00691.html

GDB is inserting a signal handler ahead of Cygwin that catches
signals used to detect valid/invalid objects and GDB is then
failing when it classifies those signals as SIGSEGV.
It happens with the iostream usage because of a static
initializer that uses a mutex for safety.  The fix involved
a small change to cygwin along with a small change to
GDB so that the exception used to detect a bad pointer
by cygwin would not be caught by GDB as a SIGSEGV.
The fix side of Cygwin is not yet released (but it is in
snapshots) and the fix side of GDB is checked in but
can't be released until Cygwin dll is released.

Perhaps Python is doing something similar and needs to
implement the same change implemented in GDB to
the signal handling?

Could someone provide a pointer to the GDB change?
(Yes, I looked into the change logs for GDB around Feb
but nothing stood out as relevant).
*http://tinyurl.com/fqpb9 *

Would the Python maintainer then consider whether these
changes are relevant to Python?

Until this is solved, all DLLs that are used by Python
and use C++ with iostreams will fail silently in this way.

Normally, I keep a snapshot of an older Cygwin release
to protect against this kind of regression.  Unfortunately,
in my exuberance lately I find that my oldest snapshot
still exhibits this problem.  I have yet to find
a way to reliably down rev from the release itself.
I tried simply choosing "Prev" for all packages but
unfortunately in my haste didn't note what error message
occurred when trying that.

Thanks - Jim

--
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.15.19 dlopen() dies with no dlerror()

[Jim Kleckner]

Larry Hall (Cygwin) wrote:

Jim Kleckner wrote:



Larry Hall (Cygwin) wrote:

Jim Kleckner wrote:

Jim Kleckner wrote:

Michael McKerns wrote:

Yes, yes...  I've not given you enough information...
...
See:
http://cygwin.com/cygwin-ug-net/dll.html
http://cygwin.com/faq.html#faq.programming.dll-relocatable
  
I'm seeing a similar problem with python and 1.5.19 and also tried 
the snapshot of 22-May.


CYGWIN_NT-5.1 kleckner2 1.5.20s(0.155/4/2) 20060522 00:51:23 i686 
Cygwin


A simple test case doesn't fail in dlopen().

My code is not simple but has been working prior to the most 
recent update (which also updated python and other packages).
A downrev of python does not make the problem go away.  If I 
downrev cygwin, I get complaints about missing entry points.


What do you recommend as the best way to isolate this?


I tried using "prev" with setup.exe but that didn't make the 
problem go away.


A simple test case with python access to a trivial function works 
fine (can supply if anyone wants).

The complex dll that used to work simply doesn't return from dlopen.

I downloaded the 20060522 snapshot with debug symbols to get a 
backtrace with GDB.
GDB says there is a seg fault and somehow this is preventing any 
information from reaching dlerror().
Without the dlerror() info, it is hard to figure out what needs to 
change with the dll.

It appears that some constructors are having trouble.

Let me know if there is some single stepping that could be helpful.
[snip]
(gdb) bt
#0  0x610b1ff8 in pthread_key_create (key=0x6622f8, destructor=0) at 

^^^
Known issue already fixed in the Cygwin snapshot and in GDB's CVS.  
This

is not fatal.  Just continue until you stop seeing this complaint.



As noted above, this was tested using snapshot 20060522. Should that 
snapshot have the fix you mention?  If it should, then this problem 
still exists in that snapshot.

If not, then which one should I test?


The part of the fix that is Cygwin-specific is in the Cygwin snapshot you
have.  But, like I said, there's another part of the fix that's only in
GDB's CVS version right now.  If you want to be rid of the problem 
right now,
you need both changes and that means you'll need to grab GDB's source 
from

CVS and build it.  But whether you choose to do this or not should not
inhibit your original investigation.  Depending on how many times your
code path takes you through pthread_ket_create(), it may test test your
tolerance level for the current work-around though. ;-)

Thanks for pointing me into the GDB and SIGSEGV discussions.
I didn't see the relationship to the dlopen() problem.

I didn't see discussion of a fix to python which has failing
dlopen() calls presumably because of initializations of mutex objects.
Does python need to do what GDB now does?

Is there a workaround/snapshot in the meantime?


--
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.15.19 dlopen() dies with no dlerror()

[Jim Kleckner]

Larry Hall (Cygwin) wrote:

Jim Kleckner wrote:

Jim Kleckner wrote:

Michael McKerns wrote:

Yes, yes...  I've not given you enough information...
...
See:
http://cygwin.com/cygwin-ug-net/dll.html
http://cygwin.com/faq.html#faq.programming.dll-relocatable
  
I'm seeing a similar problem with python and 1.5.19 and also tried 
the snapshot of 22-May.


CYGWIN_NT-5.1 kleckner2 1.5.20s(0.155/4/2) 20060522 00:51:23 i686 
Cygwin


A simple test case doesn't fail in dlopen().

My code is not simple but has been working prior to the most recent 
update (which also updated python and other packages).
A downrev of python does not make the problem go away.  If I downrev 
cygwin, I get complaints about missing entry points.


What do you recommend as the best way to isolate this?


I tried using "prev" with setup.exe but that didn't make the problem 
go away.


A simple test case with python access to a trivial function works 
fine (can supply if anyone wants).

The complex dll that used to work simply doesn't return from dlopen.

I downloaded the 20060522 snapshot with debug symbols to get a 
backtrace with GDB.
GDB says there is a seg fault and somehow this is preventing any 
information from reaching dlerror().
Without the dlerror() info, it is hard to figure out what needs to 
change with the dll.

It appears that some constructors are having trouble.

Let me know if there is some single stepping that could be helpful.
[snip]
(gdb) bt
#0  0x610b1ff8 in pthread_key_create (key=0x6622f8, destructor=0) at 

^^^
Known issue already fixed in the Cygwin snapshot and in GDB's CVS.  This
is not fatal.  Just continue until you stop seeing this complaint.



As noted above, this was tested using snapshot 20060522. 
Should that snapshot have the fix you mention?  If it should, then this 
problem still exists in that snapshot.

If not, then which one should I test?

Thanks - Jim

--
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.15.19 dlopen() dies with no dlerror()

[Jim Kleckner]

Jim Kleckner wrote:

Michael McKerns wrote:

Yes, yes...  I've not given you enough information...
...
See:
http://cygwin.com/cygwin-ug-net/dll.html
http://cygwin.com/faq.html#faq.programming.dll-relocatable
  
I'm seeing a similar problem with python and 1.5.19 and also tried the 
snapshot of 22-May.


CYGWIN_NT-5.1 kleckner2 1.5.20s(0.155/4/2) 20060522 00:51:23 i686 Cygwin

A simple test case doesn't fail in dlopen().

My code is not simple but has been working prior to the most recent 
update (which also updated python and other packages).
A downrev of python does not make the problem go away.  If I downrev 
cygwin, I get complaints about missing entry points.


What do you recommend as the best way to isolate this?


I tried using "prev" with setup.exe but that didn't make the problem go 
away.


A simple test case with python access to a trivial function works fine 
(can supply if anyone wants).

The complex dll that used to work simply doesn't return from dlopen.

I downloaded the 20060522 snapshot with debug symbols to get a backtrace 
with GDB.
GDB says there is a seg fault and somehow this is preventing any 
information from reaching dlerror().
Without the dlerror() info, it is hard to figure out what needs to 
change with the dll.

It appears that some constructors are having trouble.

Let me know if there is some single stepping that could be helpful.

 Trivial program to use dlopen on a non-trivial dll

#include 
#include 

int main( int argc, char **argv)
{
   fprintf( stderr, "Error: %s\n", dlerror());
   void *dlp = dlopen("_pycode.dll", RTLD_NOW);
   fprintf( stderr, "Error: %s\n", dlerror());
   return 0;
}

 GDB Traceback

$ gdb a.exe
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: .../Programs/a.exe
Error: (null)

Program received signal SIGSEGV, Segmentation fault.
0x610b1ff8 in pthread_key_create () from /usr/bin/cygwin1.dll
(gdb) add-symbol-file /bin/cygwin1-20060522.dbg
add symbol table from file "/bin/cygwin1-20060522.dbg" at
(y or n) y
Reading symbols from /bin/cygwin1-20060522.dbg...warning: no loadable 
sections found in added symbol-file /bin/cygwin1-20060522.dbg

done.
Current language:  auto; currently c++
(gdb) bt
#0  0x610b1ff8 in pthread_key_create (key=0x6622f8, destructor=0) at 
/netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/thread.cc:129
#1  0x61090d68 in _sigfe () at 
/netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/cygserver.h:82

#2  0x59432d52 in ?? ()
#3  0x00662300 in ?? ()
#4  0x0001 in ?? ()
#5  0x00662300 in ?? ()
#6  0x0022c204 in ?? ()
#7  0x610b2cd7 in pthread::once (once_control=0x662300, 
init_routine=0x22c264) at 
/netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/thread.cc:2000
#8  0x610b2cd7 in pthread::once (once_control=0x662300, 
init_routine=0x6846a760 )

   at /netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/thread.cc:2000
#9  0x61090d68 in _sigfe () at 
/netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/cygserver.h:82

#10 0x0022c234 in ?? ()
#11 0x6846a825 in _Unwind_SjLj_Register () from .../_pycode.dll
#12 0x6846a825 in _Unwind_SjLj_Register () from .../_pycode.dll
#13 0x6845e173 in std::ios_base::Init::Init () from .../_pycode.dll
#14 0x6845bb20 in __static_initialization_and_destruction_0 
(__initialize_p=1, __priority=1627983208)

   at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77
#15 0x61010243 in per_module::run_ctors (this=0x0) at 
/netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/dll_init.cc:55

#16 0x0001 in ?? ()
#17 0x61010290 in dll::init (this=0x61010a7e) at 
/netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/dll_init.cc:81

#18 0x68550008 in ?? ()
#19 0x in ?? () from
(gdb)


Cygwin Configuration Diagnostics
Current System Time: Tue May 23 18:07:09 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   c:\Jim\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\Microsoft Office\OFFICE11\Business Contact Manager\IM
c:\Program Files\Microsoft SQL Server\80\Tools\Binn\
c:\Program Files\Microsoft Office\OFFICE11\Business Contact Manager\
c:\Program Files\Common Files\Adaptec Shared\System
C:\cygwin\localbin
C:\cygwin\lib\lapack
c:\Program Files\vim\vim64
c:\Program Files\Java\jdk1.5.0_04\bin

Output from C:\cygw

Re: 1.15.19 dlopen() dies with no dlerror()

[Jim Kleckner]

Michael McKerns wrote:

Yes, yes...  I've not given you enough information...

$ uname -a
CYGWIN_NT-5.1 turro 1.5.19<0.150/4/2) 2006-01-20 13:38 i686 Cygwin

Also the file I attached needs to inspect a .dll that is built
with the procedure that I described in the first part of the
message.  So when you got "No such file or directory", it is because
dlopen.c is looking for the .dll that is hardwired into the code.
You'd need to replace it with a .dll that you built with the
aforementioned syntax.

I'm using the standard cygwin syntax for building dll's, but
I'm useing the raw code that's inside dlltool.

See:
http://cygwin.com/cygwin-ug-net/dll.html
http://cygwin.com/faq.html#faq.programming.dll-relocatable
  
I'm seeing a similar problem with python and 1.5.19 and also tried the 
snapshot of 22-May.


CYGWIN_NT-5.1 kleckner2 1.5.20s(0.155/4/2) 20060522 00:51:23 i686 Cygwin

A simple test case doesn't fail in dlopen().

My code is not simple but has been working prior to the most recent 
update (which also updated python and other packages).
A downrev of python does not make the problem go away.  If I downrev 
cygwin, I get complaints about missing entry points.


What do you recommend as the best way to isolate this?

Tx.

Cygwin Configuration Diagnostics
Current System Time: Mon May 22 23:35:12 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   c:\Jim\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\Microsoft Office\OFFICE11\Business Contact Manager\IM
c:\Program Files\Microsoft SQL Server\80\Tools\Binn\
c:\Program Files\Microsoft Office\OFFICE11\Business Contact Manager\
c:\Program Files\Common Files\Adaptec Shared\System
C:\cygwin\localbin
C:\cygwin\lib\lapack
c:\Program Files\vim\vim64
c:\Program Files\Java\jdk1.5.0_04\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1008(jim)   GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1004(Debugger Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1008(jim)   GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1004(Debugger Users)

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

USER = 'jim'
PWD = '/tmp'
HOME = '/cygdrive/c/Jim'
MAKE_MODE = 'unix'

Use '-r' to scan registry

c:  hd  NTFS 76261Mb  85% CP CS UN PA FC 
d:  cd N/AN/A
q:  net NTFS223465Mb  22% CP CSPAchecking

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

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
Not Found: crontab
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\patch.exe
Found: C:\cygwin\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\ssh.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Found: C:\cygwin\bin\vim.exe
Found: c:\Program Files\vim\vim64\vim.exe

   91k 2005/11/11 C:\cygwin\bin\cygapr-0-0.dll
  160k 2006/02/18 C:\cygwin\bin\cygapr-1-0.dll
   67k 2005/11/11 C:\cygwin\bin\cygaprutil-0-0.dll
  111k 2006/02/18 C:\cygwin\bin\cygaprutil-1-0.dll
   56k 2005/07/09 C:\cygwin\bin\cygbz2-1.dll
7k 2005/11/20 C:\cygwin\bin\cygcharset-1.dll
  255k 2006/05/01 C:\cygwin\bin\cygclamav-1.dll
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll
 1108k 2005/10/17 C:\cygwin\bin\cygcrypto-0.9.7.dll
 1047k 2005/10/11 C:\cygwin\bin\cygcrypto-0.9.8.dll
  182k 2005/12/07 C:\cygwin\bin\cygcurl-3.dll
   22k 2004/02/10 C:\cygwin\bin\cygcygipc-2.dll
  895k 2004/04/28 C:\cygwin\bin\cygdb-4.2.dll
  965k 2005/05/14 C:\cygwin\bin\cygdb-4.3.dll
 1156k 2004/04/28 C:\cygwin\bin\cygdb_cxx-4.2.dll
 1240k 2005/05/14 C:\cygwin\bin\cygdb_cxx-4.3.dll
  107k 2005/08/08 C:\cygwin\bin\cygexif-12.dll
  174k 2004/10/14 C:\cygwin\bin\cygexpat-0.dll
  129k 2004/03/11 C:\cygwin\bin\cygfontconfig-1.dll
   40k 2006/03/24 C:\cygwin\bin\cygform-8.dll
   45k 2001/04/25 C:\cygwin\bin\cygform5.dll
   35k 2002/01/09 C:\cygwin\bin\cygform6.dll
   48k 2003/08/09 C:\cygwin\bin\cygform7.dll
  859k 2005/08/08 C:\cygwin\bin\cygfpx-1.dll
  375k 2005/09/06 C:\cygwin\bin\cygfreetype-6.dll
  222k 2005/01/13 C:\cygwin\bin\cyggd-2.dll
   28k 2003/07/20 C:\cygwin\bin\cyggdbm-3.dll
   30k 2003/08/11 C:\cygwin\bin\cyggdbm-4.dll
   19k 2003/03/22 C:\cygwin\bin\cyggdbm.dll
   15k 2003/07/20 C:

Re: rysnc hangs when backing up multiple /cygdrive/* dirs

[Jim Kleckner]

H.S. wrote:
...


I don't know why, but it is working now. I exluded the .lnk files and
backup the d drive folder separately first. Then I included other
directories to backed up. Now I am backing up only '/cygdrive/d/sukh
/cygdrive/c/Documents\ and\ Settings' and it seems tobe working great.
Well, not 100% great, I am posting that problem in a different post shortly.


There is a deadlock when "pulling".  Try "pushing".

See http://www.cygwin.com/ml/cygwin/2005-09/msg00263.html
and lots of discussion about this via Google.

Jim

--
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: Why is setup.exe so difficult? Am I missing something?

[Jim Kleckner]

Matt England wrote:

 > I find cygwin's setup.exe extremely difficult to understand, and over
the years I've used it, I have found it somewhat buggy (unless the 
"bugs" I find are really just "features" that I don't understand).


The biggest question: why do myself and everyone else in my software 
development group that I manage (as well as everyone else with whom I've 
spoken over the years regarding cygwin) find cygwin's setup.exe so 
perplexing?


One confusing thing that could be improved is to clearly label the
radio buttons as "Default Action:" and to change "Curr" to be something
like "Update" or "Latest".  The very non-standard way that these
buttons interact with the list is confusing and every little bit of
help will help.  A more standard way would be a selection-action
interface.



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

[Jim Kleckner]

Jonathan wrote:

When backing up data off the desktop box ( debian <- windows ) the rsync 
will often stall.


Note that if you can get the client to "push" the data to
the server rather than having the server "pull" it, then
there seems to be no hang problem.  But firewalls often get
in the way of that.

It would appear that the only conclusion from all the threads, puts the 
stalling down to a socket select mishandling (Speculation ?).


Has anyone got further information regarding this issue.

PS

Yes I have tried the msleep(30); rsync solution.


A fellow named Bob Byrnes had some thread-related patches
that might have fixed this, but he seems to have gone away.
For context, see here:
 http://sources.redhat.com/ml/cygwin-patches/2005-q1/msg00016.html
 http://sources.redhat.com/ml/cygwin-patches/2005-q1/msg00015.html
 https://bugzilla.samba.org/show_bug.cgi?id=2328

I've been hoping that the thread-related patches being made
to cygwin might fix this but apparently that hasn't happened
yet.

Jim

--
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: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
On Wed, Mar 30, 2005 at 09:57:44AM -0800, Jim Kleckner wrote:

Then strike the link text and limit it to the workaround of adding
the bin to the system path.   My text was a suggested starting point.

i.e., a workaround.

The solution that the DLL has to be in the system path is not required
for a sanctioned Cygwin release.  But, then, we've seen before that
clamwin insists on running in a non-cygwin environment.  I don't want to
be in the business of adding advice to the FAQ for fixing up other
people's problems.
Nobody said the workaround was required.

See above.
Above does not say the workaround is required nor did the original
text.
You complain about 3PPs but don't want to provide any easily found
directions to them about what not to do.  You can say "search
the list" but as a practical matter, it isn't effective at guiding
their behavior.
--
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: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
On Wed, Mar 30, 2005 at 08:45:10AM -0800, Jim Kleckner wrote:

So, if you're a Unix guy since 1978, that puts you in a unique category.
You don't qualify as a FAQ.
I don't quite understand this.  I don't qualify to write FAQ entries
or shouldn't be allowed to use them?
I have very strong reservations about filling up documentation with
every conceivable combination of advice that we could possibly think of.
Adding rationales to stop Unix guys from shooting themselves in the foot
should not be a focus of the FAQ.  The FAQ is there to give advice to
people on what to do, not to provide rationales for why they shouldn't
do other things that pop into their heads.
Then strike the link text and limit it to the workaround of adding
the bin to the system path.   My text was a suggested starting point.
Look, all I'm trying to do here is save time for other people, not
waste all of our time.  The notion that the email list should be
the primary reference for this kind of issue is wrong.  And it shouldn't
be this hard to try to help out either.

The solution that the DLL has to be in the system path is not required
for a sanctioned Cygwin release.  But, then, we've seen before that
clamwin insists on running in a non-cygwin environment.  I don't want to
be in the business of adding advice to the FAQ for fixing up other
people's problems.
Nobody said the workaround was required.
I am very grateful for the great lengths you go to to fix other people's
problems who use cygwin.
If this is a problem with clamwin then people should be lobbying them
for a fix, not suggesting that the Cygwin FAQ has to be modified as
a workaround.
Agree that clamwin should be fixed.  I don't use it and don't care to
use it.  But then I share the compute resources.
Jim
- "It is better to light a candle than curse the darkness"
--
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: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
On Wed, Mar 30, 2005 at 08:08:16AM -0800, Jim Kleckner wrote:
Christopher Faylor wrote:
OTOH, perhaps I'm oversimplifying things, but it seems like this thread
went on for quite a while after the simple "delete the nonstandard DLL"
advice was given.  I don't see how any advice is going to be useful if
it isn't followed.
I agree completely.  All the more reason to pull the concise answers
out of the email list and into the FAQ.  This thread wouldn't have
existed at all.

The concise answer is already in *cygwin itself*.  The FAQ could
arguably be updated to say "delete the dll that is not in
c:\cygwin\bin".  I guess it is assuming that someone has actually
taken the time to read the error that cygwin presents.
However, again, this concise answer was mentioned in the email list and
not followed.  I don't know why anyone would view the FAQ as more
authoritative than the people they are soliciting for help here.
Not true at all.  The suggestion was followed.
Note that the FAQ does not state to put the cygwin bin on the system 
path.  Of course I knew that it would work to do that.  As a Unix guy
since 1978, I was curious to try using ln to see what it would do. 
Larry Hall helpfully pointed out that while it would work, it was a 
brittle solution.

Look, all I'm trying to do here is save time for other people, not
waste all of our time.  The notion that the email list should be
the primary reference for this kind of issue is wrong.  And it shouldn't
be this hard to try to help out either.
Jim
--
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: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
OTOH, perhaps I'm oversimplifying things, but it seems like this thread
went on for quite a while after the simple "delete the nonstandard DLL"
advice was given.  I don't see how any advice is going to be useful if
it isn't followed.
I agree completely.  All the more reason to pull the concise answers
out of the email list and into the FAQ.  This thread wouldn't have
existed at all.
Jim
--
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: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Larry Hall wrote:
> At 10:20 PM 3/24/2005, Brian Dessent wrote:
>> A symlink won't work, because it's Windows own loader that searches
>> for and loads any .DLLs called for by an .exe. Windows does not
>> understand symlinks as they are a Cygwin thing, so you can't
>> symlink a DLL and expect it to load.
>>
>> NTFS does not support symbolic links but it does support hard
>> links, see
>> 
.
>>  If the volume is NTFS, 'ln' will use this capability. On 9x or FAT
>> it will make a copy (I think.)

Right, that is what I saw.  Symlink failed but hard link worked.
> Right. It will. It's also worth noting that hard links break again as
>  soon as you update either clamwin or Cygwin, even on NTFS volumes.
> Alternatively, if you make sure that clamwin can see your Cygwin
> installation, it will seamlessly work through Cygwin updates. But the
>  only way you're going to get clamwin to work seamlessly through
> updates of clamwin is to get clamwin's installation to change.
A compelling reason to not use hard links.
OK, one last attempt, in the spirit of PTC and to help fellow
travelers.  The existing FAQ entry at this location reads:
  http://cygwin.com/faq/faq_3.html#SEC50
Is it OK to have multiple copies of the DLL?
You should only have one copy of the Cygwin DLL on your
system. If you have multiple versions, they will conflict
and cause problems.
If you get the error "shared region is corrupted" or "shared
region version mismatch" it means you have multiple versions
of cygwin1.dll running at the same time. This could happen,
for example, if you update cygwin1.dll without exiting all
Cygwin apps (including inetd) beforehand.
If you're trying to find multiple versions of the DLL that
are causing this problem, reboot first, in case DLLs still
loaded in memory are the cause. Then use the Windows System
find utility to search your whole machine, not just
components in your PATH (as 'type' would do) or
cygwin-mounted filesystems (as Cygwin 'find' would do).
Based on the information in this thread, I would suggest some
variation of the following additional paragraph at the end of
that text:
When you find copies of cygwin1.dll remove all of them
except the cygwin-installed version.  As a workaround, you
might be able to make the offending application work with
the installed DLL by adding the cygwin bin directory to your
system path environment variable.  Although you could hard
link the cygwin DLL into the location of the application
directory containing the duplicate copy instead of changing
the system path, this is not a good idea because when you
update the cygwin package, that link will break and you will
once again have two copies of the cygwin DLL.
Hopefully, this will help fellow travelers and is in the
interest of reducing the amount traffic on this list.  Such
common problems seem logical to me to document in the FAQ rather
than wasting the OP's time and everyone on the list.  If there
is a place where this is already documented, the FAQ should
point there.
If there is interest, I am willing to take a crack at pulling
together the information that is sprinkled in email threads
about how to avoid trampling on existing cygwin installations.
Eventually, there really should be a section in the user guide
about the topic "How (and how not) to create and distribute an
application that depends on cygwin".  I'm willing to help with
that but I suspect other people can write something many times
more quickly and more accurately.
Jim
--
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: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Jim Kleckner wrote:
This is helpful, thank you.  Being curious and trying to be minimal 
about changes to the system in question, I tried removing and linking
the dll in place.  I first tried "ln -s /bin/cygwin1.dll" in the
clamwin/bin directory and wasn't surprised that it didn't work.
Being Unix person by background, I then tried "ln /bin/cygwin1.dll"
And yes, I did reboot after removing to be sure caches were clear.
--
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: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Larry Hall wrote:
At 01:50 PM 3/24/2005, you wrote:
 

I had a user install clamwin and as discussed on the list here:
http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00288.html
it blithely installs cygwin1.dll regardless of any installation
of cygwin.  This predictably causes problems.
Searching through the user guide and faq doesn't yield
a suggestion for solutions or workarounds and searching
the list archives yields so much material that it is
hard to focus in on what specifically to do.  Obviously,
I can have the person uninstall clamwin.  Is there anything
else that makes sense (and, no, uninstalling cygwin doesn't
make sense)?  
   


The "standard" solution in these cases is to remove the cygwin1.dll 
from the offending 3rd party package after installing and make sure 
that the 3rd party package can find the already existing cygwin1.dll
in the Cygwin installation (C:\cygwin\bin by default).  The easiest 
way to do this is to put the Cygwin installation path/bin in your
Windows path.  As Chris points out, this could all be automated with 
some minor effort on the part of the 3rd party providers but in the
absence of such support, you have to do it manually. :-(  A better 
question might be to ask the clamwin folks why they can't augment
their installer to accommodate an existing Cygwin installation.  If
their package breaks a Cygwin installation, it's really not a Cygwin
problem per-se.
 

This is helpful, thank you.  Being curious and trying to be minimal 
about changes
to the system in question, I tried removing and linking the dll in 
place.  I first tried
"ln -s /bin/cygwin1.dll" in the clamwin/bin directory and wasn't 
surprised that it
didn't work.  Being Unix person by background, I then tried "ln 
/bin/cygwin1.dll"
and that surprised me by working.  I expected to see an NTFS cygwin1.dll.lnk
file in there but using "cmd.exe" and "dir" or the windows explorer 
looks like a
full copy of the dll file.  An "ls -l" tantalizingly shows a link count 
of 2.  "info ln"
doesn't give any cygwin-specific info.  The section of the user guide 
located here:
 http://cygwin.com/cygwin-ug-net/using-effectively.html#id2950938
has some wording that implies this might work but isin't definitive. 

My question now is, can "ln" be used to work around this issue or is 
that a "bad idea"?

Thanks again - Jim
PS.  Since cgf is steadfast, perhaps this explanation could be added to 
the FAQ
entry located here that partially explains why multiple dlls is a problem:
 http://cygwin.com/faq/faq_3.html#SEC50

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

clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

I had a user install clamwin and as discussed on the list here:
 http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00288.html
it blithely installs cygwin1.dll regardless of any installation
of cygwin.  This predictably causes problems.
Searching through the user guide and faq doesn't yield
a suggestion for solutions or workarounds and searching
the list archives yields so much material that it is
hard to focus in on what specifically to do.  Obviously,
I can have the person uninstall clamwin.  Is there anything
else that makes sense (and, no, uninstalling cygwin doesn't
make sense)?  This would be a good candidate for the FAQ,
I think.
Many thanks - Jim
--
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: ssh-agent and /tmp/ssh-* removal at logout

[Jim Kleckner]

Karl M wrote:
From: Jim Kleckner
Subject: ssh-agent and /tmp/ssh-* removal at logout
Date: Wed, 23 Feb 2005 06:18:50 -0800
ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
Jim
I noticed that in Karl's script to start keychain:
 http://sourceware.org/ml/cygwin/2004-03/msg00167.html
that he removes any /tmp/ssh-* pre-existing and presumed
stale directories left over by dead ssh-agent processes
and this assumes that there is only one ssh-agent per machine.
Not as good as actually getting rid of the source of the
zombie directories.
Actually, it does not assume that there is only one ssh-agent process 
per machine. I routinely use it with ssh-agents processes for multiple 
users. The files for other users are protected so that they can not be 
deleted. Thus, only the current user's tmp files are deleted.

I'm in the process of doing some clean-up work and trying out keychain 
2.5.1. I am also adding ${HOSTNAME}.cmd file creation for use with 
Windows shell scripts. If there is interest, perhaps I should offer to 
maintain keychain, with additional support for launching it from a 
service. Launching keychain from a service allows the ssh-agent process 
to survive logout, so you only type a passphrase once per reboot instead 
of once per login.

Thanks,
...Karl
Ah, I see.  I had assumed that persons logged in with Administrator
privileges would blow them all away.
Having the service seems like a nice arrow in the quiver.
I don't think I would want my personal keyring to persist
across my sessions, though.  Kind of like leaving the key
in the car ignition while parked.  I can see that it could be
useful for daemon processes though.
Jim
--
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: ssh-agent and /tmp/ssh-* removal at logout

[Jim Kleckner]

Corinna Vinschen wrote:
On Feb 23 06:18, Jim Kleckner wrote:
ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
[snip]
But it's correct behaviour.  A forcefully killed process usually isn't
in the shape to make cleanup tasks.
Corinna
I guess a better way of phrasing my question would be:
Many Windows applications receive a notification on logout or
shutdown that allows them to take an action prior to being
killed (including dialogs with the user).  Is there any practical
way to use this for ssh-agent (or other cygwin processes)?
For example, could the cygwin subsystem receive this notification
and send a SIGHUP to the process?  I'm guessing that the
answer is that it is not practical.
Jim
--
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/

ssh-agent and /tmp/ssh-* removal at logout

[Jim Kleckner]

ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
Jim
I noticed that in Karl's script to start keychain:
 http://sourceware.org/ml/cygwin/2004-03/msg00167.html
that he removes any /tmp/ssh-* pre-existing and presumed
stale directories left over by dead ssh-agent processes
and this assumes that there is only one ssh-agent per machine.
Not as good as actually getting rid of the source of the
zombie directories.
--
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/

gcc bounds checking, valgrind, purify

[Jim Kleckner]

Bill Priest wrote:
Jim & All,
  I've successfully built and used cygwin 3.3.1 with
Herman Ten Brugge's bounds checking patches.  I've
submitted the trivial changes required for cygwin back
to Herman.
  You can google for Herman Ten Brugge and find a
reference to the changes I made to get them to work
w/ cygwin.
  Of course it only works w/ 'C'; but I used it to
track down array indexing problems and pointer
problems.
 

Very interesting.  Checking out those links, it appears
that these patches are very much like a static version
of Valgrind.  Valgrind works dynamically with an x86
code rewriter that appears to be language independent
and seems to implement a lot of the difficult functionality
that the original Purify implemented.  Valgrind ought
to work with C++ where gcc-bounds-checking as you
say is only 'C' (though there are some traces in
These patches have been around for 10 years (!).
This kind of test is so valuable, I'm surprised that
they have never been integrated into gcc.  It seems
like it isn't such a big risk to include them and
config them to be off by default.  This would
hugely improve the maintainability and availability
of the patches.
Did your cygwin patches get into bounds checking
patch for the 3.4.2-100 version of 7-Sep-2004 ?
It does look so from the source.
Would it be reasonable integrate this patch into
the cygwin GCC?  I expect back the answer no,
because GCC needs to be synced with the upstream.
But this stuff would be so much more valuable if
(in order of accessibility):
- It was just part of GCC as an option
- It could be selectively installed as a package alternative
- The patches were integrated so that one could download
   and recompile.
There was a discussion here:
 http://www.cygwin.com/ml/cygwin/2003-11/msg00320.html
about the value of recompiling sort of a "super debug"
version of the cygwin dll and libraries with gcc-bounds-checking
that ran slowly but did a lot of checking.  That would indeed
be valuable. 

Jim
PS:  Please don't put my email address in the subject line.
Spam harvesters, you know.
PPS:  Convenience links for fellow travelers:
Good article giving the context and pointers:
http://www.network-theory.co.uk/articles/boundschecking.html
GCC extensions page:
http://gcc.gnu.org/extensions.html
Herman Ten Brugge pages with source:
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/
Alternate (main?) source of the patches:
http://sourceforge.net/projects/boundschecking/
Valgrind home page:
http://valgrind.kde.org/

--
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: Limitation in SCP?

[Jim Kleckner]

Corinna Vinschen wrote:
On Dec 13 14:37, Bob Smart wrote:
I've discovered that in some circumstances, scp seems to get tired
early when transferring a largish file (around 200MB).  It copies
diligently for the first 20-40MB (exactly where it stops varies
from run to run), then CPU usage drops to zero, the file stops
growing on the receiving end, there's no apparent network traffic,
and everything just pretty much halts.  A ps shows the scp task
running, but not doing anything.
I've only seen this when copying between two W2K machines (both
Cygwin, both using the Cygwin SSH package, both of pretty recent
vintage with DLL 1.5.11).  I did my development testing between
Linux and NT, and I never saw this behavior in that environment.
It always fails with the W2K machines.
I also never see this happen with tar.  If I do a tar-to-tar pipe
via SSH, everything works even in the W2K-to-W2K environment.
However, I'd like to understand why I can't use scp for this.

Hmm, that doesn't happen for me.  I tried to copy around a 200 Megs
file between WinXP and XP<->Linux multiple times and don't see any
hang.  Did you try with Cygwin 1.5.12, too?
Is this possibly related to the pipe hang issue that some
apps have with ssh such as mentioned here and that
Bob Byrnes is looking at?:
 http://sources.redhat.com/ml/cygwin/2004-11/msg01162.html
Bob, are you "pushing" or "pulling" the files?  It has
been noted that rsync works to push files to windows
but hangs in a similar way when pulling files from a
remote machine.  Again, it may or may not be related.
Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin-gcc-fopen bug?

[Jim Kleckner]

Lester Ingber wrote:
Jim:
Hi.   On Solaris9 I use leak and there are no leaks, and I see no errors
at all.
Valgrind implements an x86 interpreter and, among other things,
checks use of uninitialized memory or referencing outside of
allocated memory.  Dave's conjecture was that the problem was
of that type, I think, rather than a leak.
One of the errors on Cywin, using the most Current Cygwin1.dll occurs
before any memory is created, ner the top of main():
  if ((Portfolio->ptr_err = fopen (infoFile, "a")) == NULL) {
 ...
I believe you are using some C++ which may do lots
of things in static constructors called before main().
Now, I do have a large set of structs (mostly full of pointers for
memory to be created later in the program), e.g., several enum's with
about 40 entries, and several nested structs with about 225 entries,
in an include file common to about 50 .c files.  Could this be too
many for the Cygwin gcc default?
BTW, it is "NULL" that mangles the filename, not "NUL", likely
because I'm using sprintf() to string together paths and files.
Seems unlikely to be a capacity limit, but I'm not expert
in that area.  But a complex structure like that is just
the sort of thing that is likely to have an initialization
bug of some sort.
Your original post mentioned that your code would work with
-mno-cygwin.  If it will no longer work that way, it is
indicative that the problem is not a result of the cygwin
runtime...
Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin-gcc-fopen bug? (Purify, valgrind)

[Jim Kleckner]

Jim Kleckner wrote:
Dave Korn wrote: 
...
  Maybe we should try and port the free open-source equivalent valgrind
(http://valgrind.kde.org/) instead?  I haven't ever looked at this, 
but it ought
to be possible.  I note that you can use (a special variant version 
of) valgrind
to verify win32 apps running on WINE.  So I guess there's a 
long-way-round to do
that already

Interesting tool and it looks promising.
...
Without careful feature comparison, I can't be
sure, but I'll bet there are significant checks
that Purify does (if OCI is enabled) that Valgrind
does not do.
FWIW, these folks have done a detailed comparison:
http://tinyurl.com/4un5g
http://www.cs.wm.edu/~coppit/csci780-fall2003/final-papers/hewett-dipalma.pdf
Valgrind does indeed look competitive, although
the authors weren't too explicit about what
types of errors were found by one and not
the other.
Now, I wonder how hard it is to port...
Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin-gcc-fopen bug? (Purify)

[Jim Kleckner]

Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Jim Kleckner
Sent: 10 December 2004 19:01

We used to use Purify to find these sorts of problems
often just by running the program once.  Unfortunately
for us using cygwin, Purify appears to have moved toward
a firm dependence on VC.  Also, it is quite expensive.
...
  AAArrgh!  It's a Rational tool!  Oh no, run away!
I feel your angst!  Though Purify was orignally
created by Pure Software as an awesome and unique
tool (and they got a patent for the object code
insertion technique).  Pure was bought by Rational
which was bought by IBM...
Has anyone out there gotten either Purify
or BoundsChecker to work with Cygwin?
I'll wager that if you could, Purify would
pinpoint a lot of tricky issues extremely
quickly.  Maybe a tool to munge the symbol
table into VC-compatible form?
 
  Maybe we should try and port the free open-source equivalent valgrind
(http://valgrind.kde.org/) instead?  I haven't ever looked at this, but it ought
to be possible.  I note that you can use (a special variant version of) valgrind
to verify win32 apps running on WINE.  So I guess there's a long-way-round to do
that already
Interesting tool and it looks promising.
In the original implementation, Purify didn't
even need a symbol table to instrument code let
alone be compiled or linked with the program,
though meaningful messages depended on it.  The
tool understood the machine architecture and
modified the code in-place (thus object code
insertion).  You could do checking on static
or dynamic libraries from vendors with or
without their cooperation along with your own
code.  Very very nice and comprehensive.
Without careful feature comparison, I can't be
sure, but I'll bet there are significant checks
that Purify does (if OCI is enabled) that Valgrind
does not do.
Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin-gcc-fopen bug? (Purify)

[Jim Kleckner]

Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Lester Ingber
Sent: 10 December 2004 16:14
...
  Your code has a bug: a stray pointer or array overwrite that is trashing some
memory.  The only reason you get away with it on Solaris is by sheer luck;
either the stack or heap layout is different, or the random uninitialised
contents of a variable point somewhere harmless or something like that.
  Since you can see a NUL (heh, NULL != NUL you know!) appearing in the middle
of the name string, you could always set a gdb watchpoint on it to see exactly
when it gets stomped and what instruction is doing it.
We used to use Purify to find these sorts of problems
often just by running the program once.  Unfortunately
for us using cygwin, Purify appears to have moved toward
a firm dependence on VC.  Also, it is quite expensive.
However, since you say that you use Solaris you
may be able to use it on that platform.  Often,
the trial period is all you need to find that
pesky problem (and probably a host of others
in the process...).
 Info: http://tinyurl.com/54fg6
 Trial for Unix: http://tinyurl.com/6vle6
 Trial for Win: http://tinyurl.com/4t8mf
One concern is that I recall that they
may not be using their very strong
"object code insertion" technique on Unix
any longer and, without that, Purify becomes
fairly similar to BoundsChecker.
Has anyone out there gotten either Purify
or BoundsChecker to work with Cygwin?
I'll wager that if you could, Purify would
pinpoint a lot of tricky issues extremely
quickly.  Maybe a tool to munge the symbol
table into VC-compatible form?
Jim
--
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: STL std::random_shuffle behavior fails with lrand48

[Jim Kleckner]

Arturus Magi wrote:
Jim Kleckner wrote:
Version of cygwin is current (see attached file
for all version stamps)
gcc 3.3.1-3
gcc-g++ 3.3.1-3
version of gcc/g++ on Linux is 2.96.
The test program is attached as is cygcheck output.
To run it just type (note that -mno-cygwin is *not* used):
g++ xxx.cpp
./a.exe
Is this a configuration issue?  Or does lrand48 not work?
Or is it a long vs. int type mismatch?
Try upgrading the version of gcc on the Linux box before comparing. 
There are a number of differences between gcc2 and gcc3 that may be 
affecting things.
This succeeds on an up to date Gentoo system.
So the problem appears to be local to cygwin.
=== From a gentoo user:
My gcc and g++ versions are 3.3.3 20040412.
[EMAIL PROTECTED] reid]$ g++ xxx.cpp
[EMAIL PROTECTED] reid]$ ./a.out
changes before:
0 1 2 3 4 5 6
changes after:
1 4 2 3 5 6 0
changes after:
0 6 2 1 4 5 3
changes after:
0 1 3 6 5 4 2
--
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: STL std::random_shuffle behavior fails with lrand48 (workaround)

[Jim Kleckner]

Arturus Magi wrote:
Jim Kleckner wrote:
Version of cygwin is current (see attached file
for all version stamps)
gcc 3.3.1-3
gcc-g++ 3.3.1-3
version of gcc/g++ on Linux is 2.96.
The test program is attached as is cygcheck output.
To run it just type (note that -mno-cygwin is *not* used):
g++ xxx.cpp
./a.exe
Is this a configuration issue?  Or does lrand48 not work?
Or is it a long vs. int type mismatch?
Try upgrading the version of gcc on the Linux box before comparing. 
There are a number of differences between gcc2 and gcc3 that may be 
affecting things.
It is not possible to upgrade that server in order
to confirm that the bug is general to gcc3.
If someone else could demonstrate that
the bug exists on other platforms, I would
be grateful.
For other people who run into this, I found that
substituting rand() for lrand48() works around
this problem.  Add this code ahead of the includes
of  and so forth.
Not pretty but it removed the roadblock.
Jim
// This lrand48() hack is a workaround for cygwin lrand48()
extern "C" long int lrand48();
extern "C" int rand();
long int lrand48()
{
return rand();
}
--
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/

STL std::random_shuffle behavior fails with lrand48

[Jim Kleckner]

Attached is a simple test case of std::random_shuffle() that
gives different answers on cygwin and RH Linux.  Note that
the output looks like a simple circular rotation on cygwin
but works correctly on RH 7.2.  The problem appears to be
the implementation of lrand48().  If you undefine:
 #undef _GLIBCPP_HAVE_DRAND48
then it works consistently.
On cygwin output is:
changes before:
0 1 2 3 4 5 6
changes after:
6 0 1 2 3 4 5
changes after:
5 6 0 1 2 3 4
changes after:
4 5 6 0 1 2 3

on RH7.2 output is:
changes before:
0 1 2 3 4 5 6
changes after:
1 4 2 3 5 6 0
changes after:
0 6 2 1 4 5 3
changes after:
0 1 3 6 5 4 2
=
Version of cygwin is current (see attached file
for all version stamps)
gcc 3.3.1-3
gcc-g++ 3.3.1-3
version of gcc/g++ on Linux is 2.96.
The test program is attached as is cygcheck output.
To run it just type (note that -mno-cygwin is *not* used):
g++ xxx.cpp
./a.exe
Is this a configuration issue?  Or does lrand48 not work?
Or is it a long vs. int type mismatch?
Jim

Cygwin Configuration Diagnostics
Current System Time: Fri Jul 30 16:30:23 2004

Windows XP Professional Ver 5.1 Build 2600 Service Pack 1

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\WinUnix\vim\vim63b
c:\jim\bin
c:\java\j2sdk14\bin
c:\Program Files\Common Files\GTK\2.0\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1005(jim) GID: 513(None)
513(None)  545(Users)

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

SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS

CYGWIN = `ntsec'
HOME = `c:\Jim'
PWD = `/cygdrive/c/Jim/Consult/VMI/Programs'

Use `-r' to scan registry

c:  hd  NTFS   57215Mb  95% CP CS UN PA FC 
e:  cd  CDFS 589Mb 100%CS UN   TOPO_US_EAST

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

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

   61k 2003/08/09 C:\cygwin\bin\cygbz2-1.dll
   54k 2002/01/27 C:\cygwin\bin\cygbz21.0.dll
   18k 2004/07/06 C:\cygwin\bin\cygcharset-1.dll
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll
  841k 2004/03/17 C:\cygwin\bin\cygcrypto-0.9.7.dll
  645k 2003/04/11 C:\cygwin\bin\cygcrypto.dll
  617k 2004/03/22 C:\cygwin\bin\cygcurl-2.dll
   22k 2004/02/10 C:\cygwin\bin\cygcygipc-2.dll
  380k 2002/07/24 C:\cygwin\bin\cygdb-3.1.dll
  831k 2003/09/20 C:\cygwin\bin\cygdb-4.1.dll
  895k 2004/04/28 C:\cygwin\bin\cygdb-4.2.dll
  487k 2002/07/24 C:\cygwin\bin\cygdb_cxx-3.1.dll
 1080k 2003/09/20 C:\cygwin\bin\cygdb_cxx-4.1.dll
 1156k 2004/04/28 C:\cygwin\bin\cygdb_cxx-4.2.dll
  155k 2004/01/07 C:\cygwin\bin\cygexpat-0.dll
   71k 2004/01/13 C:\cygwin\bin\cygexslt-0.dll
  129k 2004/03/11 C:\cygwin\bin\cygfontconfig-1.dll
   45k 2001/04/25 C:\cygwin\bin\cygform5.dll
   35k 2002/01/09 C:\cygwin\bin\cygform6.dll
   48k 2003/08/09 C:\cygwin\bin\cygform7.dll
  361k 2003/10/25 C:\cygwin\bin\cygfreetype-6.dll
   28k 2003/07/20 C:\cygwin\bin\cyggdbm-3.dll
   30k 2003/08/11 C:\cygwin\bin\cyggdbm-4.dll
   19k 2003/03/22 C:\cygwin\bin\cyggdbm.dll
   15k 2003/07/20 C:\cygwin\bin\cyggdbm_compat-3.dll
   15k 2003/08/11 C:\cygwin\bin\cyggdbm_compat-4.dll
  349k 2003/12/08 C:\cygwin\bin\cygGraphicsMagick++-0.dll
 2169k 2003/12/08 C:\cygwin\bin\cygGraphicsMagick-0.dll
 1506k 2003/11/05 C:\cygwin\bin\cyggsl-0.dll
  190k 2003/11/05 C:\cygwin\bin\cyggslcblas-0.dll
  489k 2003/08/09 C:\cygwin\bin\cygguile-12.dll
  489k 2003/07/28 C:\cygwin\bin\cygguile-12abi13.dll
   24k 2003/08/09 C:\cygwin\bin\cygguile-ltdl-1.dll
   24k 2003/07/28 C:\cygwin\bin\cygguile-ltdl-1abi13.dll
   62k 2003/08/09 C:\cygwin\bin\cygguile-srfi-srfi-13-14-v-1-1.dll
   62k 2003/07/28 C:\cygwin\bin\cygguile-srfi-srfi-13-14-v-1-1abi13.dll
   23k 2003/08/09 C:\cygwin\bin\cygguile-srfi-srfi-4-v-1-1.dll
   23k 2003/07/28 C:\cygwin\bin\cygguile-srfi-srfi-4-v-1-1abi13.dll
   11k 2003/08/09 C:\cygwin\bin\cygguilereadline-v-12-12.dll
   11k 2003/07/28 C:\cygwin\bin\cygguilereadline-v-12-12abi13.dll
   17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll
   29k 2003/08/10 C

Re: Most mirrors don't have md5.sum for setup.exe

[Jim Kleckner]

Brian Dessent wrote:

Jim Kleckner wrote:

I noticed that the mirror site that I am using
via rsync:
  rsync://mirrors.kernel.org/sources.redhat.com/cygwin/
lost the md5.sum file some time ago (2-3 months?).


*at the top level*


An informal and incomplete check of sites from
  http://cygwin.com/mirrors.html
indicates these sites have the md5.sum file:
  http://www.online-mirror.org/cygwin/
  http://cygwin.get-software.com/


http://cygwin.get-software.com/md5.sum


and these sites do not have the md5.sum file:
  http://mirrors.kernel.org/sources.redhat.com/cygwin/
  http://cygwin.thehostedbox.com/
  http://sigunix.cwru.edu/pub/cygwin/ftp/
  http://mirrors.theonlinerecordstore.com/cygwin/
  http://sources-redhat.mirrors.redwire.net/cygwin/
  http://cygwin.matrix.com.br/
  http://ftp.univie.ac.at/packages/cygwin/
  http://mirror.cpsc.ucalgary.ca/mirror/cygwin.com/
Should it be at every site?

I don't understand what you mean by "the" md5.sum file.  There is a md5
file for every package.  If you open
<http://mirrors.kernel.org/sources.redhat.com/cygwin/> and traverse into
the release subdirectory and look at any package dir, there is a md5.sum
file with timestamp corresponding to the same date as the packages.  In
other words, I don't see anything wrong.
Brian
Yes, I know that.

The original message could have had the phrase
"at the top level" though I thought, obviously
incorrectly, that the explicit path to the
containing directory would be clear.
Click on this link to see the existing file:
  http://cygwin.get-software.com/md5.sum
or this one to see that it is missing:
  http://mirrors.kernel.org/sources.redhat.com/cygwin/md5.sum
This is the md5.sum file for setup.exe, setup.ini etc.

Note that the file mod times are "fresh" in those
sites that have it.
Jim

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

Most mirrors don't have md5.sum

[Jim Kleckner]

I noticed that the mirror site that I am using
via rsync:
  rsync://mirrors.kernel.org/sources.redhat.com/cygwin/
lost the md5.sum file some time ago (2-3 months?).
An informal and incomplete check of sites from
  http://cygwin.com/mirrors.html
indicates these sites have the md5.sum file:
  http://www.online-mirror.org/cygwin/
  http://cygwin.get-software.com/
and these sites do not have the md5.sum file:
  http://mirrors.kernel.org/sources.redhat.com/cygwin/
  http://cygwin.thehostedbox.com/
  http://sigunix.cwru.edu/pub/cygwin/ftp/
  http://mirrors.theonlinerecordstore.com/cygwin/
  http://sources-redhat.mirrors.redwire.net/cygwin/
  http://cygwin.matrix.com.br/
  http://ftp.univie.ac.at/packages/cygwin/
  http://mirror.cpsc.ucalgary.ca/mirror/cygwin.com/
Should it be at every site?

Thanks - Jim

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

Re: [ANNOUNCEMENT] Updated: gcc 3.3.3-1, gcc-mingw-20030911-2 missing java headers

[Jim Kleckner]

Christopher Faylor wrote:

On Fri, Oct 03, 2003 at 07:07:54PM -0700, Jim Kleckner wrote:

Is it possible the java code simply wasn't configured to build?
All of the java headers are missing.
Christopher Faylor wrote:


I've moved all of the latest gcc stuff out of "test" and into "current".
This is the standard gcc 3.3.1 release from gcc.gnu.org + patches from
Danny Smith and (to a vastly lesser extent) me.  If you are interested
in checking these sources out of gcc's cvs repository, the branch tag is
cygming331.  But, please, no questions about where to go or how to do
that on the cygwin list.  Go to gcc.gnu.org for that kind of info.
[snip]


There were vague reports of gcj being broken during the gcc test period
but I never saw a true bug report for this.  Since I'm not a java user,
I can only provide this as-is.
Here are the things I looked at:

So, you checked everything but the release announcement which said:

"There were vague reports of gcj being broken during the gcc test period
but I never saw a true bug report for this.  Since I'm not a java user,
I can only provide this as-is."


I see.  You only appeared to invite investigation.
This gcc announcement page that I referenced in my first email
said nothing about gcj or java problems.
 http://gcc.gnu.org/gcc-3.3/changes.html
I did substantial searching, downloading and recompiling.
But all you can do is to write it off with a flip comment.
These kinds of responses are very discouraging to people

who want to help.



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

Re: [ANNOUNCEMENT] Updated: gcc 3.3.3-1, gcc-mingw-20030911-2 missing java headers

[Jim Kleckner]

Jim Kleckner wrote:

...
I tried uncompressing, configuring, and "make" of gcc.
Recompiling and installing 3.3.1-1 fails to install the headers.
Subsequent uncompress, configure, recompile of 3.2-3 failed
to compiler.
To be clear, the install ofo 3.3.1-1 succeeds but it doesn't appear
that the include files are installed into /usr/local/include (the
default location?).  gcc is a complex install to say the least...
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: gcc 3.3.3-1, gcc-mingw-20030911-2 missing java headers

[Jim Kleckner]

Is it possible the java code simply wasn't configured to build?
All of the java headers are missing.
Christopher Faylor wrote:

I've moved all of the latest gcc stuff out of "test" and into "current".
This is the standard gcc 3.3.1 release from gcc.gnu.org + patches from
Danny Smith and (to a vastly lesser extent) me.  If you are interested
in checking these sources out of gcc's cvs repository, the branch tag is
cygming331.  But, please, no questions about where to go or how to do
that on the cygwin list.  Go to gcc.gnu.org for that kind of info.
[snip]

There were vague reports of gcj being broken during the gcc test period
but I never saw a true bug report for this.  Since I'm not a java user,
I can only provide this as-is.


Here are the things I looked at:

A quick look at:
 http://www.cygwin.com/packages/gcc/gcc-3.2-3
shows usr/include/java/... are installed but
 http://www.cygwin.com/packages/gcc/gcc-3.3.1-2
shows none of that.  Although it does include usr/bin/gcj.exe
which suggests it was configured to build.
It also suggests that I have the right packages
unless some breakup of gcc has put those files elsewhere.
Haven't seen anything on that and searching cygwin.com
packages doesn't reveal anything.
Checking the change logs for gcc:
 http://gcc.gnu.org/gcc-3.3/changes.html
Doesn't indicate any issues with Java.
Extracting the source of both versions and comparing
some of the configure files doesn't reveal any disabling
of gcj and java.
I tried uncompressing, configuring, and "make" of gcc.
Recompiling and installing 3.3.1-1 fails to install the headers.
Subsequent uncompress, configure, recompile of 3.2-3 failed
to compiler.
Checking the gcc java list
 http://gcc.gnu.org/ml/java/
doesn't reveal (to me) the answer.
Gerrit, do you know since you have the most relevant
posts on the gcc/java list?
Reverting to the previous install works.

Thanks for any pointers.

Jim

--
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: Available for test: cygwin-1.5.0-1

[Jim Kleckner]

I am really batting 0, apologies.  I searched for Nigel rather than N. 
Stephens.  Sheesh.

--
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: Available for test: cygwin-1.5.0-1

[Jim Kleckner]

It would be very nice to get Nigel Stephens select patch
into a test release:
 http://sources.redhat.com/ml/cygwin/2003-07/msg00254.html
This was the one where the socket connect state was not being
mainained across a fork.  Or is this corrected in another way?
Jim

Christopher Faylor wrote:

I've made a new version of the Cygwin DLL and associated utilities
available for download.  As usual, a list of what has changed is below.


--
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: Source for upset package

[Jim Kleckner]

Igor Pechtchanski wrote:


FYI, the cvsweb.cgi script produces a chooser box at the top of the page
which allows you to select the CVS Root without hand-editing the URL.
Igor


Holy cow, I must have been still asleep that morning, sheesh!
  Thanks again - Jim


--
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: Source for upset package

[Jim Kleckner]

Igor Pechtchanski wrote:

On Thu, 3 Jul 2003, Jim Kleckner wrote:

I see references to a package called upset to
manage the creation of release areas.  I looked
searched vigorously on cygwin-apps and cygwin
lists and looked through the site including the
pointer to the CVS web link and didn't find it.
Also downloaded and extracted the setup source
and searched for scripts and make targets.
There is an "inilint" program but that just
appears to check ini files.
Would someone mind pointing to any existing
documentation on upset and how setup.ini
is constructed?  Where is the source for it?
Apologies if I somehow missed it.

Thanks - Jim

A Google search for "cygwin upset cvs" returned
<http://www.cygwin.com/ml/cygwin-apps/2002-07/msg00175.html> as the first
match...


Igor, thanks for the pointers.

I was using the mailing list htdig search facility which doesn't perform 
nearly so well as Google:

http://cygwin.com/cgi-bin/htsearch?method=and&format=builtin-long&sort=time&config=htdig&restrict=%2Fml%2Fcygwin-apps%2F&words=upset+cvs

Compare this with:

 http://www.google.com/search?hl=en&q=cygwin+upset+cvs

In particular, the summaries don't give you a good idea of the content. 
 Should users be directed away from the htdig searching?  Or even 
better, just use Google to do the searching within cygwin.com.  I 
obviously wasted considerable time in the wrong maze when I would 
normally have used Google.

Also, note that if there had been a link in this page:
 http://cygwin.com/cvs.html
to this location:
 http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=sourceware
then it would have been possible to find it by looking at the 
repository.  After the hint from the email posting, I guessed the 
possibility of going "up" the cvs tree and hand edited the link
which is how I got to this page.  Not the most direct route.

Just trying to help other travellers.

Jim





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

Source for upset package

[Jim Kleckner]

I see references to a package called upset to
manage the creation of release areas.  I looked
searched vigorously on cygwin-apps and cygwin
lists and looked through the site including the
pointer to the CVS web link and didn't find it.
Also downloaded and extracted the setup source
and searched for scripts and make targets.
There is an "inilint" program but that just
appears to check ini files.
Would someone mind pointing to any existing
documentation on upset and how setup.ini
is constructed?  Where is the source for it?
Apologies if I somehow missed it.

Thanks - Jim

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

Request for list links in left side navbar

[Jim Kleckner]

I would be grateful if you would add one or two links
to the "Mailing lists" item in the left-side navbar
that takes one directly to the cygwin mailing list page.
Say for example:
 Mailing lists (cygwin, apps)
where "Mailing lists" points to
  http://cygwin.com/lists.html  (as it now does)
and cygwin points to
  http://cygwin.com/ml/cygwin/
and apps points to
  http://cygwin.com/ml/cygwin-apps/
It would shorten the distance to the mailing
list search pages nicely.
Thanks - Jim

--
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: rxvt dialog at shutdown suggests failure to exit due to ssh-agent?

[Jim Kleckner]

Thank you for the suggestion.

David Starks-Browning wrote:


On Wednesday 19 Feb 03, Jim Kleckner writes:

[snip]

If *all* shells source that line, then you have the problem that the
first one to exit will kill ssh-agent, and maybe you don't want that.
You could put something a bit more sophisticated in your .bash_profile
(or whatever) to identify a "master" shell, depending on your
requirements.


Unfortunately, this is exactly what keychain is for -
to start the agent in one shell and then share access
from many shells.  I start up and shut down many rxvt/bash
shells during the day without having to provide my
passphrase.  Stopping the agent with keychain is easy by
just typing "keychain -k".  I forget to do that just
about every time.

This is not a big problem.  I just thought someone
might know how to "strongly detach" the process while
at the same time allowing stdin interaction for the
passphrase.

Jim


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

rxvt dialog at shutdown suggests failure to exit due to ssh-agent?

[Jim Kleckner]

Consistently when I shutdown Win2K I get a dialog
asking to end an rxvt process:
   End Program: rxvt0510
   Windows cannot end this program.  It may need
   more time to complete an operation. ...
   End Now/Cancel

I launch rxvt via an rxvt.lnk that contains
the following as the "Target":
  C:\cygwin\bin\rxvt.exe -e bash.exe -i
I typically launch two instances of rxvt so
that I can toggle from one to the other.  Prior
to shutdown, I type exit into each shell and the
window closes.  Inspection via "ps" and the "task
manager" show no processes with rxvt in the name
after these exits.  I use keychain and ssh-agent
is still running.  If I shut down ssh-agent
with "keychain -k" prior to exiting the bash
shells, then shutdown proceeds properly.

Is there a way for keychain to launch ssh-agent
such that it doesn't cause this hang?
It currently invokes ssh-agent with:
  nohup ssh-agent -s | grep -v 'Agent pid' > "$pidf"

Thanks - Jim

=== cygcheck -s output:

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Feb 19 09:28:55 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3

Path:
C:\cygwin\bin
	c:\java\ptII2.0.1\bin
	c:\java\j2sdk14\bin
	c:\java\j2sdk14\jre\bin
	c:\WINNT\system32
	c:\WINNT
	c:\WINNT\System32\Wbem
	c:\Jim\bin
	c:\Program Files\Perforce
	c:\WinUnix\bin

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

HOME = `c:\Jim'
PWD = `/cygdrive/c/Jim'

Use `-r' to scan registry

c:  hd  NTFS   19053Mb  74% CP CS UN PA FC

.  /cygdrive user
textmode,cygdrive
C:\cygwin  / system
textmode
c: /cygdrive/c   system
textmode
C:\cygwin/bin  /usr/bin  system
textmode
C:\cygwin/lib  /usr/lib  system
textmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive system
textmode,cygdrive

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

58k 2002/05/07 C:\cygwin\bin\cygbz2-1.dll
 6k 2002/06/24 C:\cygwin\bin\cygcharset-1.dll
   847k 2003/01/09 C:\cygwin\bin\cygcrypto-0.9.7.dll
   644k 2002/12/08 C:\cygwin\bin\cygcrypto.dll
   136k 2002/10/17 C:\cygwin\bin\cygexpat-0.dll
50k 2002/03/17 C:\cygwin\bin\cygexslt-0.dll
45k 2001/04/25 C:\cygwin\bin\cygform5.dll
35k 2002/01/09 C:\cygwin\bin\cygform6.dll
19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll
   490k 2002/09/21 C:\cygwin\bin\cygguile-12.dll
   488k 2002/07/18 C:\cygwin\bin\cygguile-14.dll
63k 2002/07/18 C:\cygwin\bin\cygguile-srfi-srfi-13-14-1.dll
63k 2002/09/21 C:\cygwin\bin\cygguile-srfi-srfi-13-14-v-1-1.dll
24k 2002/07/18 C:\cygwin\bin\cygguile-srfi-srfi-4-1.dll
24k 2002/09/21 C:\cygwin\bin\cygguile-srfi-srfi-4-v-1-1.dll
14k 2002/07/18 C:\cygwin\bin\cygguilereadline-14.dll
14k 2002/09/21 C:\cygwin\bin\cygguilereadline-v-12-12.dll
17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll
20k 2002/10/10 C:\cygwin\bin\cyghistory5.dll
   306k 2002/04/27 C:\cygwin\bin\cyghttpd.dll
   929k 2002/06/24 C:\cygwin\bin\cygiconv-2.dll
22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll
28k 2002/09/20 C:\cygwin\bin\cygintl-2.dll
21k 2001/06/20 C:\cygwin\bin\cygintl.dll
   119k 2002/02/09 C:\cygwin\bin\cygjpeg6b.dll
59k 2002/09/20 C:\cygwin\bin\cygkpathsea-3-3-7.dll
32k 2003/01/04 C:\cygwin\bin\cygltdl-3.dll
26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll
20k 2002/01/09 C:\cygwin\bin\cygmenu6.dll
   156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll
   175k 2002/01/09 C:\cygwin\bin\cygncurses++6.dll
   226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll
   202k 2002/01/09 C:\cygwin\bin\cygncurses6.dll
15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll
12k 2002/01/09 C:\cygwin\bin\cygpanel6.dll
40k 2001/11/21 C:\cygwin\bin\cygpcre.dll
39k 2001/11/21 C:\cygwin\bin\cygpcreposix.dll
   175k 2002/07/22 C:\cygwin\bin\cygpng10.dll
   179k 2002/07/22 C:\cygwin\bin\cygpng12.dll
22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll
   108k 2001/06/28 C:\cygwin\bin\cygreadline4.dll
   127k 2002/10/10 C:\cygwin\bin\cygreadline5.dll
66k 2001/11/20 C:\cygwin\bin\cygregex.dll
   177k 2003/01/09 C:\cygwin\bin\cygssl-0.9.7.dll
   165k 2002/12/08 C:\cygwin\bin\cygssl.dll
   253k 2002/02/10 C:\cygwin\bin\cygtiff3.dll
   633k 2002/07/22 C:\cygwin\bin\cygxml2-2.dll
   152k 2002/03/17 C:\cygwin\bin\cygxslt-1.dll
15k 2002/03/17 C:\cygwin\bin\cygxsltbreakpoint-1.dll
50k 2002/03/12 C:\cygwin\bin\cyg

Re: Cygwin Release process

[Jim Kleckner]

Larry Hall (RFK Partners, Inc) wrote:


At 09:54 PM 1/30/2003, Jim Kleckner wrote:

[snip ]

Thanks!  While you have the code in hand, would it be
possible to allow the setup window to be resized?
I'm constantly wanting to see more lines at once...


Have you been reading the email archives?  I think I've heard 
that request before! :-)

I see the answer here:
http://sources.redhat.com/ml/cygwin/2002-11/msg00309.html

Sorry to duplicate.  I guess every single thing needs to be searched
before replying...

Jim


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Release process

[Jim Kleckner]

Max Bowsher wrote:


William A. Hoffman wrote:

[snip]

2. Failing that, it would be nice if the setup program had a button that
set all the values to Keep.   The problem is that if I want a new
package X, I have to click 20 other packages to Keep, or risk an
update of everything. There should be a way to update one single
package.   Is there a way?


It's in CVS. The next snapshot will have it.

Max.


Thanks!  While you have the code in hand, would it be
possible to allow the setup window to be resized?
I'm constantly wanting to see more lines at once...

Thanks again - Jim


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Consistent usage of "black on white" colors in terminal

[Jim Kleckner]

I see, very nice!  The synopsis with "for the X window system" led me 
astray and prevented me from looking at it.

Some mention of this would be very good to put in the documentation here:
  http://cygwin.com/cygwin-ug-net/setup-files.html

Just a mention that rxvt is a good alternative for the default windows 
terminal emulator and that it doesn't require X on Windows but works
with it if present.

Thanks!  Jim

Lapo Luchini wrote:

Jim Kleckner wrote:


Have a look at the man page and my .Xdefaults[1]...



Thank you for the suggestion. I'm currently using the bare cmd.exe of 
Win2k and didn't want to have to start X11 just to get a terminal 
emulator.  It seems heavy - is this really necessary?  There is 
probably some magic thing to say in inputrc or terminfo to specify 
these colors but it has been 20 years since I waded into 
termcap/terminfo.  The manual mentions set_foreground and 
set_background but it requires a lot of digging to sort out.  I was 
hoping someone could point the way or say "there be dragons". 


Cygwin's rxvt port is quite cool, actually: can BOTH run with and 
without X11.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Consistent usage of "black on white" colors in terminal

[Jim Kleckner]

Thorsten Kampe wrote:


* Jim Kleckner (03-01-21 21:17 +0100)


I have mostly gotten my bash colors to display properly with black on white
which I find considerably more pleasing than white on black [...]

Programs like info, man, and cpan, however, do not know about these switched
default colors.



I have switched to rxvt because of color problems with IPython and 
haven't turned back.

Have a look at the man page and my .Xdefaults[1]...


Thank you for the suggestion.  

I'm currently using the bare cmd.exe of Win2k and didn't want to have to 
start X11 just to get a terminal emulator.  It seems heavy - is this 
really necessary?  There is probably some magic thing to say in inputrc 
or terminfo to specify these colors but it has been 20 years since I 
waded into termcap/terminfo.  The manual mentions set_foreground and 
set_background but it requires a lot of digging to sort out.  I was 
hoping someone could point the way or say "there be dragons".

Jim



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Consistent usage of "black on white" colors in terminal

[Jim Kleckner]

I promise that I have searched a whole bunch to
find the answer to this question.  I would be
happy just to get pointers in the right direction
to look.  It appears that some programs use
termcap and some use terminfo.

I have mostly gotten my bash colors to display
properly with black on white which I find
considerably more pleasing than white on black
(the default cmd.exe colors).  One does this by
just creating a shortcut to the cygwin.bat file,
right-click on properties on the shortcut, and
setting the colors and layout.

Programs like info, man, and cpan, however, do not
know about these switched default colors.  Trying
to eliminate color altogether also doesn't seem to
work.  Try setting TERM=ansi-mono, invoke a bash
subshell just for good luck, then type "man man"
and notice the continued use of color and
invisible white on white highlighted text.

Has anyone done this successfully and can you give
a pointer to the documentation to do this?

Many thanks - Jim



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: RESOLVED: Using gcc to build a DLL discovered and linked at runtime

[Jim Kleckner]

Christopher Faylor wrote:


On Fri, Jan 17, 2003 at 06:58:17AM -0800, Joshua Daniel Franklin wrote:


MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

References: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>


After carefully inspecting the symbols from
generated dlls and dlls provided by TradeStation,
I found that symbols occurred with and without the
@decorations.  e.g. PPI@4 and PPI.

Adding -Wl,--add-stdcall-alias to the gcc line,
all worked fine.

Could this generally be a requirement for dlls
that are opened at runtime in a fashion similar to
dlopen?  If so, then some FAQ annotation would be
in order here:
 http://www.cygwin.com/cygwin-ug-net/dll.html


I may be wrong (I'm not a GCC expert), but isn't that more
of a gcc thing than a cygwin thing? 

I don't want to end up pasting the whole gcc manual into
the "Using DLLs" page. It's really only intended to be a quick
start for cygwin, not a comprehensive guide.


Right.  The --add-stdcall-alias option is also not something
that you just nonchantly add to the command line.  It does not
belong in a general guide, except, perhaps as a q.v.



I defer to your judgement here.  I would note that
it took me a lot of digging to come up with the
solution.  One small hint to others might save
them a boatload of time.  Something like:

 "When programs discover and open a dll at
 runtime be sure to check that the symbols are
 generated in the form expected by the program.
 Take a look at the documentation for ld about
 the --add-stdcall-alias and --kill-at options
 that control whether the 'ordinal number' is
 output as part of the symbol or not."
in this page: http://www.cygwin.com/cygwin-ug-net/dll.html

I didn't find any information on this question by
top-down inspection of the GCC manual which does
not give much discussion of Windows-specific
features.  Instead it refers readers to cygwin
where I suspect most seekers will travel.  A site
search of gcc.gnu.org yields nothing for
add-stdcall-alias or kill-at.  It appears that
only the binutils package documentation for ld and
dlltool mention it.  For completeness, the
suggestion for the binutils team would be to
augment the documentation about these options for
ld to include:

   `-k'
   `--kill-at'
Specifies that when `dlltool' is creating the
exports file it should not append the string
`@ '.  These numbers are called
ordinal numbers and they represent another
way of accessing the function in a DLL, other
than by name.
 Append this text:
When programs discover and open a dll at
runtime be sure to check that the symbols
are generated in the form with or without
ordinals as expected by the program.  Try
this option or the --add-stdcall-alias
option if dynamic loading fails at runtime.

If some kind reader might forward this message to
the binutils team's list, I would be grateful as I
am not a member.

Thanks - Jim



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: RESOLVED: Using gcc to build a DLL discovered and linked at runtime

[Jim Kleckner]

After carefully inspecting the symbols from
generated dlls and dlls provided by TradeStation,
I found that symbols occurred with and without the
@decorations.  e.g. PPI@4 and PPI.

Adding -Wl,--add-stdcall-alias to the gcc line,
all worked fine.

Could this generally be a requirement for dlls
that are opened at runtime in a fashion similar to
dlopen?  If so, then some FAQ annotation would be
in order here:
 http://www.cygwin.com/cygwin-ug-net/dll.html

Jim


Jim Kleckner wrote:


 I'm using a program called TradeStation that allows
specifying a path name to a DLL, specifying the
signature of a function to call, and then
loading/calling that function.  The documentation is
very sparse for how to do this and probably built in
some way that depends in an obscure way on having a
Microsoft compiler such as VisualC++ or VisualBasic to
work properly.  I am trying to use GCC under cygwin to
create a DLL that will dynamically open and running
into roadblocks.

A simple test file test.cpp:
 #include "windef.h"
 extern int __stdcall PPI(int);

 __declspec(dllexport) int __stdcall PPI(int notused)
 {
 return 1;
 }

commands used:
 gcc -shared -mno-cygwin -Wl,--export-dynamic 
-Wl,--export-all-symbols  -c vmi.cpp
 dlltool -e exports.o vmi.o -l vmi.lib
 gcc -shared -mno-cygwin -Wl,--export-dynamic 
-Wl,--export-all-symbols  -shared exports.o vmi.o -o vmi.dll

The program just says "can't load user function".

I have tried various combinations of commands but am
wondering if there is something I'm missing.  I'm
hoping to avoid getting out the ancient copy of VC5
from my shelf...

I will append cyg

Thanks - Jim


Resources for future travelers down this path:

I have looked at a variety of sources describing
using cygwin/gcc tools to build DLLs.

The manual is here:
 http://www.cygwin.com/cygwin-ug-net/dll.html

This message contains a bug report with a complex
example that is interesting to examine:
 http://www.cygwin.com/ml/cygwin/2000-05/msg00663.html

This one describes a "ld/dlltool/ld/dlltool/ld trick":
 http://www.cygwin.com/ml/cygwin/2002-08/msg01002.html
It suggests that what I am trying to do should be
possible by just using the -shared flag.

Christopher Faylor indicates that the cygwin dll
cannot be linked at runtime because it is broken:
 http://www.cygwin.com/ml/cygwin/2002-08/msg01042.html

The dllhelpers stuff is also useful:
 http://www.neuro.gatech.edu/users/cwilson/cygutils/dll-stuff/index.html


[snip]




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Using gcc to build a DLL discovered and linked at runtime

[Jim Kleckner]

Larry Hall (RFK Partners, Inc) wrote:



I assume the reason you're using the -mno-cygwin flag is because of 
Chris's comment.  Clearly what you're trying to do won't work if you 
link against the Cygwin DLL.  Using -mno-cygwin should remove cygwin1.dll
from the equation but just substituting MSCVRT.DLL for cygwin1.dll doesn't
mean that MSCVRT.DLL will load dynamically either.  I dunno but judging
by the fact that you're still having troubles, the assumption is suspect.  
However, since you're no longer linking against cygwin1.dll (which isn't 
going to work), you're really just using the mingw pseudo cross compiler of 
Cygwin's gcc (the -mno-cygwin switch) to produce a straight Win32 DLL.  In 
this context, it's really not a Cygwin question anymore (you could use 
mingw's gcc and presumably see the same problem... if not, then maybe that's 
your solution).  I'd recommend following up on this at [EMAIL PROTECTED] 
if the mingw site doesn't have a solution for this problem.

Good luck,


Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX

Thank you for the pointers.  I downloaded mingw and it gives the same 
behavior.  I will ask the question on the mingw list.

Note that this example doesn't use cygwin or for that matter any 
functions at all.

Jim


#include "windef.h"
extern int __stdcall PPI(int);

__declspec(dllexport) int __stdcall PPI(int notused)
{
return 1;
}



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Using gcc to build a DLL discovered and linked at runtime

[Jim Kleckner]

 I'm using a program called TradeStation that allows
specifying a path name to a DLL, specifying the
signature of a function to call, and then
loading/calling that function.  The documentation is
very sparse for how to do this and probably built in
some way that depends in an obscure way on having a
Microsoft compiler such as VisualC++ or VisualBasic to
work properly.  I am trying to use GCC under cygwin to
create a DLL that will dynamically open and running
into roadblocks.

A simple test file test.cpp:
 #include "windef.h"
 extern int __stdcall PPI(int);

 __declspec(dllexport) int __stdcall PPI(int notused)
 {
 return 1;
 }

commands used:
 gcc -shared -mno-cygwin -Wl,--export-dynamic -Wl,--export-all-symbols  
-c vmi.cpp
 dlltool -e exports.o vmi.o -l vmi.lib
 gcc -shared -mno-cygwin -Wl,--export-dynamic -Wl,--export-all-symbols  
-shared exports.o vmi.o -o vmi.dll

The program just says "can't load user function".

I have tried various combinations of commands but am
wondering if there is something I'm missing.  I'm
hoping to avoid getting out the ancient copy of VC5
from my shelf...

I will append cyg

Thanks - Jim


Resources for future travelers down this path:

I have looked at a variety of sources describing
using cygwin/gcc tools to build DLLs.

The manual is here:
 http://www.cygwin.com/cygwin-ug-net/dll.html

This message contains a bug report with a complex
example that is interesting to examine:
 http://www.cygwin.com/ml/cygwin/2000-05/msg00663.html

This one describes a "ld/dlltool/ld/dlltool/ld trick":
 http://www.cygwin.com/ml/cygwin/2002-08/msg01002.html
It suggests that what I am trying to do should be
possible by just using the -shared flag.

Christopher Faylor indicates that the cygwin dll
cannot be linked at runtime because it is broken:
 http://www.cygwin.com/ml/cygwin/2002-08/msg01042.html

The dllhelpers stuff is also useful:
 http://www.neuro.gatech.edu/users/cwilson/cygutils/dll-stuff/index.html




Output of cygcheck -s:

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Jan 15 07:03:32 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3

Path: C:\cygwin\usr\local\bin
   C:\cygwin\bin
   C:\cygwin\bin
   C:\cygwin\bin
   c:\WINNT\system32
   c:\WINNT
c:\WINNT\System32\Wbem
   c:\Jim\bin
   c:\Program Files\Perforce
   c:\WinUnix\bin
C:\cygwin\usr\X11R6\bin

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

HOME = `c:\Jim '
MAKE_MODE = `unix'
USER = `jim'

Use `-r' to scan registry

c:  hd  NTFS   19053Mb  78% CP CS UN PA FC 
d:  cd   N/AN/A

.  /cygdrive user
textmode,cygdrive
C:\cygwin  / system  
textmode
c: /cygdrive/c   system  
textmode
C:\cygwin/bin  /usr/bin  system  
textmode
C:\cygwin/lib  /usr/lib  system  
textmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive user
textmode,cygdrive

Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\sh.exe

  58k 2002/05/07 C:\cygwin\bin\cygbz2-1.dll
   6k 2002/06/24 C:\cygwin\bin\cygcharset-1.dll
 847k 2003/01/09 C:\cygwin\bin\cygcrypto-0.9.7.dll
 644k 2002/12/08 C:\cygwin\bin\cygcrypto.dll
 136k 2002/10/17 C:\cygwin\bin\cygexpat-0.dll
  50k 2002/03/17 C:\cygwin\bin\cygexslt-0.dll
  45k 2001/04/25 C:\cygwin\bin\cygform5.dll
  35k 2002/01/09 C:\cygwin\bin\cygform6.dll
  19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll
 490k 2002/09/21 C:\cygwin\bin\cygguile-12.dll
 488k 2002/07/18 C:\cygwin\bin\cygguile-14.dll
  63k 2002/07/18 C:\cygwin\bin\cygguile-srfi-srfi-13-14-1.dll
  63k 2002/09/21 C:\cygwin\bin\cygguile-srfi-srfi-13-14-v-1-1.dll
  24k 2002/07/18 C:\cygwin\bin\cygguile-srfi-srfi-4-1.dll
  24k 2002/09/21 C:\cygwin\bin\cygguile-srfi-srfi-4-v-1-1.dll
  14k 2002/07/18 C:\cygwin\bin\cygguilereadline-14.dll
  14k 2002/09/21 C:\cygwin\bin\cygguilereadline-v-12-12.dll
  17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll
  20k 2002/10/10 C:\cygwin\bin\cyghistory5.dll
 306k 2002/04/27 C:\cygwin\bin\cyghttpd.dll
 929k 2002/06/24 C:\cygwin\bin\cygiconv-2.dll
  22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll
  28k 2002/09/20 C:\cygwin\bin\cygintl-2.dll
  21k 2001/06/20 C:\cygwin\bin\cygintl.dll
 119k 2002/02/09 C:\cygwin\bin\cygjpeg6b.dll
  59k 2002/09/20 C:\cygwin\bin\cygkpathsea-3-3-7.dll
  32k 2003/01/04 C:\cygwin\bin\cygltdl-3.dll
  26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll
  20k 2002/01/09 C:\cygwin\bin\cygmenu6.dll
 156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll
 175k 2002/01/09 C:\cygwin\bin\cygncurses++6.dll
 226k 2001/04/25 C:\cygwin\bin\c

Re: rsync windows -> unix still hanging :(

[Jim Kleckner]

The msleep(100) call is not checked into version 1.156 of main.c.

I would recommend trying this one-line patch to see if it helps.
I haven't personally delved into the true meaning.

I just checked my read-only CVS tree for rsync again.
Here is the context diff for that file.  Note that the msleep(100)
is not in the checked in version.

Jim

Index: main.c
===
RCS file: /cvsroot/rsync/main.c,v
retrieving revision 1.156
diff -c -r1.156 main.c
*** main.c1 Aug 2002 20:46:59 -1.156
--- main.c31 Dec 2002 01:21:34 -
***
*** 346,351 
--- 346,353 
 exit_cleanup(0);
 }

+ io_start_buffering_in(f_in);
+ io_start_buffering_out(f_out);
 send_files(flist,f_out,f_in);
 io_flush();
 report(f_out);
***
*** 421,427 
 close(error_pipe[1]);
 if (f_in != f_out) close(f_in);

! io_start_buffering(f_out);

 io_set_error_fd(error_pipe[0]);

--- 423,429 
 close(error_pipe[1]);
 if (f_in != f_out) close(f_in);

! io_start_buffering_out(f_out);

 io_set_error_fd(error_pipe[0]);

***
*** 434,440 
 write_int(f_out, -1);
 }
 io_flush();
!
 kill(pid, SIGUSR2);
 wait_process(pid, &status);
 return status;
--- 436,442 
 write_int(f_out, -1);
 }
 io_flush();
! msleep(100);
 kill(pid, SIGUSR2);
 wait_process(pid, &status);
 return status;
***
*** 476,481 
--- 478,484 
 }   
 }

+ io_start_buffering_in(f_in);
 if (delete_mode && !delete_excluded)
 recv_exclude_list(f_in);

***
*** 569,574 
--- 572,578 
 extern int cvs_exclude;
 extern int delete_mode;
 extern int delete_excluded;
+ io_start_buffering_out(f_out);
 if (cvs_exclude)
 add_cvs_excludes();
 if (delete_mode && !delete_excluded)
***
*** 578,584 
--- 582,591 
 if (verbose > 3)
 rprintf(FINFO,"file list sent\n");

+ io_flush();
+ io_start_buffering_out(f_out);
 send_files(flist,f_out,f_in);
+ io_flush();
 if (remote_version >= 24) {
 /* final goodbye message */   
 read_int(f_in);
***
*** 590,595 
--- 597,603 
 wait_process(pid, &status);
 }
 report(-1);
+ io_flush();
 exit_cleanup(status);
 }



Mike Rubel wrote:

[ ... ]



Could you clarify for me whether the patch Steve refers to is the same as
(or has the same effect as) the one you describe below?  Or are they two
different animals?  If they are different, should we test whether this
patch fixes his specific problem?

Best regards,
Mike

http://www.mikerubel.org





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync windows -> unix still hanging :(

[Jim Kleckner]

Mike -

Greger Cronquist and I have been using a patched rsync
successfully.  This was patched from two published patches,
one for buffering which seems to cause severe performance
problems under cygwin while only mild under Linux.  The
is for the hang documented elsewhere.  Here are patch discussion links:
http://www.cygwin.com/ml/cygwin/2002-10/msg00308.html
http://sources.redhat.com/ml/cygwin/2002-09/msg01155.html

Below are the diffs.  Note the use of 100ms not 30ms as per the
original posting.

Since you are on the rsync list, can you get them into that code line?

Jim

> On Sat, 28 Dec 2002, Scott Evans wrote:
>
> > I spent about 12 hours today writing a nice backup system based on
> > Mike Rubel's snapshot system; but much to my dismay, when I took it
> > for a test drive, I found that rsync hung on the first large directory
> > I tried to back up.  Aiee!
> [ ... ]
>
> Hey Scott,
>
> I'm Mike Rubel (author of that snapshot system page)--I haven't heard
> about this cygwin issue before, but this would definitely be worth adding
> to the FAQ.  I'm sorry to hear you're having so much trouble with it!
> You're actually the second person to mention windows issues; the other
> fellow was using a SAMBA mount and rsyncing locally on the server.  The
> problem there was files mysteriously getting copied when they hadn't
> changed, or deleted when they weren't supposed to be.  I asked the 
list if
> anyone else had seen that behavior, but no one responded, so I'm not sure
> what to think.  I'll add it to the FAQ, anyway, and maybe the BUGS
> section.
>
> Please let me know if you find any additional information.  I'm on the
> rsync list but not the cygwin list (yet).
>
> I've had no trouble with this at home with my roommate's Win2K PC, but
> between this case and the previous one, it sounds like the rsync/windows
> interaction may still have some rough edges, which is not really
> acceptable for a backup solution.  :(
>
> Thanks,


Here are the patches/diffs against a freshly "cvs update"d rsync cvs tree:


Index: fileio.c
===
RCS file: /cvsroot/rsync/fileio.c,v
retrieving revision 1.5
diff -r1.5 fileio.c
79c79,107
< return write(f,buf,len);
---
> static char *writeBuf;
> static size_t writeBufSize;
> static size_t writeBufCnt;
>
> if ( !writeBuf ) {
> writeBufSize = MAX_MAP_SIZE;
> writeBufCnt  = 0;
> writeBuf = (char*)malloc(MAX_MAP_SIZE);
> if (!writeBuf) out_of_memory("write_file");
> }
> ret = len;
> do {
> if ( buf && writeBufCnt < writeBufSize ) {
> size_t copyLen = len;
> if ( copyLen > writeBufSize - writeBufCnt ) {
> copyLen = writeBufSize - writeBufCnt;
> }
> memcpy(writeBuf + writeBufCnt, buf, copyLen);
> writeBufCnt += copyLen;
> buf += copyLen;
> len -= copyLen;
> }
> if ( !buf || writeBufCnt == writeBufSize ) {
> int thisRet = write(f, writeBuf, writeBufCnt);
> if ( thisRet < 0 ) return thisRet;
> writeBufCnt = 0;
> }
> } while ( buf && len > 0 );
> return ret;
Index: flist.c
===
RCS file: /cvsroot/rsync/flist.c,v
retrieving revision 1.127
diff -r1.127 flist.c
894c894
< io_start_buffering(f);
---
> io_start_buffering_out(f);
Index: io.c
===
RCS file: /cvsroot/rsync/io.c,v
retrieving revision 1.105
diff -r1.105 io.c
44,45c44,45
< static int multiplex_in_fd;
< static int multiplex_out_fd;
---
> static int multiplex_in_fd = -1;
> static int multiplex_out_fd = -1;
288a289,291
> static char *buffer;
> static size_t bufferIdx = 0;
> static size_t bufferSz;
290c293
< if (!io_multiplexing_in || fd != multiplex_in_fd)
---
> if (fd != multiplex_in_fd)
292a296,305
> if (!io_multiplexing_in && remaining == 0) {
> if (!buffer) {
> bufferSz = 2 * IO_BUFFER_SIZE;
> buffer   = malloc(bufferSz);
> if (!buffer) out_of_memory("read_unbuffered");
> }
> remaining = read_timeout(fd, buffer, bufferSz);
> bufferIdx = 0;
> }
>
296c309,310
< read_loop(fd, buf, len);
---
> memcpy(buf, buffer + bufferIdx, len);
> bufferIdx += len;
299c313
< continue;
---
> break;
308c322,329
< if (tag == MPLEX_BASE)
---
> if (tag == MPLEX_BASE) {
> if (!buffer || remaining > bufferSz) {
> buffer = Realloc(buffer, remaining);
> if (!buffer) out_of_memory("read_unbuffered");
> bufferSz = remaining;
> }
> read_loop(fd, buffer, remaining);
>

Re: Rsync performance increase through buffering (cygwin/ssh solution?)

[Jim Kleckner]

Below is a description of a buffering speed improvement.
The original message with complete patch for performance can be found here:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&newwindow=1&selm=at1i0e%241tj3%241%40FreeBSD.csie.NCTU.edu.tw

This may explain the horrendous performance of rsync
with ssh under cygwin.  Perhaps the way that cygwin
emulates these calls.  It is especially bad under the
circumstances mentioned here - with a large sync of data
where the files are identical (-I). 

The hang fix has been identified elsewhere in cygwin:
Check out these links:
 http://www.cygwin.com/ml/cygwin/2002-10/msg00308.html
 http://sources.redhat.com/ml/cygwin/2002-09/msg01155.html
patched rsync for hang under cygwin:
 http:// www.addr.com/~dmitry/rsync.exe

Jim

[EMAIL PROTECTED] (Craig Barratt) wrote in message 
news:...
> I've been studying the read and write buffering in rsync and it turns
> out most I/O is done just a couple of bytes at a time.  This means there
> are lots of system calls, and also most network traffic comprises lots
> of small packets.  The behavior is most extreme when sending/receiving
> file deltas of identical files.
>
> The main case where I/O is buffered is writes from the server (when
> io multiplexing is on). These are usually buffered in 4092 byte
> chunks with a 4 byte header. However, reading of these packets is
> usually unbuffered, and writes from the client are generally not
> buffered.  For example: when receiving 1st phase checksums (6 bytes
> per block), 2 reads are done: one of 4 bytes and one of 2 bytes,
> meaning there are 4 system calls (select/read/select/read) per 6
> bytes of checksum data).
>
> One cost of this is some performance, but a significant issue is that
> unbuffered writes generate very short (and very many) ethernet packets,
> which means the overhead is quite large on slow network connections.

... see this link for the rest:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&newwindow=1&selm=at1i0e%241tj3%241%40FreeBSD.csie.NCTU.edu.tw




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/