Re: #includes not being processed across network (revised)

[Earnie Boyd <earnie_boyd@yahoo.com>]

M4um@aol.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