* RE: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
[not found] <718198F862F1D411B10F0002A50A4DB101A4F0E8@e90wwce3.dx.deere .com>
@ 2001-12-18 16:29 ` Larry Hall (RFK Partners, Inc)
0 siblings, 0 replies; 7+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-12-18 16:29 UTC (permalink / raw)
To: cygwin
At 02:37 PM 12/17/2001, Polley Christopher W wrote:
> > > it. If you can, debugging Cygwin via gdb would be the best way to go.
> > > Alternatively, if you can't do that, calling gcc indirectly through
> > > strace in your IDE environment would provide some trace information
> >
> >
> Here is a strace snippet right around the error's occurrence:
>
> 09:19:17 [main] make 384 dtable::build_fhandler: fd 3, fh 0x61550820
> 09:19:17 [main] make 384 dtable::build_fhandler: fd 4, fh 0x61550960
> 09:19:17 [main] make 384 fhandler_base::init: created new
>fhandler_base for handle 0xD8
> 09:19:17 [main] make 384 fhandler_base::init: created new
>fhandler_base for handle 0x154
> 09:19:17 [main] make 384 make_pipe: 0 = make_pipe ([3, 4], 16384,
>0x10000)
> 09:19:17 [main] make 384 _close: close (4)
> 09:19:17 [main] make 384 fhandler_base::close: closing '(null)'
>handle 0x154
> 09:19:17 [main] make 384 dtable::not_open: in not_open,
>fds=0x61550128 fd=4 fds[fd]=1632962912 res=0 size=32
> 09:19:17 [main] make 384 _close: 0 = close (4)
> 09:19:17 [main] make 384 fhandler_base::set_close_on_exec: set
>close_on_exec for (null) to 1
> 09:19:17 [main] make 384 _fcntl: 0 = fcntl (3, 2, 0x1)
> 09:19:17 [main] make 384 set_process_mask: old mask = 0, new mask =
>1804007
> 09:19:17 [main] make 384 dtable::not_open: in not_open,
>fds=0x61550128 fd=0 fds[fd]=1632961224 res=0 size=32
> 09:19:17 [main] make 384 dtable::build_fhandler: fd -1, fh
>0x61550960
> 09:19:17 [main] make 384 fhandler_base::dup: in fhandler_base dup
> 09:19:17 [main] make 384 fhandler_base::dup: dup(unknown disk file)
>failed, handle 0, Win32 error 6
> 09:19:17 [main] make 384 seterrno_from_win_error:
>/usr/src/cygwin/winsup/cygwin/fhandler.cc:926 errno 6
> 09:19:17 [main] make 384 geterrno_from_win_error: windows error 6 ==
>errno 9
> 09:19:17 [main] make 384 vfork: 0 = vfork()
> 09:19:17 [main] make 384 vfork: exiting vfork, res 0
>
> I'm not sure how far back is relevant to the vfork's setting up for
>the make-file's "echo" command that occurs next vs. cleaning up from
>checking dependencies (the previous task make was doing)
>
> the build_fhandler: fd=-1 is expected; that's a new dtable being
>built, so aside from that the error occurring in fhandler_base::dup (which
>we already knew) there's no new info.
>
> Larry, would posting a complete strace be useful? What might I look
>for in the strace?
It sounds to me like you've been debugging the code. strace output is
sometimes a helpful resource when doing this but only to the extent that
it leads you to the problem in the source. If you've spent the time
poking around in the debugger, I'll wager you've amassed more information
about the problem than strace will ever give you. I'd recommend continuing
down the debugging avenue you're following. Don't let my comments about
strace output sidetrack you.
Larry Hall lhall@rfk.com
RFK Partners, Inc. http://www.rfk.com
838 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
--
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
2002-01-08 7:26 Polley Christopher W
@ 2002-01-08 7:49 ` Christopher Faylor
0 siblings, 0 replies; 7+ messages in thread
From: Christopher Faylor @ 2002-01-08 7:49 UTC (permalink / raw)
To: cygwin
On Tue, Jan 08, 2002 at 09:26:00AM -0600, Polley Christopher W wrote:
>I think I've found the cause of this.
>
>I'll summarize the problem, since this is an old thread:
>when a Windows GUI IDE calls gcc or make, the process reports
>"fhandler_base::dup: dup(unknown disk file) failed, handle 0, Win32 error 6"
>and crashes.
>
>The problem seems to occur when the [non-cygwin] application calls the
>windows CreateProcess API function with one or more of the
>STARTUPINFO.hStdInput, .hStdOutput, or .hStdError handles set to NULL; and
>STARTF_USESTDHANDLES is set in StartupInfo.dwFlags.
This should be fixed in current snapshots.
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
@ 2002-01-08 7:26 Polley Christopher W
2002-01-08 7:49 ` Christopher Faylor
0 siblings, 1 reply; 7+ messages in thread
From: Polley Christopher W @ 2002-01-08 7:26 UTC (permalink / raw)
To: 'cygwin@cygwin.com'
I think I've found the cause of this.
I'll summarize the problem, since this is an old thread:
when a Windows GUI IDE calls gcc or make, the process reports
"fhandler_base::dup: dup(unknown disk file) failed, handle 0, Win32 error 6"
and crashes.
The problem seems to occur when the [non-cygwin] application calls the
windows CreateProcess API function with one or more of the
STARTUPINFO.hStdInput, .hStdOutput, or .hStdError handles set to NULL; and
STARTF_USESTDHANDLES is set in StartupInfo.dwFlags.
The MSDN documentation is silent on the topic of calling CreateProcess with
STARTUPINFO in this state, so I guess this falls under the realm of
"undefined behavior", but at least some windows programs call this function
without hStdInput set.
I've found that in dtable::vfork_child_dup (), where each open fd in the fd
table is dup'ed if it is open, that if a check for a null handle is added,
the problem disappears:
diff cygwin-1.3.6-6/winsup/cygwin/dtable.cc
cygwin-1.3.6-6-orig/winsup/cygwin/dtable.cc
565c565
< if (not_open (i) || (fds[i]->get_handle() == NULL) )
---
> if (not_open (i))
Will this break anything else? (i.e. are there occasions where a valid open
file handle might be 0?)
I've taken a glance at the testsuite directory -- is a successful "make
check" the benchmark? What other tests should I run?
BTW, I noticed in the definition of not_open (in dtable.h), that the
ResourceLock is set with the string "not_open" and then released with the
string "not open". Does this inconsistency matter? I haven't noted any
effects (good or bad) of changing the second to "not_open" (to match the
function name):
diff cygwin-1.3.6-6/winsup/cygwin/dtable.h
cygwin-1.3.6-6-orig/winsup/cygwin/dtable.h
62c62
< ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not_open");
---
> ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not open");
Warm Regards,
Chris
--
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
@ 2001-12-17 12:19 Polley Christopher W
0 siblings, 0 replies; 7+ messages in thread
From: Polley Christopher W @ 2001-12-17 12:19 UTC (permalink / raw)
To: 'cygwin@cygwin.com'
> > it. If you can, debugging Cygwin via gdb would be the best way to go.
> > Alternatively, if you can't do that, calling gcc indirectly through
> > strace in your IDE environment would provide some trace information
>
>
Here is a strace snippet right around the error's occurrence:
09:19:17 [main] make 384 dtable::build_fhandler: fd 3, fh 0x61550820
09:19:17 [main] make 384 dtable::build_fhandler: fd 4, fh 0x61550960
09:19:17 [main] make 384 fhandler_base::init: created new
fhandler_base for handle 0xD8
09:19:17 [main] make 384 fhandler_base::init: created new
fhandler_base for handle 0x154
09:19:17 [main] make 384 make_pipe: 0 = make_pipe ([3, 4], 16384,
0x10000)
09:19:17 [main] make 384 _close: close (4)
09:19:17 [main] make 384 fhandler_base::close: closing '(null)'
handle 0x154
09:19:17 [main] make 384 dtable::not_open: in not_open,
fds=0x61550128 fd=4 fds[fd]=1632962912 res=0 size=32
09:19:17 [main] make 384 _close: 0 = close (4)
09:19:17 [main] make 384 fhandler_base::set_close_on_exec: set
close_on_exec for (null) to 1
09:19:17 [main] make 384 _fcntl: 0 = fcntl (3, 2, 0x1)
09:19:17 [main] make 384 set_process_mask: old mask = 0, new mask =
1804007
09:19:17 [main] make 384 dtable::not_open: in not_open,
fds=0x61550128 fd=0 fds[fd]=1632961224 res=0 size=32
09:19:17 [main] make 384 dtable::build_fhandler: fd -1, fh
0x61550960
09:19:17 [main] make 384 fhandler_base::dup: in fhandler_base dup
09:19:17 [main] make 384 fhandler_base::dup: dup(unknown disk file)
failed, handle 0, Win32 error 6
09:19:17 [main] make 384 seterrno_from_win_error:
/usr/src/cygwin/winsup/cygwin/fhandler.cc:926 errno 6
09:19:17 [main] make 384 geterrno_from_win_error: windows error 6 ==
errno 9
09:19:17 [main] make 384 vfork: 0 = vfork()
09:19:17 [main] make 384 vfork: exiting vfork, res 0
I'm not sure how far back is relevant to the vfork's setting up for
the make-file's "echo" command that occurs next vs. cleaning up from
checking dependencies (the previous task make was doing)
the build_fhandler: fd=-1 is expected; that's a new dtable being
built, so aside from that the error occurring in fhandler_base::dup (which
we already knew) there's no new info.
Larry, would posting a complete strace be useful? What might I look
for in the strace?
Warm Regards,
Chris
--
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
@ 2001-12-17 11:39 Polley Christopher W
0 siblings, 0 replies; 7+ messages in thread
From: Polley Christopher W @ 2001-12-17 11:39 UTC (permalink / raw)
To: 'Larry Hall (RFK Partners, Inc)', Suman Kumar Ray, cygwin
[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]
I've been looking into this problem myself, (see last month's thread
starting with http://www.cygwin.com/ml/cygwin/2001-11/msg01217.html )
and have gotten to this point: at the point where vfork is duplicating the
fhandler table and dup'ing open fh's it somehow isn't detecting that stdin
isn't connected to anything. (see dtable::vfork_child_dup () in dtable.cc,
line 553)
Where i'm stuck is figuring out why fh 0 has status of 0x18010 (FH_DISK,
FH_RBINSET, FH_SYMLINK). Shouldn't fh 0 point to stdin?
The file name is a null string, so there's no help there.
BTW, I've written a short windows program to launch make (which i've
recompiled with support for the -D switch, to give me time to attach gdb --
gdb'ing the test-make program doesn't seem to work) here it is:
<<test-make.c>>
It seems that there have been reports of this for gcc and make (my guess is
that it probably happens for all cygwin programs that launch other programs
as child processes) when launched using the windows CreateProcess API call.
Does anyone know how the cygwin dll handles CreateProcess calls in these
cases?
Warm Regards,
Chris
> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [SMTP:lhall@rfk.com]
> Sent: Monday, December 17, 2001 12:52 PM
> To: Suman Kumar Ray; cygwin@cygwin.com
> Subject: Re: cygwin1.dll (file version 1003.6.0.0) dup problem with
> gcc
>
> At 01:40 PM 12/17/2001, Suman Kumar Ray wrote:
>
> >Hi,
> > In the mailing list, I have found this problem with
> >earlier dll but with no solution or information
> >whether this is a bug of cygwin.
> >If I use cygwin.dll file version 1003.6.0.0, then when
> >a windows GUI based IDE is calling gcc through
> >createprocess and pass a file for compilation error
> >message appears as
> >fhandler_base::dup: dup(unknown disk file) failed,
> >handle 0, Win32 error 6. If I use cygwin1.dll file
> >version 1003.2.0.0 ( I mean I put gcc in separate
> >directory and put 1003.2.0.0 cygwin1.dll there), no
> >problem in calling gcc from IDE. Interestingly, if I
> >open cygwin shell, within that I can compile using any
> >of the above dlls.
> > Can somebody please tell me, what is the problem, and
> >how to rectify it ?
> > I have tried following command after reading one
> >e-mail, but no success.
> > mount -b --change-cygdrive-prefix /cygdrive
>
> Right. This isn't a cygdrive issue so I wouldn't expect to see any
> significant change by altering the mount option here.
>
> Clearly, fhandler::dup() is getting an invalid handle ('net helpmsg 6'
> tells you that). Given that the handle is 0, I think it's clear that
> this complaint is valid. Beyond that though, you're going to need to
> dig a little deeper to find the root of the problem. The issue is
> internal, which would require debugging to find the cause and correct
> it. If you can, debugging Cygwin via gdb would be the best way to go.
> Alternatively, if you can't do that, calling gcc indirectly through
> strace in your IDE environment would provide some trace information
> that might help you or others better understand the problem.
>
> Good luck,
>
>
> Larry Hall lhall@rfk.com
> RFK Partners, Inc. http://www.rfk.com
> 838 Washington Street (508) 893-9779 - RFK Office
> Holliston, MA 01746 (508) 893-9889 - FAX
>
>
> --
> 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/
>
[-- Attachment #2: test-make.c --]
[-- Type: application/octet-stream, Size: 6788 bytes --]
#include <stdio.h>
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#define BUFSIZE 4096
#define IDW_STATUS 010
LRESULT WINAPI MainWndProc
( HWND, UINT, WPARAM, LPARAM );
BOOL
StatusWrite (char *);
BOOL
ReadFromPipe(HANDLE);
BOOL
CreateChildProcess(VOID);
HWND hwndStatus; // handle to status window
HINSTANCE hInst; // current instance
HANDLE PipeReadHandle;
HANDLE PipeWriteHandle;
BOOL ReadPipeOK = FALSE;
int WINAPI WinMain
( HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpszCmdLine,
int nCmdShow
)
{ WNDCLASS wc;
MSG msg;
HWND hWnd;
hInst = hInstance; // Store instance handle in our global variable
wc.lpszClassName = "TestClass";
wc.lpfnWndProc = MainWndProc;
wc.style = CS_VREDRAW | CS_HREDRAW;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon( NULL, IDI_APPLICATION );
wc.hCursor = LoadCursor( NULL, IDC_ARROW );
wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = NULL;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
RegisterClass( &wc );
hWnd = CreateWindow
( wc.lpszClassName,
"Testing Make",
WS_OVERLAPPEDWINDOW|WS_HSCROLL|WS_VSCROLL,
0,
0,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL
);
ShowWindow( hWnd, nCmdShow );
while( GetMessage( &msg, NULL, 0, 0 ) )
{ TranslateMessage( &msg );
DispatchMessage( &msg );
if (ReadPipeOK)
{
ReadPipeOK = ReadFromPipe(PipeReadHandle);
} else {
StatusWrite("Read Pipe Failed");
}
}
return msg.wParam;
}
LRESULT CALLBACK MainWndProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
{ PAINTSTRUCT ps;
HDC hDC;
switch( msg )
{ case WM_CREATE:
// Create an MLE for status messages
hwndStatus = CreateWindow ("LISTBOX", // Class
NULL, // Window Name
WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL, // Style
0, 0, 0, 0, // x, y, Width, Height
hWnd, // Parent Window
(HMENU) IDW_STATUS, // Child ID
hInst, // Application instance
NULL); // Window-creation data
Sleep(5);
StatusWrite("Creating Child Process");
if (CreateChildProcess()) {
StatusWrite("CreateChildProcess Completed OK");
ReadPipeOK = TRUE;
}
else {
StatusWrite("CreateChildProcess Completed Not OK");
}
break;
case WM_PAINT:
hDC = BeginPaint( hWnd, &ps );
EndPaint( hWnd, &ps );
break;
case WM_DESTROY:
PostQuitMessage( 0 );
break;
case WM_SIZE:
// Make the edit control the size of the window's client area.
MoveWindow (hwndStatus, 0, 0, LOWORD (lParam), HIWORD (lParam), TRUE);
default:
return( DefWindowProc( hWnd, msg, wParam, lParam ));
}
return 0;
}
//---------------------------------------------------------------------------
// FUNCTION: StatusWrite ( char * szText )
// COMMENTS: Writes the specified string to the status window
//
// Uses the buffer pointed to by hmemStatusBuf (of size MAX_STATUS_BUFFER)
// (effectively a zero-terminated string)
// Converts \n to \r\n for proper line-breaks
//
// Returns FALSE if no error, TRUE if error locating buffer
//---------------------------------------------------------------------------
void
AppendText (char *szText)
{
DWORD dwLogLength;
const DWORD dwMAX_LOG_LENGTH = 10000;
dwLogLength = SendMessage (hwndStatus, LB_GETCOUNT, 0, 0);
while (dwLogLength > dwMAX_LOG_LENGTH)
{
SendMessage (hwndStatus, LB_DELETESTRING, (WPARAM) 0,
(LPARAM) 0);
-- dwLogLength;
}
// insert text
SendMessage (hwndStatus, LB_INSERTSTRING, (WPARAM) dwLogLength, (LPARAM) szText);
}
BOOL
StatusWrite (char *szText)
{
char szBuffer[BUFSIZ];
char *szCurrentPosition = szText;
char *szEnd = szText + strlen (szText);
char *szLineEnd;
int HasCR = 0;
while (szCurrentPosition < szEnd)
{
memset (szBuffer, (int) '\0', BUFSIZ);
if ((szLineEnd = strchr (szCurrentPosition, (int) '\n')) == 0)
szLineEnd = szEnd;
if (*(szLineEnd - 1) == '\r')
HasCR = 1;
else
HasCR = 0;
strncat (szBuffer, szCurrentPosition,
(int) ((szLineEnd - HasCR) - szCurrentPosition));
szCurrentPosition = szLineEnd + 1;
AppendText (szBuffer);
}
return (FALSE);
}
BOOL CreateChildProcess(VOID)
{
SECURITY_ATTRIBUTES SecurityAttributes;
STARTUPINFO StartupInfo;
PROCESS_INFORMATION ProcessInfo;
ZeroMemory( &StartupInfo, sizeof( StartupInfo ));
ZeroMemory( &ProcessInfo, sizeof( ProcessInfo ));
ZeroMemory( &SecurityAttributes, sizeof( SecurityAttributes ));
SecurityAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
SecurityAttributes.bInheritHandle = TRUE;
SecurityAttributes.lpSecurityDescriptor = NULL;
CreatePipe
(
&PipeReadHandle, // address of variable for read handle
&PipeWriteHandle, // address of variable for write handle
&SecurityAttributes, // pointer to security attributes
0 // default num bytes reserved for pipe
);
StartupInfo.cb = sizeof(STARTUPINFO);
StartupInfo.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
StartupInfo.wShowWindow = SW_HIDE;
StartupInfo.hStdOutput = PipeWriteHandle;
StartupInfo.hStdError = PipeWriteHandle;
return CreateProcess
(
NULL, // pointer to name of executable module
//LPTSTR(
"c:\\cygwin\\bin\\make.exe -D test-cygwin",//), // command line
NULL, // pointer to process security attributes
NULL, // pointer to thread security attributes (use primary thread security attributes)
TRUE, // inherit handles
0, // creation flags
NULL, // pointer to new environment block(use parent's)
"c:\\cygwin\\usr\\local\\src\\test-make", // pointer to current directory name
&StartupInfo, // pointer to STARTUPINFO
&ProcessInfo // pointer to PROCESS_INFORMATION
);
}
BOOL ReadFromPipe(HANDLE hFile)
{
DWORD dwRead, dwBytesAvaliable, dwBytesLeft;
char chBuf[BUFSIZE];
// Read output from the child process, and write to parent's STDOUT.
memset (chBuf, (int) '\0', BUFSIZ);
if( !PeekNamedPipe( hFile, chBuf, BUFSIZE, &dwRead,
&dwBytesAvaliable, &dwBytesLeft) )
{
return FALSE;
} else if ( dwBytesAvaliable != 0 &&
ReadFile( hFile, chBuf, BUFSIZE, &dwRead,
NULL) && dwRead != 0)
{
chBuf[dwRead] = 0;
StatusWrite(chBuf);
}
return TRUE;
}
[-- Attachment #3: Type: text/plain, Size: 214 bytes --]
--
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
2001-12-17 10:54 Suman Kumar Ray
@ 2001-12-17 11:25 ` Larry Hall (RFK Partners, Inc)
0 siblings, 0 replies; 7+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-12-17 11:25 UTC (permalink / raw)
To: Suman Kumar Ray, cygwin
At 01:40 PM 12/17/2001, Suman Kumar Ray wrote:
>Hi,
> In the mailing list, I have found this problem with
>earlier dll but with no solution or information
>whether this is a bug of cygwin.
>If I use cygwin.dll file version 1003.6.0.0, then when
>a windows GUI based IDE is calling gcc through
>createprocess and pass a file for compilation error
>message appears as
>fhandler_base::dup: dup(unknown disk file) failed,
>handle 0, Win32 error 6. If I use cygwin1.dll file
>version 1003.2.0.0 ( I mean I put gcc in separate
>directory and put 1003.2.0.0 cygwin1.dll there), no
>problem in calling gcc from IDE. Interestingly, if I
>open cygwin shell, within that I can compile using any
>of the above dlls.
> Can somebody please tell me, what is the problem, and
>how to rectify it ?
> I have tried following command after reading one
>e-mail, but no success.
> mount -b --change-cygdrive-prefix /cygdrive
Right. This isn't a cygdrive issue so I wouldn't expect to see any
significant change by altering the mount option here.
Clearly, fhandler::dup() is getting an invalid handle ('net helpmsg 6'
tells you that). Given that the handle is 0, I think it's clear that
this complaint is valid. Beyond that though, you're going to need to
dig a little deeper to find the root of the problem. The issue is
internal, which would require debugging to find the cause and correct
it. If you can, debugging Cygwin via gdb would be the best way to go.
Alternatively, if you can't do that, calling gcc indirectly through
strace in your IDE environment would provide some trace information
that might help you or others better understand the problem.
Good luck,
Larry Hall lhall@rfk.com
RFK Partners, Inc. http://www.rfk.com
838 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
--
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
@ 2001-12-17 10:54 Suman Kumar Ray
2001-12-17 11:25 ` Larry Hall (RFK Partners, Inc)
0 siblings, 1 reply; 7+ messages in thread
From: Suman Kumar Ray @ 2001-12-17 10:54 UTC (permalink / raw)
To: cygwin
Hi,
In the mailing list, I have found this problem with
earlier dll but with no solution or information
whether this is a bug of cygwin.
If I use cygwin.dll file version 1003.6.0.0, then when
a windows GUI based IDE is calling gcc through
createprocess and pass a file for compilation error
message appears as
fhandler_base::dup: dup(unknown disk file) failed,
handle 0, Win32 error 6. If I use cygwin1.dll file
version 1003.2.0.0 ( I mean I put gcc in separate
directory and put 1003.2.0.0 cygwin1.dll there), no
problem in calling gcc from IDE. Interestingly, if I
open cygwin shell, within that I can compile using any
of the above dlls.
Can somebody please tell me, what is the problem, and
how to rectify it ?
I have tried following command after reading one
e-mail, but no success.
mount -b --change-cygdrive-prefix /cygdrive
Thanks,
Suman
Cygnus Win95/NT Configuration Diagnostics
Current System Time: Mon Dec 17 12:17:45 2001
Windows 2000 Professional Ver 5.0 Build 2195 Service
Pack 1, RC 1.1
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
d:\Perl\bin\
c:\Siebel2k\bin
.
c:\Oracle\Ora81\bin
c:\Program Files\Oracle\jre\1.1.7\bin
.
c:\WINNT\system32
c:\WINNT
c:\WINNT\System32\Wbem
c:\WINNT\system32
c:\WINNT
c:\WINNT\System32\Wbem
c:\ntutils
c:\Scripts
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
HOME = `C:\cygwin\home\Batwings'
MAKE_MODE = `unix'
PWD = `/home/Batwings'
USER = `Batwings'
ALLUSERSPROFILE = `D:\Profiles\All Users'
APPDATA = `D:\Profiles\r54666\Application Data'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `ZIN10WSS-L2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
DIRCMD = `/ogn'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\ZIN10WSS-L2'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/usr/bin'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
PATHEXT =
`.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping
10, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `080a'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `d:\Profiles\r54666\LOCALS~1\Temp'
TERM = `cygwin'
USERDOMAIN = `SPS'
USERNAME = `r54666'
USERPROFILE = `D:\Profiles\r54666'
WINDIR = `C:\WINNT'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus
Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x00000022
HKEY_CURRENT_USER\Software\Cygnus
Solutions\Cygwin\mounts v2\/
(default) = `C:\cygwin'
flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus
Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:/cygwin/bin'
flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus
Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:/cygwin/lib'
flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus
Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\00
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\01
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\02
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\03
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\04
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\05
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\06
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\07
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\08
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\09
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0A
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0B
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0C
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0D
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0E
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0F
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\10
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\11
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\12
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\13
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\14
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\15
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\16
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\17
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\18
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\19
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1A
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1B
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1C
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1D
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
Menu\Programs\Cygnus Solutions
(default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
a: fd N/A N/A
c: hd NTFS 8197Mb 83% CP CS UN PA FC SYSTEM
d: hd NTFS 10879Mb 45% CP CS UN PA FC DATA
e: cd N/A N/A
g: net NTFS 307212Mb 96% CP CS UN PA HOME
h: net NTFS 307212Mb 96% CP CS UN PA HOME
C:\cygwin / user textmode
C:/cygwin/bin /usr/bin user textmode
C:/cygwin/lib /usr/lib user textmode
. /cygdrive user binmode,noumount
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
Found: \bin\sh.exe
Warning: C:\cygwin\bin\sh.exe hides \bin\sh.exe
56k 2000/12/03 C:\cygwin\bin\cygbz21.0.dll - os=4.0
img=1.0 sys=4.0
"cygbz21.0.dll" v0.0 ts=2000/11/20
17:53
821k 2001/11/19 C:\cygwin\bin\cygcrypto.dll - os=4.0
img=1.0 sys=4.0
"cygcrypto.dll" v0.0 ts=2001/11/19
17:42
34k 2001/09/30 C:\cygwin\bin\cygform6.dll - os=4.0
img=1.0 sys=4.0
"cygform6.dll" v0.0 ts=2001/9/29
21:43
18k 2000/10/23 C:\cygwin\bin\cyggdbm.dll - os=4.0
img=1.0 sys=4.0
"cyggdbm.dll" v0.0 ts=2000/10/22
21:26
17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll -
os=4.0 img=1.0 sys=4.0
"cyghistory4.dll" v0.0 ts=2001/1/6
22:34
21k 2001/06/28 C:\cygwin\bin\cyghistory5.dll -
os=4.0 img=1.0 sys=4.0
"cyghistory5.dll" v0.0 ts=2001/6/27
21:27
21k 2001/06/20 C:\cygwin\bin\cygintl.dll - os=4.0
img=1.0 sys=4.0
"cygintl.dll" v0.0 ts=2001/6/20
12:09
81k 2001/10/20 C:\cygwin\bin\cygitcl30.dll - os=4.0
img=1.0 sys=4.0
"cygitcl30.dll" v0.0 ts=2001/10/19
19:25
35k 2001/10/20 C:\cygwin\bin\cygitk30.dll - os=4.0
img=1.0 sys=4.0
"cygitk30.dll" v0.0 ts=2001/10/19
19:25
45k 2001/07/04 C:\cygwin\bin\cygjbig1.dll - os=4.0
img=1.0 sys=4.0
"cygjbig1.dll" v0.0 ts=2001/7/3
22:25
119k 2001/06/06 C:\cygwin\bin\cygjpeg6b.dll - os=4.0
img=1.0 sys=4.0
"cygjpeg6b.dll" v0.0 ts=2001/6/5
23:27
19k 2001/09/30 C:\cygwin\bin\cygmenu6.dll - os=4.0
img=1.0 sys=4.0
"cygmenu6.dll" v0.0 ts=2001/9/29
21:43
175k 2001/09/30 C:\cygwin\bin\cygncurses++6.dll -
os=4.0 img=1.0 sys=4.0
"cygncurses++6.dll" v0.0
ts=2001/9/29 21:45
201k 2001/09/30 C:\cygwin\bin\cygncurses6.dll -
os=4.0 img=1.0 sys=4.0
"cygncurses6.dll" v0.0 ts=2001/9/29
21:42
12k 2001/09/30 C:\cygwin\bin\cygpanel6.dll - os=4.0
img=1.0 sys=4.0
"cygpanel6.dll" v0.0 ts=2001/9/29
21:43
40k 2001/11/21 C:\cygwin\bin\cygpcre.dll - os=4.0
img=1.0 sys=4.0
"cygpcre.dll" v0.0 ts=2001/11/21
16:15
39k 2001/11/21 C:\cygwin\bin\cygpcreposix.dll -
os=4.0 img=1.0 sys=4.0
"cygpcreposix.dll" v0.0
ts=2001/11/21 16:15
163k 2001/05/06 C:\cygwin\bin\cygpng2.dll - os=4.0
img=1.0 sys=4.0
"cygpng2.dll" v0.0 ts=2001/5/5 23:05
108k 2001/06/28 C:\cygwin\bin\cygreadline4.dll -
os=4.0 img=1.0 sys=4.0
"cygreadline4.dll" v0.0 ts=2001/1/6
22:34
135k 2001/06/28 C:\cygwin\bin\cygreadline5.dll -
os=4.0 img=1.0 sys=4.0
"cygreadline5.dll" v0.0 ts=2001/6/27
21:27
66k 2001/11/20 C:\cygwin\bin\cygregex.dll - os=4.0
img=1.0 sys=4.0
"cygregex.dll" v0.0 ts=2001/11/20
8:44
231k 2001/11/19 C:\cygwin\bin\cygssl.dll - os=4.0
img=1.0 sys=4.0
"cygssl.dll" v0.0 ts=2001/11/19
17:42
390k 2001/10/20 C:\cygwin\bin\cygtcl80.dll - os=4.0
img=1.0 sys=4.0
"cygtcl80.dll" v0.0 ts=2001/10/19
19:24
5k 2001/10/20 C:\cygwin\bin\cygtclpip80.dll -
os=4.0 img=1.0 sys=4.0
10k 2001/10/20 C:\cygwin\bin\cygtclreg80.dll -
os=4.0 img=1.0 sys=4.0
"cygtclreg80.dll" v0.0 ts=2001/10/19
19:24
245k 2001/06/12 C:\cygwin\bin\cygtiff3.dll - os=4.0
img=1.0 sys=4.0
"cygtiff3.dll" v0.0 ts=2001/6/12
12:25
623k 2001/10/20 C:\cygwin\bin\cygtk80.dll - os=4.0
img=1.0 sys=4.0
"cygtk80.dll" v0.0 ts=2001/10/19
19:25
41k 2001/07/04 C:\cygwin\bin\cygXpm-noX4.dll -
os=4.0 img=1.0 sys=4.0
"cygXpm-noX4.dll" v0.0 ts=2001/7/3
20:21
45k 2001/07/04 C:\cygwin\bin\cygXpm-X4.dll - os=4.0
img=1.0 sys=4.0
"cygXpm-X4.dll" v0.0 ts=2000/11/19
20:45
49k 2001/02/03 C:\cygwin\bin\cygz.dll - os=4.0
img=1.0 sys=4.0
"cygz.dll" v0.0 ts=2001/2/3 14:35
720k 2001/12/08 C:\cygwin\bin\cygwin1.dll - os=4.0
img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2001/12/8
16:02
Cygwin DLL version info:
DLL version: 1.3.6
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 47
Shared data: 3
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: mounts v2
Cygdrive flags: cygdrive flags
Cygdrive prefix: cygdrive prefix
Cygdrive default prefix:
Build date: Sat Dec 8 17:02:30 EST 2001
CVS tag: cygwin-1-3-6-6
Shared id: cygwin1S3
Cygwin Package Information
Last downloaded files to: c:\temp
Last downloaded files from:
http://mirrors.rcn.net/pub/sourceware/cygwin
Package Version
ash 20011018-1
autoconf 2.52-5
autoconf-stable 2.13-4
automake 1.5b-1
automake-stable 1.4p5-5
bash 2.05a-2
binutils 20011002-1
bison 1.28-1
byacc 0.0
bzip2 1.0.1-6
clear 1.0
cpio 2.4.2
cron 3.0.1-5
crypt 1.0-1
ctags 5.0.1-1
cvs 1.11.0-1
cygrunsrv 0.94-2
cygwin 1.3.6-6
dejagnu 20010117-1
diff 0.0
expect 20010117-1
file 3.33-1
fileutils 4.1-1
findutils 4.1
flex 2.5.4-1
gawk 3.0.4-1
gcc 2.95.3-5
gdb 20010428-3
gdbm 1.8.0-3
gettext 0.10.38-2
ghostscript 6.51-1
gperf 0.0
grep 2.4.2-1
groff 1.17.2-1
gzip 1.3.2-1
inetutils 1.3.2-16
irc 20010101-1
jbigkit 1.2-4
jpeg 6b-4
less 358-3
libncurses5 5.2-1
libncurses6 5.2-2
libpng 1.0.11-1
login 1.4-2
lynx 2.8.4-1
m4 0.0
make 3.79.1-5
man 1.5g-2
mingw 20010424-1
mktemp 1.4-1
mt 2.0.1-1
mutt 1.2.5i-6
ncftp 3.0.2-2
ncurses 5.2-7
newlib-man 20001118-1
opengl 1.1.0-5
openssh 3.0.2p1-2
openssl 0.9.6b-2
patch 2.5-2
pcre 3.7-1
perl 5.6.1-2
popt 1.6.2-1
postgresql 7.1.3-1
python 2.1.1-2
readline 4.2-3
regex 4.4-2
rsync 2.4.6-3
rxvt 2.7.2-6
sed 3.02-1
sh-utils 2.0-2
squid 2.4-STABLE20010508
ssmtp 2.38.7-3
tar 1.13.19-1
tcltk 20001125-1
tcsh 6.10.00-3
termcap 20010825-1
terminfo 5.2-1
tetex-beta 20001218-1
texinfo 4.0-5
textutils 2.0.16-1
tiff 3.5.6beta-2
time 1.7-1
unzip 5.41-1
vim 6.0.93-1
w32api 1.2-1
wget 1.7-1
which 1.5-1
xpm-nox 4.1.0-1
zip 2.3-1
zlib 1.1.3-6
__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.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/
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-01-08 15:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <718198F862F1D411B10F0002A50A4DB101A4F0E8@e90wwce3.dx.deere .com>
2001-12-18 16:29 ` cygwin1.dll (file version 1003.6.0.0) dup problem with gcc Larry Hall (RFK Partners, Inc)
2002-01-08 7:26 Polley Christopher W
2002-01-08 7:49 ` Christopher Faylor
-- strict thread matches above, loose matches on Subject: below --
2001-12-17 12:19 Polley Christopher W
2001-12-17 11:39 Polley Christopher W
2001-12-17 10:54 Suman Kumar Ray
2001-12-17 11:25 ` Larry Hall (RFK Partners, Inc)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).