Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-Id: <4.3.1.2.20010103171540.0227dee8@pop.ma.ultranet.com>
Date: Wed, 03 Jan 2001 17:37:20 -0500
To: M4um AT aol DOT com, cygwin AT cygwin DOT com
From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
Subject: Re: #includes not being processed across network (revised) 
In-Reply-To: <e3.e88f0d2.2784f5c3@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:38 PM 1/3/2001, 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.


You made a comment in your original message that lead me to believe that you
tried taking all the sources to some UNIX system and compiled it there with
gcc and saw the same problem.  Was that the wrong impression?  If so, then
it may be a gcc-on-Windows thing.  If not, it may be a generic gcc issue
or a problem with whatever VisionFS is and what it does for you.  I don't 
mean to suggest that you haven't configured VisionFS properly for your needs
but not knowing what this is, what it provides, and what parts are interacting
with gcc makes it hard for anyone on this list to rule it out summarily.  If
it provides access to its disks through some NFS server, for example, it 
would not be the first time that a problem was reported to this list along
this line where the issue was a problem with the way the NFS server worked. There's also always the potential for interaction problems with heretofore 
unknown and untried software in combination with Cygwin (which this qualifies
as AFAIK).  If there's reason to suspect an interaction problem here, you may 
want to try installing a Samba server on your UNIX box and use that as the 
Windows file server.  People using Cygwin have generally had luck with that.

Its also worthwhile to note that while Cygwin is a platform that supports
gcc on Windows (and probably the most convenient one for you given the 
origin of your source). There is also a native Windows port that doesn't
require Cywgin at all (see www.mingw.org).  You may want to test out your 
problem with this as well to see if you would be better served by another 
list found at gcc.gnu.org.


>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. 


Definitely could be.


>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.


This much I get!;-)

Good luck,


Larry Hall                              lhall AT rfk DOT com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


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