Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
X-Apparently-From:	<earnie?boyd AT yahoo DOT com>
Message-ID:	<3A53A4D5.155BAD1C@yahoo.com>
Date:	Wed, 03 Jan 2001 17:16:53 -0500
From:	Earnie Boyd <earnie_boyd AT yahoo DOT com>
Reply-To:	cygwin AT cygwin DOT com
X-Mailer:	Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language:	en
MIME-Version:	1.0
To:	M4um AT aol DOT com
CC:	cygwin AT cygwin DOT com, lhall AT rfk DOT com
Subject:	Re: #includes not being processed across network (revised)
References:	<e3 DOT e88f0d2 DOT 2784f5c3 AT aol DOT com>

M4um AT aol DOT com wrote:

> Larry:
>
> > If you're saying that this problem occurs if you move all the source to a
> >  UNIX machine and that the source is local on that machine (i.e. it doesn't
> >  somehow involve using the VisionFS file server stuff at all - I have no
> idea
> >  what this does for you), then I would say this is an issue with gcc tools
> >  (well cpp to be exact).  If you only see the problems when using the file
> >  server, then something about that setup/software is probably to blame.  In
> >  the former case, you could send email to the gcc list.  In the latter, you
> >  need to consult the providers of VisionFS.
>
> Pardon my ignorance, but isn't this the list that deals with gcc as it
> applies to Cygwin? The problem is, by definition, environment-dependant. The
> gcc, cpp and other Cygwin binaries are the "run side" of that environment;
> the "read side" is a common network-drive mapped onto H: (and served by
> VisionFS on the Unix box). If there is better list I'd gladly follow it, but
> starting at gnu.org and going to "Windows->gcc->binaries" leads me back here.
>

As you yourself have said, "The problem is, by definition,
environment-dependant."  No one else has your environment.  You will
have to
debug this yourself, but we'll try to help with suggestions.

Can other programs read the files?  E.G.: `cat /UNIX/foo.h' gives what
results?
Could it be a timing issue, or a permissions issue?  Are you using
Cygwin
symlinks on your H: directory, that most likely won't work unless you
can emulate
the Win32 system file bit on your UNIX server.

Cheers,
Earnie.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -