#includes not being processed across network (revised)

Earnie Boyd earnie_boyd@yahoo.com
Wed Jan 3 14:16:00 GMT 2001

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
Could it be a timing issue, or a permissions issue?  Are you using
symlinks on your H: directory, that most likely won't work unless you
can emulate
the Win32 system file bit on your UNIX server.


Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.

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

More information about the Cygwin mailing list