From mboxrd@z Thu Jan 1 00:00:00 1970 From: M4um@aol.com To: cygwin@cygwin.com Cc: lhall@rfk.com Subject: Re: #includes not being processed across network (revised) Date: Wed, 03 Jan 2001 13:38:00 -0000 Message-id: X-SW-Source: 2001-01/msg00099.html 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. That being said, can you suggest a test that would better define exactly where the breakdown is occuring? Remember that we are NOT getting any sort of error message: the #included file is being found but not processed. The Unix side of the net has been exhaustively diag'ed and reconfigured in every way imaginable, with the same results. If you'll forgive the term, it "smells" like there's a loss of syncronization somewhere in cpp. BTW: My arrangement of sources and headers across several different OSs is not that unusual. We have C source code for libraries and apps under Unix, and are preparing Windows console executables using Cygwin's gcc. This requires that the source code stay on the Unix box and #includes may be found on either machine as needed to orient the different compilers to their native OS. We will expand this to lynix, etc., as needed across the network, but never disturbing the Unix-resident source. It's basically using a network instead of a cross-compiler. Thanks, John -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple