Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: M4um AT aol DOT com
Message-ID: <d1.aa12be.27853b43@aol.com>
Date: Wed, 3 Jan 2001 21:34:43 EST
Subject: Re: #includes not being processed across network (revised) 
To: cygwin AT cygwin DOT com
CC: lhall AT rfk DOT com, earnie_boyd AT yahoo DOT com (Earnie Boyd)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Larry:

>  >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!;-)

Okay ... Now imagine that you are running a Cygwin gcc compile under such a 
arrangement: the C source code  may be anywhere on the net, and there are 
#includes on both the Windows machine and Unix.  Any #included files it finds 
on the Windows box it processes OK; any #included files it finds on the Unix 
box -- and it tells you that it finds them -- are simply not processed, and 
there is no error message telling you "cannot access", "locked", etc.  THAT'S 
what I'm observing.

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

No, I think we're miscommunicating ...  I have a Unix version of gcc running 
on the Unix box generating Unix apps; I wish to access these same sources 
from Cygwin and compile Windows versions.

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

Yes, I understand that this may be a "new" combination -- Cygwin gcc on Win98 
+ SCO's VFSU.  That's one of the reasons I posted here: in the hopes that 
someone may have used this combination before and might be able to offer an 
experienced hand.
 
I'll look into the possibility of using Samba.

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

"Ming" is not an option at this time.  I have some time constraints and must 
deliver something that will run both apps and existing Unix scripts, at least 
in the short term.

One other thought just struck me: Are #included files accessed by any 
specific dll or bash/sh command or function that can be excersized or tested 
independantly by some clever means?  It may be that I have something still 
outdated in my installation that's fallen through the cracks.  (By the way, 
since the last cygcheck I've upgraded the cygtcl dlls.) 

While I research how Samba will fit into our configuration, can you think of 
any gcc/cpp tests that might help me isolate this problem?

Thanks,
John

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