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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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