[setup PATCH] Remove pointless, worrying log message
Index: compress_bz.cc
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/compress_bz.cc,v
retrieving revision 2.7
diff -u -r2.7 compress_bz.cc
--- compress_bz.cc 10 Nov 2002 03:35:06 - 2.7
+++ compress_bz.cc 19 Jan 2003 15:21:14 -
@@ -194,7 +194,6 @@
int
compress_bz::error ()
{
- log (LOG_TIMESTAMP, compress_bz::error called);
return 0;
}
Code calls compress_bz::error() to ask *whether* an error has occurred. It
is silly and scare-mongering to print compress_bz::error called to the log
in this case.
Ok to commit?
Max.
Re: [setup PATCH] Remove pointless, worrying log message
On Sun, Jan 19, 2003 at 03:25:52PM -, Max Bowsher wrote:
Index: compress_bz.cc
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/compress_bz.cc,v
retrieving revision 2.7
diff -u -r2.7 compress_bz.cc
--- compress_bz.cc 10 Nov 2002 03:35:06 - 2.7
+++ compress_bz.cc 19 Jan 2003 15:21:14 -
@@ -194,7 +194,6 @@
int
compress_bz::error ()
{
- log (LOG_TIMESTAMP, compress_bz::error called);
return 0;
}
Code calls compress_bz::error() to ask *whether* an error has occurred. It
is silly and scare-mongering to print compress_bz::error called to the log
in this case.
Ok to commit?
I don't want to override Rob here, but IMO that's a big YES.
cgf
Re: [setup PATCH] Remove pointless, worrying log message
On Sun, Jan 19, 2003 at 03:25:52PM -, Max Bowsher wrote: - log (LOG_TIMESTAMP, compress_bz::error called); Code calls compress_bz::error() to ask *whether* an error has occurred. It is silly and scare-mongering to print compress_bz::error called to the log in this case. Ok to commit? Christopher Faylor wrote: I don't want to override Rob here, but IMO that's a big YES. I'll wait for Rob - whilst we are touching this file, maybe we should add a /* FIXME: Make compress_bz realize when an error has occured */ . Max.
[setup PATCH] Add Keep Button (and leave Prev button, for now)
OK, my previous Keep button patch fizzled, because I was trying to remove
the Prev button at the same time. So this adds Keep, whilst leaving Prev
alone.
OK to apply?
PS: Something else to think about: Does anyone edit the setup resources in
Visual Studio?
If no-one does, lets get rid of the unnecessary junk in res.rc/resource.h.
Max.
Index: choose.cc
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/choose.cc,v
retrieving revision 2.109
diff -u -p -r2.109 choose.cc
--- choose.cc 25 Nov 2002 13:26:05 - 2.109
+++ choose.cc 19 Jan 2003 17:43:38 -
@@ -437,7 +437,7 @@ create_listview (HWND dlg, RECT * r)
pkg.set_requirements (chooser-deftrust);
}
/* FIXME: do we need to init the desired fields ? */
- static int ta[] = { IDC_CHOOSE_PREV, IDC_CHOOSE_CURR, IDC_CHOOSE_EXP,
0 };
+ static int ta[] = { IDC_CHOOSE_KEEP, IDC_CHOOSE_PREV, IDC_CHOOSE_CURR,
IDC_CHOOSE_EXP, 0 };
rbset (dlg, ta, IDC_CHOOSE_CURR);
}
@@ -621,6 +621,20 @@ ChooserPage::OnMessageCmd (int id, HWND
packagedb db;
switch (id)
{
+case IDC_CHOOSE_KEEP:
+ if (IsDlgButtonChecked (GetHWND (), id))
+ {
+ for (vector packagemeta *::iterator i = db.packages.begin ();
+ i != db.packages.end (); ++i)
+ {
+packagemeta pkg = **i;
+pkg.desired = pkg.installed;
+ }
+set_view_mode (lv, chooser-get_view_mode ());
+break;
+ }
+ else
+ return false;
case IDC_CHOOSE_PREV:
if (IsDlgButtonChecked (GetHWND (), id))
{
Index: res.rc
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/res.rc,v
retrieving revision 2.44
diff -u -p -r2.44 res.rc
--- res.rc 25 Nov 2002 00:41:25 - 2.44
+++ res.rc 19 Jan 2003 17:56:49 -
@@ -288,12 +288,14 @@ STYLE DS_MODALFRAME | DS_3DLOOK | WS_CHI
CAPTION Select Packages
FONT 8, MS Sans Serif
BEGIN
-CONTROL Prev,IDC_CHOOSE_PREV,Button,BS_AUTORADIOBUTTON |
-WS_GROUP | WS_TABSTOP,150,30,27,10
-CONTROL
Curr,IDC_CHOOSE_CURR,Button,BS_AUTORADIOBUTTON,185,
-30,25,10
-CONTROL
Exp,IDC_CHOOSE_EXP,Button,BS_AUTORADIOBUTTON,220,30,
-25,10
+CONTROL Keep,IDC_CHOOSE_KEEP,Button,BS_AUTORADIOBUTTON |
+WS_GROUP | WS_TABSTOP,115,30,30,10
+CONTROL Prev,IDC_CHOOSE_PREV,Button,BS_AUTORADIOBUTTON ,
+150,30,27,10
+CONTROL Curr,IDC_CHOOSE_CURR,Button,BS_AUTORADIOBUTTON ,
+185,30,25,10
+CONTROL Exp,IDC_CHOOSE_EXP,Button,BS_AUTORADIOBUTTON ,
+220,30,25,10
PUSHBUTTON View,IDC_CHOOSE_VIEW,255,30,20,10,WS_GROUP
CONTROL ,IDC_STATIC,Static,SS_BLACKFRAME | SS_SUNKEN,0,28,
317,1
Index: resource.h
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/resource.h,v
retrieving revision 2.19
diff -u -p -r2.19 resource.h
--- resource.h 25 Nov 2002 00:41:25 - 2.19
+++ resource.h 19 Jan 2003 17:38:57 -
@@ -119,6 +119,7 @@
#define IDS_INSTALL_ERROR 1066
#define IDC_DISABLE_AV 1067
#define IDC_LEAVE_AV 1068
+#define IDC_CHOOSE_KEEP 1069
#define IDC_STATIC -1
// Next default values for new objects
@@ -129,7 +130,7 @@
#define _APS_3D_CONTROLS 1
#define _APS_NEXT_RESOURCE_VALUE129
#define _APS_NEXT_COMMAND_VALUE 40003
-#define _APS_NEXT_CONTROL_VALUE 1069
+#define _APS_NEXT_CONTROL_VALUE 1070
#define _APS_NEXT_SYMED_VALUE 101
#endif
#endif
Add-Keep-Button.patch
Description: Binary data
Re: ntsec patch for setup
Pierre A. Humblet wrote: This is the patch mentioned in the previous e-mail. I seems to work fine on NT and an early version was tested on 2000 (there are differences). Essentially the installed files should be in the Users or Admins groups instead of None. Nothing changes if the user running setup does not have the None gid. Sounds like this should migitate most new user's ntsec problems. It would probably be nice to add some logging to the success case, so its easier to see that it has actually taken effect. I don't understand this code: + isadmins = isadmins || EqualSid(groups-Groups[pg].Sid, asid); + isusers = isusers || EqualSid(groups-Groups[pg].Sid, usid); If I'm reading it right, isadmins and isusers were initialized as false several lines above, and not touched since - so why not a direct assignment? Max.
Re: [setup PATCH] Remove pointless, worrying log message
On Mon, 2003-01-20 at 02:25, Max Bowsher wrote: Code calls compress_bz::error() to ask *whether* an error has occurred. It is silly and scare-mongering to print compress_bz::error called to the log in this case. Ok to commit? No. We really need to implement the error checking - thats why it's there and verbose. There was a large fixup of such messages ~ 6 months back - and the same discussion on this particular one. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Add Keep Button (and leave Prev button, for now)
On Mon, 2003-01-20 at 05:03, Max Bowsher wrote: OK, my previous Keep button patch fizzled, because I was trying to remove the Prev button at the same time. So this adds Keep, whilst leaving Prev alone. OK to apply? Yes. PS: Something else to think about: Does anyone edit the setup resources in Visual Studio? If no-one does, lets get rid of the unnecessary junk in res.rc/resource.h. I don't, but I think Gary does. Lets blame it on Gary :}. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Remove pointless, worrying log message
Robert Collins wrote: On Mon, 2003-01-20 at 02:25, Max Bowsher wrote: Code calls compress_bz::error() to ask *whether* an error has occurred. It is silly and scare-mongering to print compress_bz::error called to the log in this case. Ok to commit? No. We really need to implement the error checking - thats why it's there and verbose. There was a large fixup of such messages ~ 6 months back - and the same discussion on this particular one. Wouldn't a /* FIXME: */ be more appropriate here? Or, is the idea to annoy yourself into fixing the lack of error checking? Max.
Re: [setup PATCH] Add Keep Button (and leave Prev button, for now)
Robert Collins wrote: On Mon, 2003-01-20 at 05:03, Max Bowsher wrote: OK, my previous Keep button patch fizzled, because I was trying to remove the Prev button at the same time. So this adds Keep, whilst leaving Prev alone. OK to apply? Yes. Applying. PS: Something else to think about: Does anyone edit the setup resources in Visual Studio? If no-one does, lets get rid of the unnecessary junk in res.rc/resource.h. I don't, but I think Gary does. Lets blame it on Gary :}. OK. Gary, if you use Visual Studio, fair enough, things stay as they are. If not, I think its time to trim those files. Max.
Re: [setup PATCH] Remove pointless, worrying log message
Christopher Faylor wrote: On Sun, Jan 19, 2003 at 08:15:17PM -, Max Bowsher wrote: Robert Collins wrote: On Mon, 2003-01-20 at 02:25, Max Bowsher wrote: Code calls compress_bz::error() to ask *whether* an error has occurred. It is silly and scare-mongering to print compress_bz::error called to the log in this case. Ok to commit? No. We really need to implement the error checking - thats why it's there and verbose. There was a large fixup of such messages ~ 6 months back - and the same discussion on this particular one. Wouldn't a /* FIXME: */ be more appropriate here? Or, is the idea to annoy yourself into fixing the lack of error checking? And not just yourself, either. It hass worryied scores of other people. A FIXME sounds better to me. Either that or add a don't worry about this to the message. How about this?: Robert and I promise to annoy each other into fixing the lack of error checking, and I change the log to a FIXME for now. Max.
Re: [setup PATCH] Remove pointless, worrying log message
On Mon, 2003-01-20 at 07:34, Max Bowsher wrote: How about this?: Robert and I promise to annoy each other into fixing the lack of error checking, and I change the log to a FIXME for now. How about this: If the error checking isn't implemented when we go to release the next setup.exe, *then* we remove the error for that release tag. The message stays in HEAD until the erorr checking is fixed. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [setup PATCH] Remove pointless, worrying log message
On Mon, Jan 20, 2003 at 07:39:07AM +1100, Robert Collins wrote: On Mon, 2003-01-20 at 07:34, Max Bowsher wrote: How about this?: Robert and I promise to annoy each other into fixing the lack of error checking, and I change the log to a FIXME for now. How about this: If the error checking isn't implemented when we go to release the next setup.exe, *then* we remove the error for that release tag. The message stays in HEAD until the erorr checking is fixed. Sounds like a great compromise to me. cgf
Re: ntsec patch for setup
At 06:25 PM 1/19/2003 -, Max Bowsher wrote: Pierre A. Humblet wrote: It would probably be nice to add some logging to the success case, so its easier to see that it has actually taken effect. OK. Good idea. I don't mind doing it but you know better what formats to use etc.. to fit with the rest. Let me know how you want to proceed. I don't understand this code: + isadmins = isadmins || EqualSid(groups-Groups[pg].Sid, asid); + isusers = isusers || EqualSid(groups-Groups[pg].Sid, usid); If I'm reading it right, isadmins and isusers were initialized as false several lines above, and not touched since - so why not a direct assignment? That's in the pg loop. So the effect is to set isadmins or isusers to true if the admins or users sids are found anywhere in the token groups. A direct assignment would in effect only consider the last sid in the groups array. Pierre
Re: ntsec patch for setup
On Sat, 2003-01-11 at 14:36, Pierre A. Humblet wrote: This is the patch mentioned in the previous e-mail. I seems to work fine on NT and an early version was tested on 2000 (there are differences). I'll be looking at this shortly - I am for it in principal. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: ntsec patch for setup
Pierre A. Humblet wrote:
At 06:25 PM 1/19/2003 -, Max Bowsher wrote:
Pierre A. Humblet wrote:
It would probably be nice to add some logging to the success case,
so its easier to see that it has actually taken effect.
OK. Good idea. I don't mind doing it but you know better
what formats to use etc.. to fit with the rest. Let me
know how you want to proceed.
Formats? What formats? :-) Setup has already has some badly punctuated /
badly spelt log strings. Anyway, I'd suggest something like this:
if (isusers)
{
nsid = usid;
log(LOG_TIMESTAMP) Changing gid to Users endLog;
}
else if (isadmins)
nsid = asid;
log(LOG_TIMESTAMP) Changing gid to Administrators endLog;
}
I don't understand this code:
+ isadmins = isadmins || EqualSid(groups-Groups[pg].Sid, asid);
+ isusers = isusers || EqualSid(groups-Groups[pg].Sid, usid);
If I'm reading it right, isadmins and isusers were initialized as
false several lines above, and not touched since - so why not a
direct assignment?
That's in the pg loop. So the effect is to set isadmins or isusers
to true if the admins or users sids are found anywhere in the token
groups. A direct assignment would in effect only consider the last
sid in the groups array.
*I must pay more attention!*
Max.
Crash on startup - debugging info
Okay, there are at least two problems happening in XWin.exe.
The first problem is totally unrelated to the new multiwindow mode. The
problem is, if you startup XWin.exe in gdb, a call to fchown causes a
SIGSEGV on every single execution. That sucks.
You can avoid that problem by setting a break in
_XSERVTransSocketUNIXCreateListener, then stepping until right before the
call to fchown, then ``set updateOwner=0'', which causes the call to be
skipped. After that you can continue. In non-multiwindow mode the server
will run fine after the continue.
The second problem is that in multiwindow mode the call to
pthread_mutex_init causes a SIGSEGV. That sucks too. I have peeked at the
code for pthread_mutex, but I can't figure out much. I might eventually
have to setup a cygwin1.dll build environment so I can debug this, but I
would really like to avoid that if possible. I actually started building a
debug version of cygwin1.dll tonight, but I got to the part where it needs
libiberty and I wussed out.
I am kinda stuck. Any help would be appreciated. Even saying, ``yeah, we
know that gdb doesn't work well when you call fchown'' would be help enough
for me.
Oh yeah, I also tried this with the 20030117 cygwin1.dll snapshot. Same
results.
Thanks in advance,
Harold
Running with -multiwindow or without -multiwindow, setting a breakpoint in
_XSERVTransSocketUNIXCreateListener
Starting program: /usr/X11R6/bin/XWin.exe -multiwindow
Program received signal SIGSEGV, Segmentation fault.
0x77e6d0c0 in _libkernel32_a_iname ()
(gdb) where
#0 0x77e6d0c0 in _libkernel32_a_iname ()
#1 0x0001 in ?? ()
#2 0x6103f35f in _libkernel32_a_iname ()
#3 0x6103f38b in _libkernel32_a_iname ()
#4 0x6107b7df in _libkernel32_a_iname ()
#5 0x6107baba in _libkernel32_a_iname ()
#6 0x0044b96a in trans_mkdir (path=0x448cb7 /tmp/.X11-unix, mode=1023)
at ../../../lib/xtrans/Xtransutil.c:495
#7 0x00448e37 in _XSERVTransSocketUNIXCreateListener (ciptr=0x100f26b8,
port=0x22fd30 0) at ../../../lib/xtrans/Xtranssock.c:932
#8 0x0044a5b1 in _XSERVTransCreateListener (ciptr=0x100f26b8,
port=0x22fd30 0) at ../../../lib/xtrans/Xtrans.c:734
#9 0x0044ac98 in _XSERVTransMakeAllCOTSServerListeners (port=0x22fd30 0,
partial=0x22fd58, count_ret=0x83f440, ciptrs_ret=0x7e4550)
at ../../../lib/xtrans/Xtrans.c:1029
#10 0x0043ed5c in CreateWellKnownSockets () at connection.c:342
#11 0x0040155c in main (argc=2, argv=0x100f1c00, envp=0x100f0330) at
main.c:327
#12 0x61007638 in _libkernel32_a_iname ()
#13 0x6100791d in _libkernel32_a_iname ()
#14 0x007e1862 in cygwin_crt0 ()
#15 0x0040103c in mainCRTStartup ()
#16 0x77e814c7 in _libkernel32_a_iname ()
(gdb) break _XSERVTransSocketUNIXCreateListener
Breakpoint 2 at 0x448e08: file ../../../lib/xtrans/Xtranssock.c, line 924.
(gdb) stop
(gdb) run -multiwindow
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/X11R6/bin/XWin.exe -multiwindow
Breakpoint 2, _XSERVTransSocketUNIXCreateListener (ciptr=0x100f26b8,
port=0x22fd30 0) at ../../../lib/xtrans/Xtranssock.c:924
924 oldUmask = umask (0);
(gdb) s
928 mode = 01777;
(gdb)
932 if (trans_mkdir(UNIX_DIR, mode) == -1) {
(gdb)
trans_mkdir (path=0x448cb7 /tmp/.X11-unix, mode=1023)
at ../../../lib/xtrans/Xtransutil.c:439
439 if (mkdir(path, mode) == 0) {
(gdb)
445 if (errno == EEXIST) {
(gdb)
446 if (lstat(path, buf) != 0) {
(gdb)
451 if (S_ISDIR(buf.st_mode)) {
(gdb)
452 int updateOwner = 0;
(gdb)
453 int updateMode = 0;
(gdb)
454 int updatedOwner = 0;
(gdb)
455 int updatedMode = 0;
(gdb)
457 if (buf.st_uid != 0)
(gdb)
458 updateOwner = 1;
(gdb)
464 if ((~mode) 0077 buf.st_mode)
(gdb)
466 if ((mode 01000)
(gdb)
475 if (updateMode || updateOwner) {
(gdb)
476 int fd = -1;
(gdb)
478 if ((fd = open(path, O_RDONLY)) != -1) {
(gdb)
479 if (fstat(fd, fbuf) == -1) {
(gdb)
488 if (!S_ISDIR(fbuf.st_mode) ||
(gdb)
495 if (updateOwner fchown(fd, 0, 0) == 0)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x77e6d0c0 in _libkernel32_a_iname ()
(gdb)
Running with -multiwindow, but running set updateOwner=0 right before the
call to fchown, then continuing until the breakpoint in InitQueue is hit:
495 if (updateOwner fchown(fd, 0, 0) == 0)
(gdb) set updateOwner=0
(gdb) continue
Continuing.
Breakpoint 1, InitQueue
Mirror
Hi, Can someone please direct me to where I can find out about becomming an official mirror for Cygwin in South Africa. Thank You, Tony Wade Systems Engineer, Infrastructure Internet Solutions Email: [EMAIL PROTECTED] Tel: +27 11 575 0503 Fax: +27 11 576 0503 Switchboard: +27 11 575 1000 #include std/disclaimer.h
Re: Crash on startup - debugging info
Harold, It seems that http://sources.redhat.com/ml/cygwin/2001-12/msg00395.html is related to the second problem. Kensuke Matsuzaki
Using XFree to replace explorer.exe as the window manager for Windows
Hey All, I am wondering if anyone has attempted to use Cygwin/XFree86 to replace explorer.exe as the window manager. -Gene [EMAIL PROTECTED]
RE: Crash on startup - debugging info
Kensuke, This is also related: http://www.cygwin.com/ml/cygwin/2002-10/msg00956.html The only difference is that I am not stepping through the code, I am just running it in gdb. The problem does also happen when not running in gdb. Perhaps I will just continue past the first two SIGSEGV's and see what the third one is. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kensuke Matsuzaki Sent: Sunday, January 19, 2003 8:24 AM To: [EMAIL PROTECTED] Subject: Re: Crash on startup - debugging info Harold, It seems that http://sources.redhat.com/ml/cygwin/2001-12/msg00395.html is related to the second problem. Kensuke Matsuzaki
Can't open display w/Cygwin on Win XP
Starting Cygwin/Xfree86 (4.2) with starxwin.bat or startxwin.sh or startx ends up with the same message them .. Can't open display. Message from startxwin.sh sh /usr/X11R6/bin/startxwin.sh Agent pid 2212 xsetroot: unable to open display '127.0.0.1:0.0' Sun Jan 19 09:42 AM [~] twm: unable to open display 127.0.0.1:0.0 xterm Xt error: Can't open display: 127.0.0.1:0.0 I'm running Win XP w/cygwin 1.3.18-1 The FAQ refers to a potential firewall problem .. which (i believe) is not the case .. as I run many many other TCP/IP apps on this PC with no problem. I am at a lost where to start .. as I believe this may have to do with XP (not seeing any other probable solutions in the archives). attached is my cygcheck file -Bob Gottesman cygcheck.out Description: Binary data
Re: Crash on startup - debugging info
On Sun, Jan 19, 2003 at 02:47:31AM -0500, Harold L Hunt II wrote: Okay, there are at least two problems happening in XWin.exe. The first problem is totally unrelated to the new multiwindow mode. The problem is, if you startup XWin.exe in gdb, a call to fchown causes a SIGSEGV on every single execution. That sucks. You can avoid that problem by setting a break in _XSERVTransSocketUNIXCreateListener, then stepping until right before the call to fchown, then ``set updateOwner=0'', which causes the call to be skipped. After that you can continue. In non-multiwindow mode the server will run fine after the continue. The second problem is that in multiwindow mode the call to pthread_mutex_init causes a SIGSEGV. That sucks too. I have peeked at the code for pthread_mutex, but I can't figure out much. I might eventually have to setup a cygwin1.dll build environment so I can debug this, but I would really like to avoid that if possible. I actually started building a debug version of cygwin1.dll tonight, but I got to the part where it needs libiberty and I wussed out. Have you tried continuing beyond the SIGSEGV? Some of the pthread code does a check of invalid memory and ends up raising an exception that is caught by the debugger. Unfortunately, there isn't much that gdb can do to detect that situation so we're stuck just continuing in that scenario. If a continue ends up leaving you in the same place then it really is a SIGSEGV. cgf
Re: Mirror
i think there's a link on the mirror link on cygwin.com's banner...try reading it carefully it must be somewhere in there... jagg --- Tony Wade [EMAIL PROTECTED] wrote: Hi, Can someone please direct me to where I can find out about becomming an official mirror for Cygwin in South Africa. Thank You, Tony Wade Systems Engineer, Infrastructure Internet Solutions Email: [EMAIL PROTECTED] Tel: +27 11 575 0503 Fax: +27 11 576 0503 Switchboard: +27 11 575 1000 #include std/disclaimer.h __ Post your free ad now! http://personals.yahoo.ca
---Re: Can't open display w/Cygwin on Win XP
If you run cygwin, cygwin's Xfree86 relies that these variables MUST be set in order to work...these variables are first set under windows XP...if you do a set in a 'dos-box' this is what i'm talking about...these variables are then used with cygwin's X to become functional.. SYSTEMROOT=C:\WINDOWS- a must! (this is an eg) PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; ( and for compiling, windows libraries... INCLUDE LIB ) you may also want someone to help you if you scripts are not pointing to existing files...it may be this as well...but make sure these two variables are at least correctly set or it won't work...it may also possibly be a firewall installation or compatibility issue... ..hope this helps... jagg --- Robert Gottesman [EMAIL PROTECTED] wrote: Starting Cygwin/Xfree86 (4.2) with starxwin.bat or startxwin.sh or startx ends up with the same message them .. Can't open display. Message from startxwin.sh sh /usr/X11R6/bin/startxwin.sh Agent pid 2212 xsetroot: unable to open display '127.0.0.1:0.0' Sun Jan 19 09:42 AM [~] twm: unable to open display 127.0.0.1:0.0 xterm Xt error: Can't open display: 127.0.0.1:0.0 I'm running Win XP w/cygwin 1.3.18-1 The FAQ refers to a potential firewall problem .. which (i believe) is not the case .. as I run many many other TCP/IP apps on this PC with no problem. I am at a lost where to start .. as I believe this may have to do with XP (not seeing any other probable solutions in the archives). attached is my cygcheck file -Bob Gottesman ATTACHMENT part 2 application/octet-stream name=cygcheck.out __ Post your free ad now! http://personals.yahoo.ca
[ANNOUNCEMENT] Server Test 73
Links: I just posted Test 73 to the server development page: http://xfree86.cygwin.com/devel/shadow/ You can install the Test 73 package via setup.exe by selecting the 'test' package (and be sure to check the 'Bin' box): XFree86-xserv-4.2.0-21 Server Test Series binary and source code releases are now available via the sources.redhat.com ftp mirror network (http://cygwin.com/mirrors.html) in the pub/cygwin/xfree/devel/shadow/ directory. You may wish to note the desired filename in the links below, then download from your closest mirror (http://cygwin.com/mirrors.html). Server binary, direct link: http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test73.exe.bz2 (1201 KiB) Server source, direct link: http://www.msu.edu/~huntharo/xwin/shadow/xwin-20030120-0108.tar.bz2 (106 KiB) xc/programs/Xserver/hw/xwin (all files) diff against Test72 source code: http://www.msu.edu/~huntharo/xwin/shadow/xwin-Test72-to-Test73.diff.bz2 (16 KiB) Changes: 1) Preliminary integration of the ``xwinclip'' functionality into the main server executable. This functionality is accessible via the ``-clipboard'' command-line parameter. (Harold Hunt) 2) Delay the execution of the Multi-Window Window Manager thread until the X Server has finished starting up. (Harold Hunt) 3) Restructure the way that the Multi-Window Window Manager handles fatal errors. Return FALSE when we encounter an initialization error so that the server can make a clean exit, instead of aborting immediately by calling exit (1). For later errors, call pthread_exit (NULL) instead of exit (1) so that only the Multi-Window Window Manager aborts; there is no need to kill the X Server process since work could still be recovered without the window manager module. (Harold Hunt) 4) Destroy the pthread mutex and condition variables, used for synchronization in the Multi-Window Window Manager, upon X Server exit. (Harold Hunt) Enjoy, Harold
RE: [ANNOUNCEMENT] Server Test 71 [DEBUG BUILD]
Erik and JS, Try the new Test73 release (4.2.0-21). The new release has a much more robust way of initializing the Multi-Window Window Manager that should take care of your crashes on startup. If not, it should at least allow for better reporting of errors. Do not run Test73 in gdb; that will not give me any useful information and you will just see SIGSEGV's that are normally handled by the C++ exception handlers. Just run Test73 as usual and report your results. Thanks so much for testing, Harold
RE: Using XFree to replace explorer.exe as the window manager for Windows
I am wondering if anyone has attempted to use Cygwin/XFree86 to replace explorer.exe as the window manager. David Fraser has reported done so with kde-cygwin. See http://lists.kde.org/?l=kde-cygwinm=103072530327420w=2 for further infos. Regards Ralf
src/winsup/cygwin ChangeLog grp.cc passwd.cc p ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2003-01-20 02:57:54 Modified files: winsup/cygwin : ChangeLog grp.cc passwd.cc path.cc path.h pwdgrp.h uinfo.cc Log message: * pwdgrp.h (etc): Move to path.h. (pwdgrp::max_lines): New field. (pwdgrp::curr_lines): New field. (pwdgrp::pwdgrp_buf): Ditto. (pwdgrp_buf_elem_size): Ditto. (pwdgrp_parse): Ditto. (pwdgrp::gets): Just declare here. (pwdgrp::load): Ditto. Just take one argument. (pwdgrp::load): Define overloaded function accepting passwd buf. (pwdgrp::load): Define overloaded function accepting group buf. * grp.cc: Use pwdgrp elements rather than standalone static variables throughout. (curr_lines): Eliminate. (max_lines): Ditto. (add_grp_line): Ditto. (parse_grp): Define as returning boolean. Accept void * arg and line count. Coerce first argument into __group32 buf reference. Increment curr_line as appropriate. (read_etc_group): Pass pwdgrp buffer to gr.load. * passwd.cc: Use pwdgrp elements rather than standalone static variables throughout. (curr_lines): Eliminate. (max_lines): Ditto. (add_grp_line): Ditto. (parse_passwd): Define as returning boolean. Accept void * arg and line count. Coerce first argument into passwd buf reference. Increment curr_line as appropriate. (read_etc_group): Pass pwdgrp buffer to pr.load. * path.cc (etc::fn): Extend buffer size to allow index by 1 rather than zero. (etc::last_modified): Ditto. (etc::change_possible): Ditto. Renamed from sawchange. Change to signed char since elements are now tri-state. (etc::init): Assume handle is 1 based rather than 0. (etc::test_file_change): New function. Sets change_possible based on file date comparison. (etc::dir_changed): Check file states immediately after changed_h is initialized to avoid a race. (etc::file_changed): Use test_file_change to detect if file needs to be updated. * path.h (etc): Move class here from pwdgrp.h. * uinfo.cc: Move etc:: functions to path.cc. Move pwdgrp functions here. (pwdgrp::gets): Eliminate buf checks. Just check eptr and set lptr. (pwdgrp::add_line): New function. (pwdgrp::load): Call generic add_line function which will call correct parser. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.1699r2=1.1700 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/grp.cc.diff?cvsroot=srcr1=1.64r2=1.65 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/passwd.cc.diff?cvsroot=srcr1=1.59r2=1.60 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.239r2=1.240 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.h.diff?cvsroot=srcr1=1.48r2=1.49 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pwdgrp.h.diff?cvsroot=srcr1=1.11r2=1.12 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/uinfo.cc.diff?cvsroot=srcr1=1.100r2=1.101
Re: etc_changed, passwd group
Ok. I took another stab at this, cleaning up some more stuff and moving (almost) everything into the pwdgrp class. Hardly anything is marked NO_COPY now. I moved etc out of uinfo since, as I mentioned, I plan on using it for more than just passwd/group stuff someday. I renamed sawchange to change_possible and made change_possible a tri-state where -1 means definitely changed. I think that I worked around the potential for a race by explicitly testing any registered files prior to checking if the directory had changed. And, I explicitly closed the file even in the error condition. For the Novell case, I explicitly check the creation time of the file every time. It may be slower but at least it makes cygwin behavior consistent regardless of whether the FS. I also a debug_printf showing how many lines were read in in pwdgrp::load (I made all of the functions in pwdgrp into non-inline, hope Corinna doesn't mind but I got tired of watching six files recompile every time I made a change). I've got some more checks to run and then I'll checkin the current sources and make YA snapshot -- the first to be deployed on the new sources.redhat.com. Once again, these are not trivial changes, but I think they are zeroing in on something. I am still not sure if the handle concept for the etc class makes sense. I may end up just going with a linked list of etc elements eventually. Thanks, cgf On Fri, Jan 17, 2003 at 11:36:12PM -0500, Pierre A. Humblet wrote: I like your code, just made a few changes. The explanations below are detailed and longer that the changes! In load(), CloseFile wasn't called on read error, and it was called before GetFileTime.
Re: etc_changed, passwd group
On Sun, Jan 19, 2003 at 09:40:01PM -0500, Christopher Faylor wrote: For the Novell case, I explicitly check the creation time of the file every time. It may be slower but at least it makes cygwin behavior consistent regardless of whether the FS. XXX I also a debug_printf showing how many lines were read in in pwdgrp::load added Cheesh. cgf
Crash on startup - debugging info
Okay, there are at least two problems happening in XWin.exe.
The first problem is totally unrelated to the new multiwindow mode. The
problem is, if you startup XWin.exe in gdb, a call to fchown causes a
SIGSEGV on every single execution. That sucks.
You can avoid that problem by setting a break in
_XSERVTransSocketUNIXCreateListener, then stepping until right before the
call to fchown, then ``set updateOwner=0'', which causes the call to be
skipped. After that you can continue. In non-multiwindow mode the server
will run fine after the continue.
The second problem is that in multiwindow mode the call to
pthread_mutex_init causes a SIGSEGV. That sucks too. I have peeked at the
code for pthread_mutex, but I can't figure out much. I might eventually
have to setup a cygwin1.dll build environment so I can debug this, but I
would really like to avoid that if possible. I actually started building a
debug version of cygwin1.dll tonight, but I got to the part where it needs
libiberty and I wussed out.
I am kinda stuck. Any help would be appreciated. Even saying, ``yeah, we
know that gdb doesn't work well when you call fchown'' would be help enough
for me.
Oh yeah, I also tried this with the 20030117 cygwin1.dll snapshot. Same
results.
Thanks in advance,
Harold
Running with -multiwindow or without -multiwindow, setting a breakpoint in
_XSERVTransSocketUNIXCreateListener
Starting program: /usr/X11R6/bin/XWin.exe -multiwindow
Program received signal SIGSEGV, Segmentation fault.
0x77e6d0c0 in _libkernel32_a_iname ()
(gdb) where
#0 0x77e6d0c0 in _libkernel32_a_iname ()
#1 0x0001 in ?? ()
#2 0x6103f35f in _libkernel32_a_iname ()
#3 0x6103f38b in _libkernel32_a_iname ()
#4 0x6107b7df in _libkernel32_a_iname ()
#5 0x6107baba in _libkernel32_a_iname ()
#6 0x0044b96a in trans_mkdir (path=0x448cb7 /tmp/.X11-unix, mode=1023)
at ../../../lib/xtrans/Xtransutil.c:495
#7 0x00448e37 in _XSERVTransSocketUNIXCreateListener (ciptr=0x100f26b8,
port=0x22fd30 0) at ../../../lib/xtrans/Xtranssock.c:932
#8 0x0044a5b1 in _XSERVTransCreateListener (ciptr=0x100f26b8,
port=0x22fd30 0) at ../../../lib/xtrans/Xtrans.c:734
#9 0x0044ac98 in _XSERVTransMakeAllCOTSServerListeners (port=0x22fd30 0,
partial=0x22fd58, count_ret=0x83f440, ciptrs_ret=0x7e4550)
at ../../../lib/xtrans/Xtrans.c:1029
#10 0x0043ed5c in CreateWellKnownSockets () at connection.c:342
#11 0x0040155c in main (argc=2, argv=0x100f1c00, envp=0x100f0330) at
main.c:327
#12 0x61007638 in _libkernel32_a_iname ()
#13 0x6100791d in _libkernel32_a_iname ()
#14 0x007e1862 in cygwin_crt0 ()
#15 0x0040103c in mainCRTStartup ()
#16 0x77e814c7 in _libkernel32_a_iname ()
(gdb) break _XSERVTransSocketUNIXCreateListener
Breakpoint 2 at 0x448e08: file ../../../lib/xtrans/Xtranssock.c, line 924.
(gdb) stop
(gdb) run -multiwindow
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/X11R6/bin/XWin.exe -multiwindow
Breakpoint 2, _XSERVTransSocketUNIXCreateListener (ciptr=0x100f26b8,
port=0x22fd30 0) at ../../../lib/xtrans/Xtranssock.c:924
924 oldUmask = umask (0);
(gdb) s
928 mode = 01777;
(gdb)
932 if (trans_mkdir(UNIX_DIR, mode) == -1) {
(gdb)
trans_mkdir (path=0x448cb7 /tmp/.X11-unix, mode=1023)
at ../../../lib/xtrans/Xtransutil.c:439
439 if (mkdir(path, mode) == 0) {
(gdb)
445 if (errno == EEXIST) {
(gdb)
446 if (lstat(path, buf) != 0) {
(gdb)
451 if (S_ISDIR(buf.st_mode)) {
(gdb)
452 int updateOwner = 0;
(gdb)
453 int updateMode = 0;
(gdb)
454 int updatedOwner = 0;
(gdb)
455 int updatedMode = 0;
(gdb)
457 if (buf.st_uid != 0)
(gdb)
458 updateOwner = 1;
(gdb)
464 if ((~mode) 0077 buf.st_mode)
(gdb)
466 if ((mode 01000)
(gdb)
475 if (updateMode || updateOwner) {
(gdb)
476 int fd = -1;
(gdb)
478 if ((fd = open(path, O_RDONLY)) != -1) {
(gdb)
479 if (fstat(fd, fbuf) == -1) {
(gdb)
488 if (!S_ISDIR(fbuf.st_mode) ||
(gdb)
495 if (updateOwner fchown(fd, 0, 0) == 0)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x77e6d0c0 in _libkernel32_a_iname ()
(gdb)
Running with -multiwindow, but running set updateOwner=0 right before the
call to fchown, then continuing until the breakpoint in InitQueue is hit:
495 if (updateOwner fchown(fd, 0, 0) == 0)
(gdb) set updateOwner=0
(gdb) continue
Continuing.
Breakpoint 1, InitQueue
Re: Apache corrupt big file
Hi, 2003/01/19 6:37:50, Stipe Tolj [EMAIL PROTECTED] wrote: sorry, I could never reproduce the reported problem. I understand this is my particular environmental problem. So, any hints to solve this problem? Unfortunatly, I am a hardware engineer, I am not familier with debugging such problem... Tetsu KOUNO -- 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/
Serial port access under expect
Hello, I have a simple terminal emulation program, through which I am able to access an embedded board, through serial port. This works fine from the bash prompt; but however, if I try to do the same from within an expect script, the program fails with Permission denied message, for the open() call (to open the serial port). The expect script snippet is something like the below: set timeout 60 spawn tinycom -n -b 9600 /dev/ttyS0 sleep 2 send \r\r expect $ I'd looked up the mailing list archives, and found some mails related to psuedo-tty functionality not stable in expect, and consequently the expect would not be able to `talk' to spawned processes well (well that's what I could conclude; corrections are welcome). But from the error message which I get, that doesn't seem to be the problem. However, I tried an ftp script which would login into a local machine and download a file. The expect script ran fine and didn't have problems `talking' to ftp. I wonder what could be problem with my setup. Does anybody have any idea, as to what could I be doing wrong? Thanks, chyrag. -- 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: Serial port access under expect
Don't you try to open a serial port from two processes? You can't do that on Windows, Windows don't allow to share the serial ports. Sergey Okhapkin Somerset, NJ - Original Message - From: Chirag Kantharia [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 6:50 AM Subject: Serial port access under expect Hello, I have a simple terminal emulation program, through which I am able to access an embedded board, through serial port. This works fine from the bash prompt; but however, if I try to do the same from within an expect script, the program fails with Permission denied message, for the open() call (to open the serial port). The expect script snippet is something like the below: set timeout 60 spawn tinycom -n -b 9600 /dev/ttyS0 sleep 2 send \r\r expect $ I'd looked up the mailing list archives, and found some mails related to psuedo-tty functionality not stable in expect, and consequently the expect would not be able to `talk' to spawned processes well (well that's what I could conclude; corrections are welcome). But from the error message which I get, that doesn't seem to be the problem. However, I tried an ftp script which would login into a local machine and download a file. The expect script ran fine and didn't have problems `talking' to ftp. I wonder what could be problem with my setup. Does anybody have any idea, as to what could I be doing wrong? Thanks, chyrag. -- 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/ -- 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: Serial port access under expect
Hi Sergey, I am not sure if I understand you. I am not trying to open the serial port from two processes simultaneously. I tried opening the serial port from the bash prompt, which worked and later, I tried from the expect script which didn't work. If the expect script is implicitly opening the serial port twice, then I'm confused. Does the script mentioned below open the serial port twice? Regards, chyrag. - Original Message - From: Sergey Okhapkin [EMAIL PROTECTED] Date: Sunday, January 19, 2003 5:48 pm Subject: Re: Serial port access under expect Don't you try to open a serial port from two processes? You can't do that on Windows, Windows don't allow to share the serial ports. snip From: Chirag Kantharia [EMAIL PROTECTED] I have a simple terminal emulation program, through which I am able to access an embedded board, through serial port. This works fine from the bash prompt; but however, if I try to do the same from within an expect script, the program fails with Permission denied message, for the open() call (to open the serial port). The expect script snippet is something like the below: set timeout 60 spawn tinycom -n -b 9600 /dev/ttyS0 sleep 2 send \r\r expect $ -- 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: Serial port access under expect
Could you strace the script execution? Sergey Okhapkin Somerset, NJ - Original Message - From: Chirag Kantharia [EMAIL PROTECTED] To: Sergey Okhapkin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 7:29 AM Subject: Re: Serial port access under expect Hi Sergey, I am not sure if I understand you. I am not trying to open the serial port from two processes simultaneously. I tried opening the serial port from the bash prompt, which worked and later, I tried from the expect script which didn't work. If the expect script is implicitly opening the serial port twice, then I'm confused. Does the script mentioned below open the serial port twice? Regards, chyrag. - Original Message - From: Sergey Okhapkin [EMAIL PROTECTED] Date: Sunday, January 19, 2003 5:48 pm Subject: Re: Serial port access under expect Don't you try to open a serial port from two processes? You can't do that on Windows, Windows don't allow to share the serial ports. snip From: Chirag Kantharia [EMAIL PROTECTED] I have a simple terminal emulation program, through which I am able to access an embedded board, through serial port. This works fine from the bash prompt; but however, if I try to do the same from within an expect script, the program fails with Permission denied message, for the open() call (to open the serial port). The expect script snippet is something like the below: set timeout 60 spawn tinycom -n -b 9600 /dev/ttyS0 sleep 2 send \r\r expect $ -- 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: Tab completion list takes enormously long time to generate from empty string
Mangus, At 16:12 2003-01-13, Magnus Holmgren wrote: -Original Message- From: Magnus Holmgren [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 7:51 PM To: [EMAIL PROTECTED] Subject: Tab completion list takes enormously long time to generate from empty string Greetings. When I press tab in bash without having typed anything at all (which is somewhat abusive but it easily happens), bash works for 15 minutes, going through $PATH looking for executables (and in the end producing nothing) on a 2x450 MHz PIII. Is that normal? The time consumed in this sort of thing is almost certainly dominated by I/O activity, not CPU load. Well, there are certainly some disk I/O, but also 100% load on one processor, so the operation seems to be CPU-bound anyway. How long does it take Cygwin Setup to compute the list of packages that are candidates for download or installation? If your 15 minute time to produce a list of executables for command completion is any indication, it must be hours! A few seconds. Bite that! :) But Cygwin setup doesn't have to open and read thousands of files. And it's not using cygwin1.dll. The Cygwin layer seems to slow down things considerably. On my 2.4 GHz single processor system with fast disks, it takes only a few seconds to get the beep on the first tab and only about a second or two to be asked if I want to see all 3719 possibilities on the second tab. I was able to strip down my $PATH a bit (removing KDE for example), reducing the time needed to generate the list to some minute, but I'm not quite satisfied with that either. It's too bad so many DLLs are produced in this list. Must they have execute bits set to be loaded? NT does have separate read and execute bits. I don't know if DLL:s have to have the execute bits set to be loaded, but it's rather laborious to change all the permissions anyway. Windows primarily relies on extensions to determine what files are executable, as you know. Perhaps cygwin should do that as well, i.e. only check files with known extensions for #!/path? Correction; there is no writing to disk, but certainly loads of *reading*, and quicksort seems to be used, so I don't blame the sorting anymore. I reckon that all files in $PATH (except .exe-s) have to be opened to see if they start with #!, and that that takes some time. Getting rid of some entries in $PATH surely reduces the time consumed, but I still think that more than five seconds is too much. Any perceptible delay in getting a result from a computer is too long. So it goes... Hey! I didn't say that! I'll be fine with ten seconds! :-) Some optimizations should be possible, such as only checking files with certain extensions, like .sh, .pl, and none at all for the magic #! or caching the list in some form. A second option might even be to disallow tab completion of commands without entering a prefix. This is the sort of thing the -x, -E and -X options to mount are meant to address. Check them out, they can probably help a lot with this problem. It helps a bit, or even a lot, but at the price that all files will be tab completed to. Unless I create a mount point to each directory in $PATH. /Magnus Randall Schulz /Magnus -- 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: Serial port access under expect
Hi Sergey, I could strace the script. The strace output shows that the /dev/ttyS0 is opened just once, which fails with return value -1. I can send you the strace output, if required. Much thanks and regards, chyrag. - Original Message - From: Sergey Okhapkin [EMAIL PROTECTED] Date: Sunday, January 19, 2003 6:11 pm Subject: Re: Serial port access under expect Could you strace the script execution? Sergey Okhapkin Somerset, NJ -- 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: Tab completion list takes enormously long time to generate from empty string
Magnus Holmgren wrote: But Cygwin setup doesn't have to open and read thousands of files. And it's not using cygwin1.dll. The Cygwin layer seems to slow down things considerably. Yes, stat is known to be an expensive operation. I was able to strip down my $PATH a bit (removing KDE for example), reducing the time needed to generate the list to some minute, but I'm not quite satisfied with that either. It's too bad so many DLLs are produced in this list. Must they have execute bits set to be loaded? NT does have separate read and execute bits. I don't know if DLL:s have to have the execute bits set to be loaded, Yes! This is the sort of thing the -x, -E and -X options to mount are meant to address. Check them out, they can probably help a lot with this problem. It helps a bit, or even a lot, but at the price that all files will be tab completed to. Unless I create a mount point to each directory in $PATH. Do you have that many that this is impractical? Max. -- 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/
Unsubcribe
Alle 02:04, sabato 18 gennaio 2003, Christopher Faylor ha scritto: On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote: Chris, On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote: On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote: This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? Looking good! I spoke too soon. I'm getting segmentation faults and stuff like the following by just running ls: $ uname -a CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown $ cd src/pgsql /home/jt/src/pgsql $ ls ... 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state (probably corrupted stack) Could you get a gdb backtrace of this problem? cgf * www.topdrin.com Solo il TOP per il tuo cellulare !! Una selezione di oltre 5000 loghi, suonerie e picture. -- 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: Apache corrupt big file
Tetsu KOUNO wrote: I have a problem with apache. I found a mail which reports same symptom, in cygwin-apps mailing list (attached below). However I can not find follow-ups which gives a solution of the problem. Stipe Tolj wrote: sorry, I could never reproduce the reported problem. Seems to be XP specific?! I run apache 1.3.17 on a public IP Windows 2000 workstation (aka apache.dev.wapme.net) and you can download any kind of sized files from there. XP's not the trigger factor. Just tested putting a 191K JPEG through Cygwin apache, on XP/Pro/SP1, Cygwin 1.3.18. cmp reports that before.jpg and after.jpg are identical. Max. -- 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/
ssh with one agent for all bash´s
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, looking up the mailinglist and testing a while I figured out that with following .bash_profile, I can have one ssh-agent thruoghout all sessions I open! Once the agent is running the following shells use it again! Although the first shell will not close by it self till the last one is gone. May be helpfull for anybody using ssh! #!/bin/bash trap ' if [ $(ps -fu `id -un`|grep -c bash) -eq 2 ] then test -n $SSH_AGENT_PID eval `ssh-agent -k` ; setx.exe SSH_AGENT_PID ; setx.exe SSH_AUTH_SOCK ; fi ' 0 ... if [ $SSH_AUTH_SOCK = ] then eval `ssh-agent`; /usr/bin/tty /dev/null ssh-add $HOME/.ssh/id_dsa; setx.exe SSH_AGENT_PID $SSH_AGENT_PID; setx.exe SSH_AUTH_SOCK $SSH_AUTH_SOCK; fi -BEGIN PGP SIGNATURE- Version: PGP 8.0 iQA/AwUBPiq++50aiFY+2vypEQKafQCdF+35SKzOgXQtK4PkQwpSowPzeaMAoI46 nONcpKXrLfs/ww3jdFTl6B0o =Gurg -END PGP SIGNATURE- -- 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: gcc-2 ..../bin/as.exe: Permission denied
On Fri, Jan 17, 2003 at 12:43:36AM -0500, Christopher Faylor wrote: On Fri, Jan 17, 2003 at 04:35:15PM +1100, Brendan Kosowski wrote: I have just installed cygwin on win98se using setup.exe. I selected gcc-2 as the only extra on top of the base install. I told setup that I am the only user and I use unix style text files. When I run Cygwin Bash Shell and try to compile a C program in my home dir (eg. gcc-2 -o mytest.exe mytest.c ) I get the following error message: gcc-2: installation problem, cannot exec '/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/ bin/as.exe': Permission denied Thanks for any help. Check out http://cygwin.com/bugs.html, specifically the part about sending cygcheck output. Chris, I ran into a similar problem[1] this *just* yesterday. With the help of the Cygwin FAQ, I remembered that symlinks are expected to have the DOS/NT system attribute set. I launched command.com, changed the directory c:\cygwin\usr\i686-pc-cygwin, and ran 'attrib', and as.exe did not have the system attribute set. I then ran 'attrib +s *.exe' from command.com, and retried my compile, and it started working again. So, somehow the system attribute is getting wiped out after installation. I'll look into it some more and post anything I find. [1] - I'm using gcc-3, and Brendan is using gcc-2, but I guess the problem is independent of gcc version. -- Dario Alcocer -- Sr. Software Developer, Helix Digital Inc. [EMAIL PROTECTED] -- http://www.helixdigital.com -- 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: gcc-2 ..../bin/as.exe: Permission denied
Dario Alcocer wrote: Chris, I ran into a similar problem[1] this *just* yesterday. With the help of the Cygwin FAQ, I remembered that symlinks are expected to have the DOS/NT system attribute set. For the archives: Only the magic cookie type. For the *.lnk type, it is the read-only attribute. Max. -- 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/
How to get out of cygwin mail lists
On Sun, 19 Jan 2003 15:00:48 +0100 Peppino [EMAIL PROTECTED] wrote: snipped totally irrelevant text from 'reply-to' I doubt this will do much good since you didn't read the responses to the last person who sent such a request to the list, but if you visit (http://cygwin.com/ml/#unsubscribe-simple) and follow the instructions given there you should be able to unsubscribe from this list. The same URL is at the bottom of every message sent through the list, including your request. If the instructions in 1. Unsubscribing, simple are not sufficient, look at the sections in the web page immediately below there for successively more difficult situations. Addresses for help and unsubscribing are also in the headers of every message sent through the list. If none of that is sufficient, email your problem to [EMAIL PROTECTED] as mentioned under 4. Unsubscribing, I'm desperate. Sending it to this list just annoys everyone else and doesn't get you out of the list. There is also a webform available at http://cygwin.com/ml/#faqs if you want unsubscribe that way. Finally, if you are going to be too lazy to type even the list address in the 'TO' address field, please at least snip the message you 'Replied to' to when you generate your message. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age. -- 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/
grep -r *.java doesn't work as expected
I try to grep all .java file recursively [/q/Workflow/AppAdmin/src/com/cisco/wf/admin] $ grep -rn systemRsrc *.java LDAPConfig.java:948: ... getRemoteSubsystemRsrcMgr() TestLDAPConfig.java:58:... getRemoteSubsystemRsrcMgr... Only files in the current directory is searched. Interesting when I use only * I search recursively. [/q/Workflow/AppAdmin/src/com/cisco/wf/admin] $ grep -rn systemRsrc * LDAPConfig.java:948: public RemoteRsrcMgr getRemoteSubsystemRsrcMgr() LDAPConfig.java.keep:928: public ... getRemoteSubsystemRsrcMgr() TestLDAPConfig.java:58:public ... getRemoteSubsystemRsrcMgr() .. iaq/LDAPIAQWebConfig.java:343: ... myLDAPConfig.getRemoteSubsystemRsrcMgr(); iaq/LDAPIAQWebConfig.java:383: ... myLDAPConfig.getRemoteSubsystemRsrcMgr(); Problem is it included some non java file. What's wrong? Wai Yip Tung -- 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: grep -r *.java doesn't work as expected
Wai-Yip Tung (wtung) wrote: I try to grep all .java file recursively [/q/Workflow/AppAdmin/src/com/cisco/wf/admin] $ grep -rn systemRsrc *.java Only files in the current directory is searched. What's wrong? Nothing. This is the expected behaviour. The shell expands *.java, and then runs grep -rn file1.java file2.java file3.java - none of which are directories, so grep can't recurse into them. Try: find -name '*.java' | xargs grep -n systemRsrc Max. -- 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: grep -r *.java doesn't work as expected
Wai-Yip, Grep _will_ search in files found throughout a directory hierarchy, but that's not it's default mode of operation. Look into the -R / -r / --recursive option and the associated --include and --exclude options. Also, I don't know what you intend by your use of -m, but according to the help output, it requires a numeric argument that limits the number of matches displayed per target file. I suspect that in part you're accustomed to a non-Gnu grep program, and there are considerable differences between other greps and Gnu grep. Read the man page so you'll know how to use it properly. Randall Schulz At 07:04 2003-01-19, Wai-Yip Tung \(wtung\) wrote: I try to grep all .java file recursively [/q/Workflow/AppAdmin/src/com/cisco/wf/admin] $ grep -rn systemRsrc *.java LDAPConfig.java:948: ... getRemoteSubsystemRsrcMgr() TestLDAPConfig.java:58:... getRemoteSubsystemRsrcMgr... Only files in the current directory is searched. Interesting when I use only * I search recursively. [/q/Workflow/AppAdmin/src/com/cisco/wf/admin] $ grep -rn systemRsrc * LDAPConfig.java:948: public RemoteRsrcMgr getRemoteSubsystemRsrcMgr() LDAPConfig.java.keep:928: public ... getRemoteSubsystemRsrcMgr() TestLDAPConfig.java:58:public ... getRemoteSubsystemRsrcMgr() .. iaq/LDAPIAQWebConfig.java:343: ... myLDAPConfig.getRemoteSubsystemRsrcMgr(); iaq/LDAPIAQWebConfig.java:383: ... myLDAPConfig.getRemoteSubsystemRsrcMgr(); Problem is it included some non java file. What's wrong? Wai Yip Tung -- 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: grep -r *.java doesn't work as expected
Randall R Schulz wrote: Grep _will_ search in files found throughout a directory hierarchy, but that's not it's default mode of operation. Look into the -R / -r / --recursive option and the associated --include and --exclude options. I didn't know about --include/--exclude - much simpler than find and xargs! Thanks! Also, I don't know what you intend by your use of -m That would be -rn, as in the contraction of -r -n :-) Max Bowsher. -- 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/
linker can't find getsubopt()
Hi,
I try to compile this simple program on cygwin:
#include unistd.h
#include stdlib.h
#include stdio.h
int main()
{
getsubopt(0,0,0);
return 0;
}
gcc has no problem with the program, but when linking starts, the linker can't find
a reference to getsubopt.
I don't care about the program working or not, I just want to make it compile, as it
will solve
several problems porting a Linux program to CYGWIN.
Any ideas?
Maor Avni
--
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: grep -r *.java doesn't work as expected
Hi, Max, At 08:34 2003-01-19, Max Bowsher wrote: Randall R Schulz wrote: Grep _will_ search in files found throughout a directory hierarchy, but that's not it's default mode of operation. Look into the -R / -r / --recursive option and the associated --include and --exclude options. I didn't know about --include/--exclude - much simpler than find and xargs! Thanks! Also, I don't know what you intend by your use of -m That would be -rn, as in the contraction of -r -n :-) Indeed! I really wish my good monitor hadn't broken (when I myself am broke). Max Bowsher. Randall Schulz -- 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: linker can't find getsubopt()
It appears getsubopt is in newlib, and so present in Cygwin's sys/unistd.h, but not exported from cygwin1.dll One of Cygwin's core developers will need to tell us whether this is accidental or on purpose. Max. -- 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: gcc-2 ..../bin/as.exe: Permission denied
On Fri, Jan 17, 2003 at 04:35:15PM +1100, Brendan Kosowski wrote: I have just installed cygwin on win98se using setup.exe. I selected gcc-2 as the only extra on top of the base install. I told setup that I am the only user and I use unix style text files. When I run Cygwin Bash Shell and try to compile a C program in my home dir (eg. gcc-2 -o mytest.exe mytest.c ) I get the following error message: gcc-2: installation problem, cannot exec '/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/../../../../i686-pc-cygwin/ bin/as.exe': Permission denied Just curious; are you running Windows stand-alone, or in an emulated environment? I ran into a very similar problem as yours yesterday using gcc-3 (also running Windows 98 SE), but running under Win4Lin. What I found in my case is that Cygwin symbolic links lose the DOS system attribute after Win4Lin shuts down. Since .../i686-pc-cygwin/bin/as.exe is supposed to a symbolic link to /usr/bin/as.exe, gcc cannot run the assembler due to the broken symbolic link. I verified that this does not happen under a stand-alone (non-Win4Lin) Win98SE installation; the system attribute persists between reboots. Check the attributes for C:\cygwin\usr\i686-pc-cygwin\bin\as.exe from a DOS command line using the 'attrib' command. If the 'S' flag isn't displayed, then reset the system attributes using the command 'attrib +s *.exe'. -- Dario Alcocer -- Sr. Software Developer, Helix Digital Inc. [EMAIL PROTECTED] -- http://www.helixdigital.com -- 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: Unsubcribe
On Sun, Jan 19, 2003 at 03:00:48PM +0100, Peppino wrote: Alle 02:04, sabato 18 gennaio 2003, Christopher Faylor ha scritto: On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote: Chris, On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote: On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote: This should be fixed now. It was a simple mistake, as far as I could tell. How does the refreshed snapshot look? Looking good! I spoke too soon. I'm getting segmentation faults and stuff like the following by just running ls: $ uname -a CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown $ cd src/pgsql /home/jt/src/pgsql $ ls ... 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state (probably corrupted stack) Could you get a gdb backtrace of this problem? cgf * www.topdrin.com Solo il TOP per il tuo cellulare !! Una selezione di oltre 5000 loghi, suonerie e picture. What is that, again? You want to be blocked from sending email to any mailing list at sources.redhat.com? Sure. I can help you with that. cgf -- 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: linker can't find getsubopt()
On Sun, Jan 19, 2003 at 04:49:04PM -, Max Bowsher wrote: It appears getsubopt is in newlib, and so present in Cygwin's sys/unistd.h, but not exported from cygwin1.dll One of Cygwin's core developers will need to tell us whether this is accidental or on purpose. Oh, it's on purpose. Believe me. Caused someone some discomfort? Then our evil plan is succeeding. Core developers! Raise your glasses and repeat after me We are the core developers and we are MEAN! It's a well know fact that we put functions in unistd.h which are not actually exported by cygwin just to tantalize and confuse people. What other earthly reason would we have for dangling this tempting fruit in front of people, if not to frustrate them? Bwahahaha. cgf -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- 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: linker can't find getsubopt()
At 09:32 2003-01-19, Christopher Faylor wrote: On Sun, Jan 19, 2003 at 04:49:04PM -, Max Bowsher wrote: It appears getsubopt is in newlib, and so present in Cygwin's sys/unistd.h, but not exported from cygwin1.dll One of Cygwin's core developers will need to tell us whether this is accidental or on purpose. Oh, it's on purpose. Believe me. Caused someone some discomfort? Then our evil plan is succeeding. Core developers! Raise your glasses and repeat after me We are the core developers and we are MEAN! It's a well know fact that we put functions in unistd.h which are not actually exported by cygwin just to tantalize and confuse people. What other earthly reason would we have for dangling this tempting fruit in front of people, if not to frustrate them? Bwahahaha. cgf I'm on to you, Chaotica. Captain Proton -- 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/
Error Message
I keep getting this error msg at random times (including whenever I click on the Cygwin desktop icon: The procedure entry point libintl_bindtextdomain could not be located in the dynamic link library cygintl-2.dll. Any idea as to what is the problem? TIA Augy Thiel
Re: Error Message
Augy Thiel wrote: I keep getting this error msg at random times (including whenever I click on the Cygwin desktop icon: The procedure entry point libintl_bindtextdomain could not be located in the dynamic link library cygintl-2.dll. Any idea as to what is the problem? You have an out-of-date version of the libintl2 package installed. Install the latest version (0.11.5-1). Max. -- 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: linker can't find getsubopt()
On Sun, Jan 19, 2003 at 05:53:02PM -, Max Bowsher wrote: Christopher Faylor wrote: On Sun, Jan 19, 2003 at 04:49:04PM -, Max Bowsher wrote: It appears getsubopt is in newlib, and so present in Cygwin's sys/unistd.h, but not exported from cygwin1.dll One of Cygwin's core developers will need to tell us whether this is accidental or on purpose. --meanmeanmean Content-Language: cgf_mean Oh, it's on purpose. Believe me. Caused someone some discomfort? Then our evil plan is succeeding. Core developers! Raise your glasses and repeat after me We are the core developers and we are MEAN! It's a well know fact that we put functions in unistd.h which are not actually exported by cygwin just to tantalize and confuse people. What other earthly reason would we have for dangling this tempting fruit in front of people, if not to frustrate them? Bwahahaha. --meanmeanmean Attempting translation: cgf_mean - en_gb ... Translation not possible! Gist comprehended... Will you make the necessary adjustments to cygwin.din/version.h, or should I submit a patch? I don't think it is that simple. Cygwin doesn't use the getopt that comes with newlib. Is there supposed to be any correspondence between the getopt version and the getsubopt version? Take a look at cygwin/winsup/lib/getopt.c . Uh, I mean. Why should I care? Suffer! cgf -- 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: ssh with one agent for all bash´s
Nicolaie Szabadkai wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, looking up the mailinglist and testing a while I figured out that with following .bash_profile, I can have one ssh-agent thruoghout all sessions I open! Once the agent is running the following shells use it again! That's what keychain is for. Any special reason to reinvent the wheel, instead of using standard cygwin packages? sdesc: An OpenSSH key manager ldesc: Keychain is an OpenSSH key manager, typically run from ~/.bash_profile. When run, it will make sure ssh-agent is running; if not, it will start ssh-agent. It will redirect ssh-agent's output to ~/.ssh-agent, so that cron jobs that need to use ssh-agent keys can simply source this file and make the necessary passwordless ssh connections. In addition, when keychain runs, it will check with ssh-agent and make sure that the ssh RSA/DSA keys that you specified on the keychain command line have actually been added to ssh-agent. If not, you are prompted for the appropriate passphrases so that they can be added by keychain. If these descriptions weren't clear to you, any improvement to them are welcome. Although the first shell will not close by it self till the last one is gone. May be helpfull for anybody using ssh! #!/bin/bash trap ' if [ $(ps -fu `id -un`|grep -c bash) -eq 2 ] then test -n $SSH_AGENT_PID eval `ssh-agent -k` ; setx.exe SSH_AGENT_PID ; setx.exe SSH_AUTH_SOCK ; fi ' 0 ... if [ $SSH_AUTH_SOCK = ] then eval `ssh-agent`; /usr/bin/tty /dev/null ssh-add $HOME/.ssh/id_dsa; setx.exe SSH_AGENT_PID $SSH_AGENT_PID; setx.exe SSH_AUTH_SOCK $SSH_AUTH_SOCK; fi -BEGIN PGP SIGNATURE- Version: PGP 8.0 iQA/AwUBPiq++50aiFY+2vypEQKafQCdF+35SKzOgXQtK4PkQwpSowPzeaMAoI46 nONcpKXrLfs/ww3jdFTl6B0o =Gurg -END PGP SIGNATURE- -- 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/ -- Med venlig hilsen / Kind regards Hack Kampbjørn -- 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: Crash on startup - debugging info
On Sun, Jan 19, 2003 at 02:47:31AM -0500, Harold L Hunt II wrote: Okay, there are at least two problems happening in XWin.exe. The first problem is totally unrelated to the new multiwindow mode. The problem is, if you startup XWin.exe in gdb, a call to fchown causes a SIGSEGV on every single execution. That sucks. You can avoid that problem by setting a break in _XSERVTransSocketUNIXCreateListener, then stepping until right before the call to fchown, then ``set updateOwner=0'', which causes the call to be skipped. After that you can continue. In non-multiwindow mode the server will run fine after the continue. The second problem is that in multiwindow mode the call to pthread_mutex_init causes a SIGSEGV. That sucks too. I have peeked at the code for pthread_mutex, but I can't figure out much. I might eventually have to setup a cygwin1.dll build environment so I can debug this, but I would really like to avoid that if possible. I actually started building a debug version of cygwin1.dll tonight, but I got to the part where it needs libiberty and I wussed out. Have you tried continuing beyond the SIGSEGV? Some of the pthread code does a check of invalid memory and ends up raising an exception that is caught by the debugger. Unfortunately, there isn't much that gdb can do to detect that situation so we're stuck just continuing in that scenario. If a continue ends up leaving you in the same place then it really is a SIGSEGV. cgf -- 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: sshd: setgid() fails on second login
I have compiled and installed ssh.com's 3.2.2 ssh clients and daemon. I can start the daemon without a hitch. But the daemon is unable to authenticate the password, probably becasue the cygwin's libc password interface to the Win2K password authentication lib is not working. The ssh client re-prompts for the password 3 times, after which it bails out. The password I use is same as one I login into win2k with, with same user name. Has anyone been able to successfully connect to the ssh.com's sshd2 daemon running on Cygwin? Cheers, Joe __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- 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/
Porting GridEngine, almost there, just need some help linking...
Almost done compiling GridEngine to run under Cygwin. Having some trouble linking. I'm getting: ./librmon.a(rmon_macros.o)(.text+0xae0):rmon_macros.c: undefined reference to `_shmget' ./librmon.a(rmon_macros.o)(.text+0xb09):rmon_macros.c: undefined reference to `_shmat' ./librmon.a(rmon_macros.o)(.text+0xf2a):rmon_macros.c: undefined reference to `_shmdt' ./librmon.a(rmon_macros.o)(.text+0xf65):rmon_macros.c: undefined reference to `_shmctl' ./librmon.a(rmon_macros.o)(.text+0x1499):rmon_macros.c: undefined reference to `_shmdt' ./librmon.a(rmon_macros.o)(.text+0x14c7):rmon_macros.c: undefined reference to `_shmctl' linking errors when running the linker command: gcc -O2 -Wall -Werror -DLINUX -DLINUX6 -DCYGWIN -DCOMPILE_DC -D__SGE_NO_USERMAPPING__ -I../security/sec -I../common -I../libs/uti -I../libs/gdi -I../libs/spool -I../libs/spool/classic -I../libs/spool/flatfile -I../libs/cull -I../libs/rmon -I../libs/comm -I../libs/sched -I../daemons/common -I../daemons/commd -I../daemons/qmaster -I../daemons/execd -I../daemons/schedd -I../clients/common -I. -L. -o sge_commd commd.o message.o rwfd.o commproc.o process_received_message.o prolog.o deliver_message.o ack.o reset_messages_for_commproc.o setup_commd_path.o version.o commd_io.o -luti -lrmon -lm I had made the following symbolic links to get stuff to compile up to this point: /usr/include/cygwin/ipc.h - /usr/include/sys/ipc.h /usr/include/cygwin/sem.h - /usr/include/sys/sem.h /usr/include/cygwin/shm.h - /usr/include/sys/shm.h Now my question is: what library should I pass to the linker so the shared memory calls (shmget, etc.) being complained about are found? I tried -lcygwin but that wasn't it. Anyone have any suggestions? I thought shmget and such were in libc.a, but -lc didn't help the situation. Any help is greatly appreciated -- I'm so close to having binaries. Just need a little direction, I'm pretty green when it comes to cygwin porting. Thanks! Ian --- Ian R. Chesal [EMAIL PROTECTED] -- 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: Porting GridEngine, almost there, just need some help linking...
./librmon.a(rmon_macros.o)(.text+0xae0):rmon_macros.c: undefined reference to `_shmget' Ian, Do you have cygipc installed? I am presuming so as you have the headers (or do they default in cygwin?) installed so you needed to pass `-lcygipc' to the linker when your compiling or put it in the Makefile. If you don't already have cygipc you can find it here: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/ Elfyn [EMAIL PROTECTED] -- 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: Porting GridEngine, almost there, just need some help linking...
Elfyn, Thank you! I was missing the cygipc libraries. Strange though that Cygwin does ship with the IPC headers in /usr/include/cygwin/. Cheers! Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Elfyn McBratney Sent: January 19, 2003 9:18 PM To: cygwin; [EMAIL PROTECTED] Subject: Re: Porting GridEngine, almost there, just need some help linking... ./librmon.a(rmon_macros.o)(.text+0xae0):rmon_macros.c: undefined reference to `_shmget' Ian, Do you have cygipc installed? I am presuming so as you have the headers (or do they default in cygwin?) installed so you needed to pass `-lcygipc' to the linker when your compiling or put it in the Makefile. If you don't already have cygipc you can find it here: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/ Elfyn [EMAIL PROTECTED] -- 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/ -- 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/
Where is rresvport defined in the Cygwini distribution?
Again, this is related to porting GridEngine to cygwin. I have a file that says: #include unistd. and then calls rresvport(int *port). When I do a 'man rresvport' it looks like it should be in unistd.h but I can't find a prototype for the function in any header file. Can someone point me in the right direction? Thanks! Ian --- Ian R. Chesal [EMAIL PROTECTED] -- 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: Where is rresvport defined in the Cygwini distribution?
To answer my own question, adding: #ifdef CYGWIN extern int rresvport(int *port); #endif To the top of the file after the #includes seems to have solved the problem. Cheers! Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ian R. Chesal Sent: January 19, 2003 11:42 PM To: 'cygwin' Subject: Where is rresvport defined in the Cygwini distribution? Again, this is related to porting GridEngine to cygwin. I have a file that says: #include unistd. and then calls rresvport(int *port). When I do a 'man rresvport' it looks like it should be in unistd.h but I can't find a prototype for the function in any header file. Can someone point me in the right direction? Thanks! Ian --- Ian R. Chesal [EMAIL PROTECTED] -- 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/ -- 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: Make fails for various programs
Igor, bash is currently used. However, I have to investigate further on. * Autotools works if and only if CYGWIN = nontsec. * makewhatis fails (see also http://cygwin.com/ml/cygwin/2003-01/msg00829.html) * login does not work as expected * export does not work There is a lot to do and may I have to learn a lot Thanks for your message Petrik Igor Pechtchanski schrieb: 'export VAR=value' works in bash and ksh, but doesn't in ash (you need to use 'VAR=value; export VAR'). Perhaps that is your problem? Igor -- 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/
