headers
Igor Pechtchanski | 1 Nov 2002 01:42
Picon

Re: Environment windows not opening

On Thu, 31 Oct 2002 john_staroba <at> agilent.com wrote:

> I just installed cygwin without any trouble. The command prompt window
> appears to be working fine, as does the vi editor. When attempting to
> launch an xwindow, only the main window will open and the system
> apparently hangs. Prompt window displays
> ..
> ..
> ..
> ..
> until you close the main xwindow, and then displays:
>
> giving up.
> xinit: No such file or directory <errno 2>: unable to connect to X server
> xinit: No such process <errno 3>: Server error.
>
> I'm running win NT. Any ideas on what to do?

Yes.  Run an X server.  For details, see http://xfree86.cygwin.com/
If you have problems, please direct any queries to the cygwin-xfree list
(I set the Reply-To: field to it, and also Cc'd this message there).
	Igor
--

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha <at> cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor <at> watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pierre A. Humblet | 1 Nov 2002 01:55
Picon

Re: 1.3.14 Permission denied while doing a touch on MVFS

On Thu, Oct 31, 2002 at 03:22:18PM -0800, Andrew DeFaria wrote:
> I just installed 1.3.14 and am now experiencing problems with permission 
> denied when doing a touch but only when working on Clearcase's MVFS file 
> system (i.e. a dynamic view). AFAICT I do have ntsec set and a proper 
> /etc/passwd file, etc. This all sounds like other permissions problems 
> that I've read about recently but the kicker is that in involves a 3rd 
> party file system from Rational, Clearcase's MVFS file system. Here's an 
> example:
> 
I am also using Clearcase at work and for as long as I can remember 
cp -p produced an error saying times can't be preserved.
The touch is failing in SetFileTime with error 5, indicating a Windows problem.
The mystery is why it fails now and on that machine.
Does it still fail if you set nontsec in CYGWIN?

Pierre
Permalink | Reply | 0 comments |
headers
abarto | 1 Nov 2002 02:04

Problem Compiling Cygwin Source

I'm trying to compile compile the cygwin source and I get the following error:

c++ -L/tmp/i686-pc-cygwin/winsup -L/tmp/i686-pc-cygwin/winsup/cygwin -L/tmp/i686
-pc-cygwin/winsup/w32api/lib -isystem /usr/src/cygwin-1.3.14-1/winsup/include -i
system /usr/src/cygwin-1.3.14-1/winsup/cygwin/include -isystem /usr/src/cygwin-1
.3.14-1/winsup/w32api/include -isystem /usr/src/cygwin-1.3.14-1/newlib/libc/sys/
cygwin -isystem /usr/src/cygwin-1.3.14-1/newlib/libc/sys/cygwin32 -B/tmp/i686-pc
-cygwin/newlib/ -isystem /tmp/i686-pc-cygwin/newlib/targ-include -isystem /usr/s
rc/cygwin-1.3.14-1/newlib/libc/include -c -nostdinc++ -nostdinc -
DHAVE_CONFIG_H
 -g -O2 -Wall -Wwrite-strings -fno-common -pipe -Winline -fbuiltin  -I.  -I/usr/
src/cygwin-1.3.14-1/winsup/cygwin    -I/usr/src/cygwin-1.3.14-1/newlib/libc/sys/
cygwin/include  -I/usr/src/cygwin-1.3.14-1/winsup/cygwin/config/i386 -I/usr/lib/
gcc-lib/i686-pc-cygwin/3.2//include -fno-rtti -fno-exceptions -o ./tty.o /usr/sr
c/cygwin-1.3.14-1/winsup/cygwin/tty.cc
/usr/src/cygwin-1.3.14-1/winsup/cygwin/tty.cc: In member function `int
   tty_list::allocate_tty(int)':
/usr/src/cygwin-1.3.14-1/winsup/cygwin/tty.cc:196: `GetConsoleWindow'
   undeclared (first use this function)
/usr/src/cygwin-1.3.14-1/winsup/cygwin/tty.cc:196: (Each undeclared identifier
   is reported only once for each function it appears in.)
make[2]: *** [tty.o] Error 1
make[2]: Leaving directory `/tmp/i686-pc-cygwin/winsup/cygwin'
make[1]: *** [cygwin] Error 1
make[1]: Leaving directory `/tmp/i686-pc-cygwin/winsup'
make: *** [all-target-winsup] Error 2

I've seen this same error posted before but I couldn't find a workaround for it.

Agustin
(Continue reading)

Permalink | Reply | 1 comment |
headers
Max Bowsher | 1 Nov 2002 02:07

Re: Problem Compiling Cygwin Source

abarto <at> efn.uncor.edu <abarto <at> efn.uncor.edu> wrote:
> I'm trying to compile compile the cygwin source and I get the
> following error: 

Diagnosis: http://cygwin.com/ml/cygwin/2002-10/msg01532.html

Max.

> c++ -L/tmp/i686-pc-cygwin/winsup -L/tmp/i686-pc-cygwin/winsup/cygwin
> -L/tmp/i686 
> -pc-cygwin/winsup/w32api/lib -isystem
> /usr/src/cygwin-1.3.14-1/winsup/include -i system
> /usr/src/cygwin-1.3.14-1/winsup/cygwin/include -isystem
> /usr/src/cygwin-1 .3.14-1/winsup/w32api/include -isystem
> /usr/src/cygwin-1.3.14-1/newlib/libc/sys/ cygwin -isystem
> /usr/src/cygwin-1.3.14-1/newlib/libc/sys/cygwin32 -B/tmp/i686-pc  
> -cygwin/newlib/ -isystem /tmp/i686-pc-cygwin/newlib/targ-include
> -isystem /usr/s rc/cygwin-1.3.14-1/newlib/libc/include -c -nostdinc++
> -nostdinc - DHAVE_CONFIG_H
>  -g -O2 -Wall -Wwrite-strings -fno-common -pipe -Winline -fbuiltin 
> -I.  -I/usr/ src/cygwin-1.3.14-1/winsup/cygwin   
> -I/usr/src/cygwin-1.3.14-1/newlib/libc/sys/ cygwin/include 
> -I/usr/src/cygwin-1.3.14-1/winsup/cygwin/config/i386 -I/usr/lib/
> gcc-lib/i686-pc-cygwin/3.2//include -fno-rtti -fno-exceptions -o
> ./tty.o /usr/sr c/cygwin-1.3.14-1/winsup/cygwin/tty.cc
>    /usr/src/cygwin-1.3.14-1/winsup/cygwin/tty.cc: In member function
> `int tty_list::allocate_tty(int)':
>    /usr/src/cygwin-1.3.14-1/winsup/cygwin/tty.cc:196:
> `GetConsoleWindow' undeclared (first use this function)
>    /usr/src/cygwin-1.3.14-1/winsup/cygwin/tty.cc:196: (Each
(Continue reading)

Permalink | Reply | 0 comments |
headers
CBFalconer | 1 Nov 2002 03:05
Picon
Favicon

Re: gdb hangs on a 486

Christopher Faylor wrote:
> Larry Hall (RFK Partners, Inc) wrote:
> >At 11:13 PM 10/30/2002, CBFalconer wrote:
> 
> >>I have been trying out gdb in Cygwin, and found it to hang and/or
> >>crash under W98, running on a 486.  The output of gdb --version
> >>is:
> >>
... snip ...
> >> > This GDB was configured as "i686-pc-cygwin".
> >>                               ^^^^^^^^^^^^^^
> >>This appears unwarranted.  I would have assumed gdb would test and
> >>adapt itself to the processor on which it is running.
> >
> >At this point, I think most (all?) Cygwin packages are configured 
> >like this. Whether or not that's true, it's not unwarranted.  
> >There's good reason to make use of the newer architectures' 
> >capabilities.
> 
> The "i686-pc-cygwin" is just a convention.  It doesn't mean anything.
> GNU tools built for an i686 target *may* produce binaries that are
> reordered for better efficiency on that target but, in this case, I
> doubt that is even the case.
> 
> Unless someone can point to an actual 686 instruction that is causing
> problems, this discussion should die.  The standard "it crashes" or
> "it dies" bug reporting technique does not provide any details and
> speculating as to the cause with no supporting details is not a
> useful endeavor.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christopher Faylor | 1 Nov 2002 03:09
Picon
Favicon

Re: gdb hangs on a 486

On Thu, Oct 31, 2002 at 06:58:03PM -0500, CBFalconer wrote:
>Unfortunately that is all the data there is.  I don't expect a magic
>wand.  The problem is probably in the gui stuff gdb is calling anyhow.
>W98 is not noted for system protection.  However ignoring it is NOT the
>right answer.

Noting that a string on the screen says "i686", concluding that since
you don't have a i686 this is the cause of all of your problems, and
continuing to hold to that belief after you've been told it is unlikely,
is not the right answer either.

>Maybe a few mirrors should be set aside for systems with other
>configurations.

And now we segue into YA misconception this time it's about how mirrors
work.

What fun.

cgf
Permalink | Reply | 2 comments |
headers
Christopher Faylor | 1 Nov 2002 03:10
Picon
Favicon

Re: gdb hangs on a 486

On Thu, Oct 31, 2002 at 09:05:40PM -0500, CBFalconer wrote:
>Maybe a few mirrors should be set aside for systems with other
>configurations.

Wait a minute.  I thought I was having fun before but this is
*double* the fun.

Wheeee!

cgf
Permalink | Reply | 0 comments |
headers
CBFalconer | 1 Nov 2002 04:10
Picon
Favicon

Re: gdb hangs on a 486

Christopher Faylor wrote:
> On Thu, Oct 31, 2002 at 06:58:03PM -0500, CBFalconer wrote:
> 
> >Unfortunately that is all the data there is.  I don't expect a magic
> >wand.  The problem is probably in the gui stuff gdb is calling anyhow.
> >W98 is not noted for system protection.  However ignoring it is NOT the
> >right answer.
> 
> Noting that a string on the screen says "i686", concluding that since
> you don't have a i686 this is the cause of all of your problems, and
> continuing to hold to that belief after you've been told it is unlikely,
> is not the right answer either.

I did NOT say that.  I did say, in effect, that I was speculating,
and in one message that it would be worthwhile to record and
publicize what a package was compiled for.  I also said that this
system is and has been rock solid until the gdb-gui episode.  I am
well aware that noone is going to go out and look for anything as
nebulous as this.  With luck though, sometime somebody may say to
themself "AHA - this may explain that".  Provided the "that" has
been mentioned in public.

> 
> >Maybe a few mirrors should be set aside for systems with other
> >configurations.
> 
> And now we segue into YA misconception this time it's about how
> mirrors work.
> 
> What fun.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Takashi Yano | 1 Nov 2002 07:23
Picon

Re: 1.3.13-2 & 1.3.14-1 problem on read() from dgram socket

To reproduce this problem, please try next test cases.
Thank you.

Test Case 1:
- Environment: cygwin 1.3.13-2 or 1.3.14-1 under Windows 2000 or XP
- Setup inetutils and start "CYGWIN inetd"
- Send udp packet to port 9 of localhost
- Result: System load will goes up to full load.

Test Case 2:
- Environment: cygwin 1.3.13-2 or 1.3.14-1 under Windows 2000 or XP
- Compile following source; "server.c"
- Execute "server" to wait for udp packets.
- Result: "server" cause an error on read(). ( Bad Address).

- Environment: cygwin 1.3.12-2 under Windows 2000 or XP
- Compile following source; "server.c" and "client.c"
- Execute "server" to wait for udp packets.
- Execute "client" to throw a udp packet.
- Result: "server" receives upd packet correctly.

---------------------------------------------------------------
/* server.c */
#include <stdio.h>
#include <stdlib.h>

#include <strings.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tommy Chang | 1 Nov 2002 07:39
Picon
Favicon

succeed in linking both MSVCRT.dll and cygwin1.dll (version 1.3.12-4)


Just recently I started my first gtk+-2.0 application
under win32 platform.  At that time, the latest cygwin
was version 1.3.12-4.  I was able to compile and run
my gtk+-2.0 application without the '-mno-cygwin'
flag.

After I upgraded to cygwin 1.3.13-x I was not able to
run the program and got error like "Couldn't reserve
space for cygwin's heap".  The error went away if I
add the '-mno-cygwin' flag.

Now just going through the FAQ I learned that
MSVCRT.dll and cygwin1.dll are not suppose to
co-exist.  And indeed, my program have them both
linked, as verified from issuing the cygcheck command.
 It was strange that I could link both dlls and run
perfectly with cygwin version 1.3.12-4.

Anyway, I was just wondering if this 'feature' can be
restored....

--

-- 

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
(Continue reading)

Permalink | Reply | 0 comments |

Gmane